SCA-анализ в CI: OWASP Dependency-Check с кэшем и suppression

OWASP Dependency-Check в сборке: где узкое место

OWASP Dependency-Check ставят в сборку как обязательный шаг: пока проверка библиотек не прошла, артефакт не публикуется. На проекте с сотнями прямых и транзитивных зависимостей этот шаг быстро становится узким местом сборки — он один занимает больше времени, чем компиляция, тесты и упаковка вместе взятые.

Первая причина — работа с базой уязвимостей. На чистом агенте каждый запуск заново выкачивает и перестраивает локальный индекс: десятки тысяч записей, длительные сетевые операции, плавающие таймауты. Сборка падает не из-за кода, а из-за недоступности внешнего источника, и перезапуск не гарантирует, что следующий прогон пройдёт.

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

Третья — невоспроизводимость. Результат зависит от момента обновления базы и от того, какие модули успели загрузиться. Тот же коммит сегодня зелёный, завтра красный, а сравнить два отчёта между запусками нечем: наборы находок несопоставимы.

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

Что меняется после внедрения SCA-контроля

До внедрения анализ зависимостей запускался на каждом изменении целиком, и время сборки росло линейно вместе с числом модулей. Чем больше сервисов в репозитории, тем дольше ждать вердикт — и тем чаще проверку обходили стороной.

OWASP Dependency-Check вместе с кэшем результатов анализа меняет эту арифметику: пересчитываются только изменённые ветки дерева зависимостей, остальное поднимается из кэша. Время сборки перестаёт расти вместе с числом модулей и определяется реальным объёмом правок.

Ключ кэша привязан к файлу блокировки зависимостей и версии базы уязвимостей, поэтому повторный анализ на той же ревизии даёт идентичный отчёт. Это и есть воспроизводимость проверки: результат в среде сборки и на машине инженера совпадает, спорную находку можно разобрать локально, не дожидаясь очереди.

Дальше работает политика подавления срабатываний. Каждое исключение — отдельная запись с обоснованием и сроком пересмотра: уязвимая функция не вызывается, транзитивная зависимость приходит только в тестовую область. Доля ложных срабатываний падает в разы — в отчёте остаются десятки реальных находок вместо сотен шумовых.

Сборка останавливается при превышении заданного порога серьёзности, поэтому класс отказов «уязвимая библиотека уехала в релиз» закрывается на входе. Проверка перестаёт быть тормозом и работает фильтром: дальше проходят только разобранные зависимости.

Режимы запуска проверки зависимостей: сравнение

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

Как режимы сочетаются

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

Порядок внедрения: от аудита до передачи

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

1. Аудит конвейера сборки: фиксируем, где именно собираются артефакты, какие шаги кэшируются, сколько времени занимает чистая сборка и где в ней появляются внешние библиотеки.
2. Инвентаризация зависимостей: собираем перечень прямых и транзитивных компонентов, помечаем устаревшие и заброшенные, отмечаем модули с самым широким деревом зависимостей.
3. Схема кэша: OWASP Dependency-Check тянет базу уязвимостей при каждом запуске — выносим её в отдельный том, привязанный к версии базы, чтобы повторные сборки не скачивали её заново и не теряли результаты при падении сети.
4. Настройка запуска: выбираем режим сканирования, набор форматов отчёта, момент вызова относительно тестов и порог, при котором сборка останавливается.
5. Правила подавления: описываем срабатывания, которые не относятся к нашему коду, с обязательным комментарием и сроком пересмотра — иначе шум быстро обесценивает отчёт.
6. Проверка на реальных сборках: прогоняем конфигурацию на нескольких модулях, замеряем прирост времени сборки и долю срабатываний, которые действительно требуют правок.
7. Передача регламентов: отдаём документ о порядке обновления базы, разборе новых срабатываний и пересмотре подавлений, проводим разбор с командой и остаёмся на связи на период первых изменений.

Комплект поставки: конфигурации, политики, регламенты

Комплект поставки собран так, чтобы анализ зависимостей жил в вашем репозитории без нашего участия. После внедрения OWASP Dependency-Check остаются конфигурации, политики и инструкции — их достаточно, чтобы новый инженер поднял проверку и понял, почему отчёт выглядит именно так.

