Этапы DevSecOps‑пайплайна: pre‑commit, pre‑build и post‑build

В первой части статьи мы рассказывали о концепции Shift-left и о структуре DevSecOps‑пайплайна. Основная идея — начать проверки безопасности продукта ещё на этапе разработки. Мы упомянули основные фазы проверки безопасности, подробнее о которых поговорим во второй и третьей части статьи.

Во второй части пойдёт речь об этапах pre‑commit (проверка безопасности до того, как разработчик закоммитит код в систему контроля версий), pre‑build (проверка безопасности после того, как код попал в систему контроля версий) и post‑build (проверка безопасности артефакта, собранного из исходного кода, например Docker‑файла, RPM‑пакета или JAR‑архива). Мы подробнее рассмотрим, в чём на этих этапах заключаются проверки безопасности и какие инструменты для этого можно использовать.

Статья будет полезна руководителям и сотрудникам отделов информационной безопасности, разработки и DevOps‑команд.

Проверки pre‑commitПроверки pre‑commit

Pre‑commit‑проверки позволяют анализировать исходный код на машине разработчика перед коммитом изменений в локальную копию репозитория. Если какая‑то из проверок возвращает ошибку, коммит не выполняется. В этом случае разработчик должен исправить ошибку и заново сделать коммит. Такая проверка позволяет избежать ситуации, когда в репозиторий попадёт непроверенный код, например, с незашифрованными секретами.

Pre‑commit‑проверки требуют установки инструментов на локальные машины разработчиков. Такой подход имеет не только плюсы, но и минусы. Например, различия в окружении: разные версии самих инструментов, разные операционные системы и даже архитектуры процессора. Если разработчики используют разные версии инструментов pre‑commit, результаты проверки будут различаться, это может затруднить совместную работу. Учитывайте это, внедряя pre‑commit‑проверки в рамках команды или всей компании.

Проверки pre‑buildПроверки pre‑build

На фазе pre‑build выполняются проверки методом «белого ящика» (White Box Testing). С помощью таких проверок, как и на предыдущей фазе, анализируется исходный код.

Существует несколько типов pre‑build‑проверок:

• Secret Detection

• Static Application Security Testing (SAST)

• Software Composition Analysis (SCA)

Рассмотрим каждый из этих типов подробнее.

Secret DetectionSecret Detection

Secret Detection — это автоматизированная проверка, с помощью которой можно обнаружить незашифрованную конфиденциальную информацию: например, секреты в исходном коде, попавшем в систему контроля версий.

Pre‑build‑проверки выполняются после того, как исходный код попал в репозиторий системы контроля версий. Поэтому все незашифрованные конфиденциальные данные в репозитории потенциально могут стать доступны злоумышленникам, например, в случае утечки содержимого репозитория.

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

Чтобы решить эти проблемы, нужно выполнить много разных действий. Например, очистить репозитории от незашифрованных секретов, внедрить различные инструменты управления секретами, такие как HashiCorp Vault или Yandex Lockbox.

Static Application Security TestingStatic Application Security Testing

Static Application Security Testing (SAST) — проверка, при которой анализаторы не просто проверяют синтаксическую корректность, но и измеряют качество кода с помощью специальных метрик. Основная задача SAST‑сканеров — тестирование на безопасность. В частности, SAST‑анализаторы проверяют исходный код на наличие распространённых уязвимостей, например, из списка OWASP Top Ten. Сканеры находят не только саму уязвимость, но и фрагмент кода, из‑за которого она появилась.

SAST‑анализ также называют проверкой методом «белого ящика» (White Box Testing), так как анализатор имеет доступ к внутренней структуре приложения. Важно отметить, что анализаторы проверяют исходный код, не запуская его, поэтому могут генерировать ложные срабатывания и не обнаружить некоторые типы уязвимостей. По этой причине не стоит ограничиваться только SAST‑анализом. Лучше подойти к вопросу комплексно и использовать различные типы анализа: SCA, DAST, IAST, OAST.

Source Software Composition AnalysisSource Software Composition Analysis

Software Composition Analysis (SCA) — методология, которая обеспечивает безопасность приложений, анализируя их компоненты с открытым исходным кодом.

SCA‑сканеры отыскивают устаревшие зависимости, содержащие известные уязвимости и эксплойты. А ещё некоторые SCA‑инструменты могут определить лицензионную совместимость компонентов и риски нарушения лицензионных прав.

Source SCA анализирует исходный код, а точнее — зависимости приложения, определённые в исходном коде. Этот анализ часто встречается под именем Dependency Scanning.

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

Хороший пример — Log4Shell. Эту уязвимость обнаружили в конце 2021 года в Log4j, популярном Java‑фреймворке для логирования. Она стала одной из самых страшных уязвимостей, так как позволяла злоумышленникам выполнять произвольный Java‑код на сотнях миллионов устройств.

Проверки post‑build. Binary SCAПроверки post‑build. Binary SCA

Фаза post‑build наступает после того, как в CI‑пайплайне из исходного кода были собраны артефакты: Docker‑образ, RPM‑пакет или JAR‑архив. С помощью post‑build‑проверок анализируются зависимости в этих бинарных артефактах.

Binary Software Composition Analysis (SCA)Binary Software Composition Analysis (SCA)

Binary SCA анализ подразумевает проверку бинарных артефактов, таких как Docker‑образы, RPM‑пакеты и JAR/WAR/EAR‑архивы. Его также часто называют Container Scanning. Запускать его имеет смысл, когда бинарные артефакты собраны, то есть не раньше стадии post‑build.

При работе с Docker‑образами есть некоторые интересные особенности. Binary SCA‑анализаторы проверяют слои Docker‑образов и ищут их бинарные слепки в виде хеш‑сумм в открытых базах уязвимостей, таких как National Vulnerability Database (NVD) или Snyk Vulnerability DB. Некоторые из анализаторов могут не только отыскать уязвимые компоненты, но и предложить способ исправления, например, указав минимально необходимую версию компонента с уже устранённой уязвимостью.

ЗаключениеЗаключение

Мы кратко рассмотрели особенности проверок безопасности на первых трёх фазах DevSecOps‑пайплайна. Для этих целей есть как проприетарные решения (в том числе и российские), так и опенсорсные инструменты. Узнать подробности о работе таких инструментов можно на курсе «DevSecOps в облачном CI/CD».

В третьей части статьи мы поговорим об этапах test‑time, post‑deploy и инструментах визуализации данных.