Когда я был молодым разработчиком, только что окончившим колледж, безопасность приложений не была чем-то особенным. Моя степень связана с информатикой, и я даже не помню ни одного курса, связанного с безопасностью приложений. Как разработчику мне было трудно понять, как моя работа может повлиять на безопасность.
В то время я ассоциировал безопасность с обязательным обучением обнаружению фишинга, защитой на сетевом уровне, препятствием для своевременного выполнения моих требований в процессе разработки и набором бюрократических политик, которые не имели для меня никакого логического смысла. Я как бы не хотел иметь ничего общего с безопасностью. Пока я не увидел it, Что такое it? Это был изъян в моем коде, который позволял мне манипулировать результатами. Так началось мое увлечение безопасность приложения — и новый карьерный путь, который я буду любить все больше с каждым днем.
За свою карьеру я создал несколько базовых программ безопасности приложений. Первый прошел методом проб и ошибок, но в итоге я добился своего. Последующие программы становились все лучше и лучше. В чем мой секрет? Зная свою аудиторию!
Когда вы создаете программу безопасности приложений, это не диктатура, это партнерство. Также важно отметить, что для обеспечения безопасности приложений необходимо быть двуязычным. Вам нужно говорить разработчику, и вам нужно говорить о безопасности.
Я утверждаю, что двумя наиболее фундаментальными критериями успеха развития являются:
- Функциональность бизнес-требований
- Соблюдайте сроки вовремя
Сдвиг влево
Зная эти основные критерии успеха разработки, как нам не повлиять на них негативно?
Ответ: безопасность со сдвигом влево, применение средств контроля безопасности уже в жизненный цикл разработки программного обеспечения (SDLC) насколько это возможно. Когда вы обнаруживаете уязвимость в коде на этапе разработки SDLC — не каждая уязвимость является уязвимостью, но каждая уязвимость является уязвимостью — время, деньги и усилия, необходимые для исправления, экспоненциально меньше, чем если бы она была обнаружена как уязвимость. в производстве… или, что еще хуже, в эксплуатации.
Существует множество отличных решений для статического тестирования безопасности приложений (SAST), которые могут анализировать код по мере написания кода разработчиками и предлагать исправления в режиме реального времени. Не хотите использовать подключаемый модуль SAST в своей среде IDE? Отлично, интегрируйте SAST в свой автоматизированный конвейер. Автоматизируйте сбои сборок, которые не соответствуют политике безопасности. Если ваше решение SAST обнаружит критическую ошибку или уязвимость, не допускайте слияния запроса на извлечение с мастером. Ваши разработчики по достоинству оценят ваше вмешательство раньше, чем если бы вы решили выдернуть вилку из розетки и принудительно предпринять экстренные меры по исправлению после того, как продукт/программное обеспечение/микропрограмма были развернуты в рабочей среде.
Давайте рассмотрим уязвимость Log4j. Вы также можете помнить о безопасности сдвига влево при работе со сторонними зависимостями. Анализ состава программного обеспечения (SCA) сканирует ваше программное обеспечение и составляет спецификацию (BOM), в которой перечислены компоненты вашего приложения и используемые версии. Многие надежные бинарные сканеры SAST также будут иметь SCA в качестве опции. Сделайте и то, и другое! Знайте, с чем вы имеете дело в своем окружении. Когда произойдет следующий нулевой день Log4j, насколько хорошо было бы быстро найти эту конкретную зависимость и версию, чтобы вы могли определить влияние и создать план для следующих шагов?
Отступим от технологий. Помните, я сказал, что секрет успешного создания программ безопасности приложений заключается в знании вашей аудитории? Что ж, разработчики логически мыслят. Они будут более склонны присоединиться к вашей программе безопасности, если вы начнете с «почему» и дадите им возможность купить или высказать свои опасения, потому что то, что вы делаете, должно иметь для них смысл. Каждую технологию безопасности, которую я внедряю, я проверяю с группой разработчиков, которая будет затронута. Каждую политику, которую я пишу, я привлекаю для утверждения представителями отдела разработки. Вы будете удивлены, как далеко вас заведет сила партнерства.
Другие вещи, которые вы можете заранее сделать, чтобы повысить безопасность сдвига влево в SDLC:
- Создавайте стандарты безопасности приложений и сообщайте о них: Дайте разработчикам надежду на успех в области безопасности.
- Предлагайте курсы по безопасному кодированию и поощрения для разработчиков, которые выходят за рамки: Наградите своих чемпионов по безопасности! Вы нуждаетесь в них!
- Подружитесь со своими менеджерами проектов и проинформируйте их о требованиях безопасности, чтобы они знали, как связаться с вами, когда появятся новые проекты: Вы не хотите быть последним приглашенным на вечеринку.
Хотя также важно быть готовым реагировать, когда дело доходит до безопасности, большие победы приходят от этого подхода к безопасности со сдвигом влево и позитивной культуры, которую вы создаете с его помощью.
