Безопасная разработка: виток развития. Интеграция на каждом этапе

Безопасная разработка: виток развития. Интеграция на каждом этапе

Финансовые организации сегодня в большинстве своём уже пришли к осознанию необходимости выстраивания процессов безопасной разработки. Этому способствует, в частности, ЦБ. После недавнего появления методического документа «Профиль защиты прикладного программного обеспечения и автоматизированных систем и приложений…» стало понятно, что для соответствия политикам регулятора качественный процесс безопасной разработки иметь просто необходимо. Поговорим о том, какие возможности существуют сегодня для повышения эффективности уже функционирующего процесса безопасной разработки.   

БЕЗОПАСНОСТЬ «ПО КЛАССИКЕ»

Подход, при котором проверки на безопасность были периодическими и проводились ближе к концу выпуска релиза продукта, а специалисты по ИБ были изолированы от процесса, уже остался в прошлом. Тогда считалось вполне нормальным в качестве заключительного штриха провести для продукта тестирование на проникновение. Причём обнаруженные по итогу проблемы безопасности не всегда устранялись из-за угрозы срыва поставок.  

Но довольно быстро разработчики и отдел сопровождения начали работать совместно, руководствуясь принципами Agile, постепенно автоматизируя свои процессы и переходя к непрерывной разработке (DevOps). Безопасность поначалу сильно отставала, но постепенно пришло понимание, появились средства анализа защищённости, предназначенные для контроля различных аспектов ПО, включая SAST (статический анализ кода), SCA (анализ используемых библиотек с открытым исходным кодом), DAST (динамический анализ приложений). Эти практики начали не только применять вручную, но и включать их в процесс разработки для автоматизации.  

ПАРАДИГМА «ДВИЖЕНИЯ ВЛЕВО»

На следующем этапе произошёл «сдвиг влево» практик безопасной разработки, то есть максимально близко к началу создания продукта. Так, статический анализ приложения стал проводиться сразу при сборке новой тестовой версии, после внесения изменений разработчиком. За счёт этого дефекты безопасности начали выявляться и устраняться на раннем этапе, без необходимости проверять стабильность работы системы после исправления.  

Аналогично стали проверяться библиотеки с открытым исходным кодом — сразу при попадании в код, благодаря чему отпала необходимость впоследствии переделывать ощутимую часть продукта в попытках найти замену уязвимой библиотеке.  

Все практики стали ориентироваться на максимальное смещение в сторону начала процесса разработки и на уменьшение показателя «стоимость исправления дефекта». И уже когда компании начали выходить на определённый уровень зрелости, они начали задумываться о том, что всё это можно использовать на более поздних этапах, тем самым обеспечивая контроль не только при разработке, но и при эксплуатации. А также обратить внимание и на более ранние этапы, ещё до попадания кода или библиотеки в репозиторий. 

НОВЫЕ ВЫЗОВЫ — «ИНТЕГРАЦИЯ НА КАЖДОМ ЭТАПЕ»

Сегодня всё большую популярность набирает новый подход — «интеграция на каждом этапе жизненного цикла», с которым проверки могут дать наибольшую пользу.

SAST

Статический анализ кода, как правило, применяется после попадания кода разработчика в основную ветку. Но эффективность данной практики можно повысить.

Проверка на этапе написания кода

Так, можно анализировать код из среды разработки, в которой он пишется. Это делается при помощи плагина от инструмента безопасности, который подсвечивает опасные места или небезопасные конструкции сразу после создания строки кода или, в других случаях, после нажатия на специальную кнопку. Такой подход позволяет не просто обнаруживать уязвимости, а не допускать их появления в системе контроля версий (VCS). При этом он очень удобен в работе. 

Сканирование перед загрузкой в систему контроля версий

Ещё один пример реализации: при отправке разработчиком кода в систему контроля версий происходит блокировка в случае нарушения одного из требований. Его часто применяют для поддержания качества кода. Но также можно использовать его для статического анализа — чтобы обновлённая версия кода автоматически проверялась, после чего принималось бы решение о возможности её загрузки. Оптимально проводить быстрый поверхностный анализ для выявления наиболее простых или критических вещей (исключив их попадание в репозиторий), так как последующие этапы покроют всё остальное. 

Интеграция с системой проведения код-ревю

При отправке кода на процесс ревю другими разработчиками он также может уходить в систему SAST. И тогда после анализа выявленные уязвимости будут добавляться в комментарии, которые видят все участники процесса ревю. Это исключит «умалчивание» уязвимостей и их попадание в стабильную ветку. 

SCA/OSA

Как правило, анализ библиотек с открытым исходным кодом проводят на уже собранном артефакте, который содержит в себе все зависимости, или для исходного кода, в котором есть файлы сборки. 

Есть решения, которые позволяют упростить внедрение этой практики и получать эффект на многих этапах, включая и выпуск в промышленную эксплуатацию: 

Анализ компонент, которые попадают во внутренний репозиторий

Некоторые компании разрабатывают свои системы в закрытом контуре, и их системы сборки, а иногда и рабочие места не имеют доступа в интернет. В таком случае загрузка всех библиотек, необходимых для сборки приложения, проходит через единую систему хранения библиотек. И можно применить подход с файрволом для компонент с открытым исходным кодом, которые не удовлетворяют требованиям безопасности. Допустим, при создании новой функциональности разработчик хочет подключить внешнюю библиотеку, которой ещё нет во внутреннем контуре. Он обращается к репозиторию с соответствующей просьбой. Если процесс выстроен грамотно, библиотека проходит анализ на безопасность внутри и принимается решение о возможности её использования. Это позволит свести риски попадания уязвимого компонента из неё к минимуму. 

Мониторинг компонент в промышленной эксплуатации

Также возможно мониторить то, что уже находится в периметре компании. В частности, библиотеки и их версии, которые на данный момент используются в развёрнутом приложении. Ведь может случиться, что библиотека считалась безопасной, когда компания выпускала продукт, а через неделю в ней обнаружили критическую уязвимость. Как можно быстро узнать об этом? Как понять, какие продукты используют именно эту уязвимую версию? Ответы на эти вопросы поможет дать механизм мониторинга. Непосредственно перед разворачиванием продукта происходит составление SBOM-файла с перечнем используемых библиотек и их версий. И к нему проводится периодическая проверка на наличие новых, неизвестных ранее проблем с безопасностью. При их появлении ответственные лица сразу же получат уведомление и смогут принимать решения и реагировать.  

ВЫВОДЫ

Примеров того, как разные практики эволюционируют, предоставляя новые возможности для интеграции их в самые разные этапы жизненного цикла, великое множество. К сожалению, охватить их все в рамках одной статьи и показать, как различные активности могут применяться ближе к «правой» части разработки, как контролировать целостность артефактов, как обрабатывать срабатывания с инструментов защиты приложений, как использовать информацию из сообщений технической поддержки, как развиваются программы Bug Bounty, физически невозможно, хоть и очень хочется. 

Отрадно наблюдать за развитием процессов безопасной разработки, за тем, как они предоставляют компаниям всё больше возможностей для повышения эффективности и качества работы.

Важно то, что каждая компания, с которой мы работаем, успешно развивается от «классической безопасности» в сторону «интеграции на каждом этапе». Очень надеюсь, что в ближайшем будущем мы увидим новый виток развития процессов безопасной разработки и сможем выйти на новый уровень защищённости наших сервисов. 

Реклама. ООО «Свордфиш секьюрити», ИНН:7842496093, erid: 2VfnxwQgVVr