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

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

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

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

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

Проверки pre‑commit

Место проверок pre‑commit в DevSecOps‑пайплайне

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

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

Инструменты pre‑commit

Существует множество опенсорсных инструментов, с помощью которых можно настроить pre‑commit‑проверки:

Проверки pre‑build

Место проверок pre‑build в DevSecOps‑пайплайне

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

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

  • Secret Detection

  • Static Application Security Testing (SAST)

  • Software Composition Analysis (SCA)

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

author
Алексей Колосков
Ведущий DevOps/Cloud инженер Hilbert Team.
author
Михаил Кажемский
Ведущий DevOps/Cloud инженер Hilbert Team.

DevSecOps на практике

Из серии статей вы узнаете об основных этапах DevSecOps-пайплайна, автоматизированных проверках безопасности при разработке ПО, бесплатных и опенсорс-инструментах.

Secret Detection

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

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

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

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

Инструменты Secret Detection

Secret Detection можно настроить с помощью Gitleaks, git‑secrets или detect‑secrets. Но лучше всего использовать сервисы, которые предоставляют известные CI/CD‑платформы, например GitLab Secret Detection.

Static Application Security Testing

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

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

Инструменты SAST

Source Software Composition Analysis

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

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

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

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

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

Инструменты SCA

  • Опенсорсное решение:

  • Инструмент в составе GitLab (доступен только в Ultimate‑версии):

  • Российские решения:

  • Коммерческие решения с бесплатными тарифными планами:

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

Место проверок post‑build в DevSecOps‑пайплайне

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

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. Некоторые из анализаторов могут не только отыскать уязвимые компоненты, но и предложить способ исправления, например, указав минимально необходимую версию компонента с уже устранённой уязвимостью.

Инструменты Binary SCA анализа

Заключение

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

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

Курс "DevSecOps в облачном CI/CD"

Узнайте, что такое DevSecOps, зачем он нужен и как усовершенствовать существующие DevOps-пайплайны.

Напишите нам

Начать пользоваться Yandex Cloud

Тарифы

Узнать цены и рассчитать стоимость

Мероприятия

Календарь событий Yandex Cloud
Этапы DevSecOps‑пайплайна: pre‑commit, pre‑build и post‑build
Войдите, чтобы сохранить пост