• Конфигурация анализа — единый профиль: список сканируемых модулей, глубина разбора транзитивных зависимостей, форматы отчётов и условие выхода шага сборки с ненулевым кодом.
• Схема кэша — к какому набору файлов привязан ключ, когда он сбрасывается и как хранится база уязвимостей, чтобы повторные прогоны не тянули её заново.
• Списки подавления — файл в формате XML, где у каждой записи есть обоснование, владелец и срок пересмотра; запись без комментария не проходит ревью.
• Пороги срабатывания — отдельные правила для релизной ветки и для повседневных: что останавливает сборку, а что уходит предупреждением в отчёт.
• Инструкции для разработчиков — как прогнать проверку локально до коммита, как читать отчёт по транзитивным зависимостям и когда заводится подавление.
• Регламент обновления базы уязвимостей — расписание и контроль фактического обновления: без этого отчёт строится по устаревшим данным и выглядит благополучно на пустом месте.

Всё это лежит в репозитории и проходит ревью как код: изменения порогов видно в истории, а на записи подавления можно ссылаться при разборе инцидента.

Кейс: как изменились время сборки и число срабатываний

На одном конвейере проверку зависимостей запускали целиком на каждый коммит: инструмент скачивал свежую базу уязвимостей, прогонял все модули и возвращал отчёт на несколько сотен строк. Сборка занимала 16 минут, а шаг стоял в обязательных — правка небольшого сервиса ждала полного прогона.

Что изменили

Базу OWASP Dependency-Check начали кэшировать между запусками и обновлять по расписанию, а не на каждом коммите; ключом стала контрольная сумма файла зависимостей — при её изменении база перечитывается, при неизменной берётся из хранилища. Завели список подавлений: у каждого исключения есть идентификатор уязвимости, модуль, обоснование и дата пересмотра, поэтому это решение с владельцем, а не строка, чтобы сборка прошла.

Что стало

Типичная сборка сократилась с 16 до 4 минут, полный прогон с обновлением базы остался в ночном расписании. Доля шумовых срабатываний упала с 78% до 15% — в основном за счёт исключений для зависимостей тестового контура и уязвимостей без применимого вектора атаки.

Реальные находки стали видны: за квартал до команды дошли три критичных уязвимости в библиотеках, одна — в компоненте, который подтягивался транзитивно и не попадал в ручной просмотр. Доверие к проверке держится на том, что отчёт короткий, а каждое срабатывание кто-то уже разобрал.

Чем Dependency-Check отличается от проверки лицензий?

Dependency-Check отвечает на один вопрос: какие известные уязвимости есть в сторонних библиотеках проекта. Он читает манифесты и lock-файлы, сверяет версии с базами уязвимостей и отдаёт отчёт с критичностью и путём до проблемной транзитивной зависимости — но код самого проекта не разбирает.

Проверка лицензий решает другую задачу: можно ли поставлять продукт с этой библиотекой. Важны тип лицензии, копилефт-условия и требования атрибуции — результат здесь правовой риск, а не уязвимость. Сканер покажет лицензию в отчёте, но вердикт остаётся за юристом.

Поиск секретов и статический анализ работают по нашей кодовой базе: один ищет ключи и токены в файлах и истории коммитов, второй — небезопасные потоки данных. Уязвимость внутри транзитивной зависимости не увидит ни тот, ни другой.

Границы ответственности проходят по источнику данных: сканирование зависимостей читает манифесты, статический анализ и поиск секретов — наш код. Пересечения возникают в конвейере, поэтому подавления ложных срабатываний держим централизованно — иначе одна библиотека всплывает в трёх отчётах под разными формулировками.

Технические сомнения: кэш, шум, обновление базы

Инженерные сомнения вокруг SCA-контура обычно одни и те же: насколько свежа база в кэше, что делать в закрытом контуре и не превратится ли подавление срабатываний в свалку. Ниже — короткие ответы по каждому пункту, с тем, что попадает в отчёт и конфигурацию сборки.

Сборка идёт без выхода во внешнюю сеть — обновление возможно?

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