SAST и SCA как процесс: когда блокируют сборку, кто закрывает находки
Сканер в конвейере без правил — это отчёт, который никто не читает. Зафиксируйте процесс: какие находки SAST (анализ своего кода) и SCA (зависимости) останавливают merge, кто их забирает, за сколько дней закрывают, как выглядит исключение. Как поставить SonarQube, bandit, pip-audit или Dependency-Track — уже написано; сюда эти job не копируйте.
Статья опирается на логику направления «Управление уязвимостями» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. NIST SP 800-218 относит поиск уязвимостей в коде и компонентах к практикам создания ПО, а не к разовому пентесту: SP 800-218. Это не российский закон.
Два потока, не один отчёт
| Поток | Что ищет | Где на сайте инструмент | Когда гонять |
|---|---|---|---|
| SAST | Ошибки в вашем коде | bandit, SonarQube в GitLab CI | Каждый merge request и ветка по умолчанию |
| SCA | Известные дыры в библиотеках | pip-audit, Dependency-Track в той же статье про GitLab CI | Каждый MR, где меняется lock-файл, и ночной прогон на основной ветке |
| Образ | Пакеты и секреты в контейнере | Trivy | Сборка образа, не вместо SCA приложения |
Инфраструктурный скан хостов — другой цикл: управление уязвимостями. Не складывайте CVE nginx на сервере и CVE в requirements.txt в одну очередь без пометки источника.
Порог, который реально краснеет
На старте для небольшой команды достаточно такого правила (запишите его в README репозитория, не в голове ИБ):
| Сигнал | Merge | Что делать |
|---|---|---|
| SAST: высокая уверенность и высокая серьёзность, находка в новом коде ветки | Блок | Исправить в этом MR или вырезать кусок |
| SCA: критичность высокая или критическая и есть исправление в новой версии | Блок, если зависимость добавили или обновили в этом MR | Поднять версию или не добавлять пакет |
| Та же SCA-находка уже была на основной ветке | Не блок этого MR | Отдельная задача со сроком, как для хостовых CVE |
| Секрет в диффе | Блок всегда | Отзыв и хранение в CI: секреты для CI |
| Низкая серьёзность, стиль, «полезно подумать» | Не блок | Не кормите очередь |
Не блокируйте все исторические находки в первый день: конвейер станет красным навсегда, и его обойдут. Сначала «новое в ветке», потом отдельным спринтом — долг на основной. Quality gate в SonarQube настраивайте под это правило, а не под «ноль issues».
Владелец находки и исключение
Владелец — автор merge request, пока находка в его диффе. Находка на основной ветке — владелец компонента из CODEOWNERS или ведущий команды. ИБ не закрывает SQL-инъекцию за разработчика и не копит сотни тикетов «на потом».
Исключение — одна строка в таблице репозитория (файл вроде security-exceptions.md): идентификатор правила или CVE, почему не чиним, дата пересмотра, кто разрешил (ИБ плюс владелец продукта). Без даты это не исключение, а вечный mute. nosec и аналог в коде без строки в таблице — обход процесса; на ревью такое отклоняйте.
Риск: исключение «чтобы успеть релиз» без даты. Через месяц никто не вспомнит. Срок по умолчанию — 30 дней, иначе находка снова блокер. Что в итоге имеет право выйти в продуктив, решает приёмка: приёмка релиза службой ИБ.
Диагностика
| Симптом | Причина и что делать |
|---|---|
Job с allow_failure: true вечно жёлтый |
Это не процесс, это декорация. Снимите allow_failure для порога из таблицы |
| Сканер есть, тикетов нет | Нет владельца. Правило: красный MR без исправления не мержат, даже если «очень надо» |
| Сто тикетов с основной ветки в первый день | Включили блок на историю. Сузьте порог до нового кода, долг заведите пачкой |
| Разные пороги в трёх репозиториях | Скопируйте одну таблицу в шаблон группы GitLab, иначе команды разъедутся |
Где это в модели зрелости
Материал относится к направлению «Управление уязвимостями» (хаб: уязвимости, карта: карта зрелости). Для SSDLC это гигиена: находка имеет владельца и срок, конвейер умеет сказать «нет». Это не замена сканера хостов и не обучение разработчиков: программа по коду закрывает навык, процесс — дисциплину merge.
Как проверить
- В README или шаблоне группы есть таблица порогов, совпадающая с quality gate.
- Контрольный MR с заведомо опасным новым кодом (на своём репозитории) не сливается, пока находка открыта.
- У SCA-находки на основной ветке есть задача, владелец и дата, а не только строка в UI сканера.
- Файл исключений без просроченных дат; просроченные снова блокеры.
- Секрет в диффе блокирует независимо от серьёзности SAST.
Источники
- NIST SP 800-218 (SSDF) 1.1: csrc.nist.gov.
- OWASP SAMM: owasp.org/www-project-samm.
