DevSecOps - build phase

Первая фаза DevSecOps-конвейера относится к сборке проекта и состоит из этапов pre-commit, Pre-build и Post-build. Сегодня предлагаю рассмотреть возможные проверки и инструменты этих этапов. Преимущество буду отдавать передовым open-source-решениям.

Все проверки этой фазы выполняются методом белого/серого ящика — анализируется код, файлы проекта или метаданные артефактов сборки.

Pre-commit

На этапе Pre-commit можно настроить Secret Detection. Вызов сканера интегрируется в Git через pre-commit hook. Преимущества понятны, а вот к недостаткам следует отнести необходимость локальной установки и настройки, поддержка идентичности которой отдельная и крайне неприятная задача. Между тем, многие настройки можно положить в Git.

Управление секретами — прежде всего определённый уровень инженерной культуры проекта. Иначе говоря, сначала нужно договориться о способе работы с секретами, а потом вводить инструменты контроля.

Популярные инструменты:

• Trivy — универсальный сканер для обнаружения проблем с безопасностью. Производит анализ пакетов в SBOM, находит известные уязвимости (CVE), некорректные настройки в IaC, конфиденциальную информацию и секреты, проблемы с лицензированием. Имеет подробную документацию и интеграцию с множеством инструментов. Лицензия Apache-2.0, 27.9k звёзд на GitHub.
• gitleaks — сканер для детектирования секретов в Git-репозитории, файловой системе и stdin. Позволяет гибко настраивать правила проверки. Лицензия MIT, 22.9k звёзд на GitHub.

Pre-build

На этом уровне можно настроить следующие проверки:

• Secret Detection — обнаружение секретов, но уже после того, как изменения отправлены в центральный репозиторий. Инструменты: GitLab Secret Detection (Free); Trivy; gitleaks.
• Static Application Security Testing (SAST) — анализ исходного кода на наличие распространённых уязвимостей. Отчёт включает список уязвимостей со ссылкой на конкретные фрагменты кода. Статический анализ не запускает проверяемый код, следовательно, провоцирует множество ложно-положительных срабатываний и пропускает некоторые виды уязвимостей. Инструменты: GitLab SAST (Free), GitFlic SAST (Enterprise); PVS-Studio SAST; SonarQube.
• Software Composition Analysis (SCA) — обнаружение уязвимостей в используемых зависимостях с открытым исходным кодом, анализ лицензионной совместимости и возможные риски нарушения лицензионных прав. Инструменты: Trivy; PVS-Studio SCA; GitLab Dependency Scanning (Ultimate); GitFlic SCA (Enterprise).

Как мне кажется, несмотря на все недостатки, по соотношению прилагаемых усилий и получаемого эффекта статический анализ остаётся самым простым и рабочим инструментом. Обратите внимание, что часть проверок доступна из коробки CI/CD, следовательно, подключить эти проверки будет проще. Некоторые инструменты могут быть интегрированы в IDE (Trivy, PVS-Studio).

Для SCA требуется сформировать файл SBOM. Они бывают разных форматов, поэтому выбирать нужно тот, который совместим с используемым SCA. В Java файл SBOM проще всего формировать на этапе сборки. Например, для генерации SBOM в формате CycloneDX используйте официальный Gradle-плагин.

Post-build

На этом уровне выполняется Binary SCA — обнаружение уязвимостей в бинарных артефактах, полученных после сборки. Проверяться может как содержимое файлов, так и их хэш-сумма. В последнем случае по хэш-сумме находят сведения о файле в открытых базах уязвимостей. Инструменты: GitLab Container Scanning (Free); Trivy; grype; clair.

---

Делитесь своими историями использования статических сканеров. У меня есть одна…

На одном из проектов SAST-проверку делал заказчик. Под анализ попадал не только код, но и локальная конфигурация с тестами. Нормально договориться так и не получилось, пришлось искать “обходные пути”. В итоге вся проверка была сведена к какому-то бесполезному ритуалу. Уверен, что всё можно сделать значительно эффективней, но эффективность, по всей видимости, во многом зависит от того, насколько ИБ понимает разработку, а разработка ИБ.