8505 подписчиков

Как SAST улучшает безопасность DevSecOps

25 июня25 июн

6 мин

изображение: recraft

DevSecOps – набор методик, без которых сегодня сложно представить разработку программных решений. Рынок цифровых продуктов развивается стремительно – разработчики выпускают релизы, добавляют новые функции. При такой скорости обновлений растет риск ошибок и уязвимостей. Любая неточность в коде может привести к утечке данных или сбою в ПО, поэтому специалисты пересматривают подход к разработке и встраивает безопасность в каждый из ее этапов.

При этом каждый раз анализировать код вручную сложно и трудозатратно. Существует эффективный метод анализа безопасности исходного кода приложений на этапе разработки – SAST (Static Application Security Testing). Его используют для автоматического поиска уязвимостей без запуска программы, что помогает устранить риски до выпуска продукта. Инструменты SAST, согласно методологии DevSecOps, интегрируются в CI/CD, ускоряя проверку кода и снижая затраты на исправление ошибок. В статье выясним, почему разработчики выбирают этот подход, как он помогает анализировать код и создавать безопасные ИТ-решения.

Как эффективно интегрировать SAST в DevSecOps, рассказывает Павел Пилькевич, инженер-разработчик отдела систем анализа машинных данных STEP LOGIC.

Основной причиной появления DevSecOpsстало требование к интеграции проверок безопасности в процесс разработки, что способствует повышению эффективности и ускорению выпуска новых релизов продукта. Интеграция в SASTв DevSecOps, в первую очередь, должна учитывать этот основополагающий фактор.

В самом простом случае анализатору SAST нужно предоставить исходный код приложения и запустить процесс сканирования. Во время работы сканер проверит программный код на наличие опасных паттернов, таких как хранение секретов, поиск уязвимых или незадекларированных элементов кода, и, в случае обнаружения, оповестит об угрозах.

Мы рекомендуем внедрять SASTиз-за простоты и удобства использования таких анализаторов. По моим оценкам, ни один другой способ поиска уязвимостей не сможет настолько детально проанализировать все строки исходного кода разработанного приложения. Он строку за строкой проходит и проверяет все символы на совпадения. Гибкий функционал конфигурирования статических анализаторов позволяет самостоятельно определять, какие уязвимые паттерны искать в коде – не оперировать стандартным набором часто встречающихся уязвимостей, а адаптировать процесс контроля безопасности под требования компании и продукта.

Вторая причина, по которой мы рекомендуем внедрятьSASTв процессы разработки – сокращение времени обнаружения уязвимости. Чем позже вы обнаружите «дыру» в безопасности продукта, тем дороже и труднее обойдется ее закрытие. Статический анализ позволяет предотвратить появление таких «дыр» на самом начальном этапе разработки.

В связи с тем, что для обнаружения угроз статические анализаторы работают с исходным кодом напрямую, главная задача DevSecOpsпри взаимодействии с SAST – не допустить попадание уязвимого кода в репозиторий продукта. DevSecOpsвключает в себя несколько ключевых точек проверки продукта на соответствие безопасности: pre-build, post-build, deployи другие. Статические анализаторы необходимо внедрять уже на самом начальном этапе pre-commitchecks, который служит точкой входа в DevSecOps. Проверки на этом этапе, как правило, запускаются, когда разработчик пытается зафиксировать внесенные им изменения в репозитории проекта.

Перед тем, как принять изменения разработчика, мы рекомендуем проверять исходный код на соответствие требованиям безопасности, и только в случае отсутствия нарушений, фиксировать изменения в истории проекта. Если SAST обнаружил уязвимости, изменения отклоняются, а разработчику приходит уведомление с деталями. Такие проверки могут быть настроены как перед фиксацией изменений в локальном репозитории (gitcommit), так и при попытке отправки локальных изменений в удалённый репозиторий (gitpush). Другим примером реализации SASTявляется внедрение таких проверок уже перед выпуском изменений в продуктивной версии решения, если требования к безопасности не такие строгие.

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

Для эффективной интеграции SASTв жизненный цикл разработки ПО необходимо, в первую очередь, проанализировать уже имеющийся цикл и выявить точки, где статический анализ будет повышать безопасность продукта, а не станет отягчающим фактором для команды разработки. Рассмотрим на примере одного из кейсов нашей компании.

Служба информационной безопасности заказчика установила обязательное требование: проводить проверку исходного кода на наличие уязвимостей перед выводом решения в промышленную эксплуатацию. При этом, анализ выполнялся на завершающем этапе разработки, и по результатам каждого контроля команда получала расширенный перечень выявленных проблем, требующих обязательного устранения перед согласованием релиза. Это приводило к постоянному увеличению объема доработок и переносу сроков выпуска продукта. В сложившейся ситуации наша компания была привлечена в качестве эксперта для реорганизации процесса разработки и корректной интеграции инструментов статического анализа кода. Мы внедрили SASTна более ранних этапах разработки ПО, что позволило минимизировать доработки и выпустить продукт в срок.

Мы также рекомендуем останавливать свой выбор на качественных статических анализаторах, которые поддерживают понятное и удобное конфигурирование, чтобы процесс корректировки механизма статического анализа не подрывал весь цикл DevSecOps. Если существуют специально разработанные решения под вашу платформу управления CI/CD, используйте их. Например, если вы используете GitLab, то можно выбрать решение GitLabSAST, которое уже ориентировано на данную среду. Продукты для статического анализа кода не отличаются сложной логикой реализации, поэтому на рынке существует множество доступных решений, в том числе с открытым исходным кодом. Например, если стоит задача анализировать случайно оставленные конфиденциальные данные в коде (пароли, токены), отлично подойдетGitLeaks.

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