Security gate релиза: как SBOM превращает обновление зависимостей в контролируемый процесс

В одной из свежих проверок API-платформы исходная сборка содержала 57 зарегистрированных уязвимостей. После работы с зависимостями осталось семь, а находок уровней Critical и High в финальной поставке не было. Такой результат появляется, когда команда заранее определяет состав релиза, сверяет его с базами уязвимостей и останавливает выпуск по чётко заданному правилу.

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

Релиз состоит из большего, чем собственный код

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

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

SBOM фиксирует состав, который действительно выпускают

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

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

Опись стоит создавать после фиксации состава релиза. Если сформировать её слишком рано, а затем заменить зависимость или изменить образ контейнера, проверка потеряет связь с итоговой поставкой. В процессах с Kubernetes важно так же контролировать версии базовых образов и компонентов, попадающих в контейнеры.

Сканер находит совпадения, решение принимает правило релиза

Следующий шаг — сопоставить компоненты из SBOM с данными об известных уязвимостях. В описанном случае для этого использовали Grype: сканер сверяет пакеты и версии с записями CVE и GHSA, затем формирует список находок по конкретным библиотекам.

Такой список ещё нельзя считать итоговым риском. Для каждой записи требуется проверить, затрагивает ли она используемую версию, есть ли исправление, доступен ли путь эксплуатации в данном продукте и какому уровню критичности соответствует находка. В российской инфраструктуре может потребоваться дополнительное сопоставление с Банком данных угроз безопасности информации ФСТЭК России.

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

Порог готовности должен останавливать выпуск

Security gate превращает результаты сканирования в правило, которое влияет на выпуск. Для упомянутой версии API-платформы им стало отсутствие в финальной сборке уязвимостей Critical и High, зарегистрированных в БДУ ФСТЭК. Пока хотя бы одна такая запись сохраняется, сборка не проходит в релиз.

Это правило удобно именно своей проверяемостью. Оно не требует угадывать настроение ревьюера и даёт команде единый маршрут: обновить пакет, заменить компонент, заново собрать поставку, сгенерировать SBOM и повторить проверку. В рассмотренном релизе были устранены 10 Critical-находок, 24 High и четыре Low; число Medium сократилось с 19 до семи.

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

Medium-уязвимости требуют маршрута, а не забвения

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

Автоматическое разрешение на Medium и Low здесь было бы ошибкой. Иногда уязвимость средней критичности важна из-за конфигурации, публичного доступа к сервису или характера данных. Полезная проверка перед выпуском — посмотреть, открыт ли уязвимый путь в реальном развёртывании и можно ли компенсировать риск настройкой, ограничением доступа или обновлением в ближайшем цикле.

Отчёт имеет срок действия

Базы уязвимостей пополняются постоянно, а оценка относится к конкретному набору компонентов на определённую дату. Сборка, которая проходила security gate месяц назад, не получает бессрочный статус безопасности. При следующем релизе или обновлении зависимостей опись и сканирование нужно повторять.

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