Метрики SCA для безопасных релизов: CVSS, сроки, исключения

Какая проблема решается метриками SCA

SCA-сканеры сегодня есть почти у всех: в CI, в репозитории, в контейнерных образах. Но релизы все равно выходят с рисками, потому что сам факт находки не отвечает на главный вопрос: что делать прямо сейчас и кто за это отвечает.

Типичная картина: сканер показывает десятки уязвимостей в зависимостях. Часть из них не эксплуатируема в вашем контексте, часть давно известна, а часть относится к dev-зависимостям. В итоге команда либо игнорирует отчет, либо начинает чинить все подряд и срывает сроки.

Конфликт обычно один и тот же: скорость релиза против требований ИБ. Разработчикам важно доставить функциональность, а ИБ - не пропустить критичный риск в прод. Без общих правил разговор быстро превращается в спор про ощущения: "это важно" против "это не успеем".

Метрики SCA переводят сканы в понятные числа и пороги. Их можно использовать как правило, а не как мнение. Они помогают отделить шум от реального риска, заранее согласовать компромиссы и сделать процесс предсказуемым.

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

Простой пример. Команда готовит релиз, сканер находит CVE с высоким баллом в популярной библиотеке. Без метрик начинается хаос. С метриками видно: уязвимость затрагивает только опциональный модуль, патч доступен, а политика требует исправить такие находки за 7 дней. Тогда решение ясное: релиз либо переносится на 1-2 дня ради обновления, либо оформляется временное исключение с датой окончания и компенсирующей мерой (например, отключить модуль). Такое решение можно спокойно защитить перед ИБ.

Что реально измеряют Mend, Snyk и Sonatype

SCA (Software Composition Analysis) - это проверка того, из каких сторонних библиотек и компонентов состоит ваше приложение. Инструмент смотрит версии зависимостей, ищет известные уязвимости и проблемы с лицензиями. По сути, он отвечает на вопрос: что именно мы тащим в прод вместе с нашим кодом?

Mend, Snyk и Sonatype в базовом наборе делают похожие вещи: строят список зависимостей, сопоставляют его с базами уязвимостей, показывают приоритет и помогают закрепить правила в виде политики. Разница чаще не в том, что они "видят" уязвимости, а в том, как они собирают данные, объясняют риск и поддерживают процесс исправления.

Оценки уязвимостей берутся не из одного источника. Обычно это сочетание NVD, бюллетеней вендоров, данных из сообществ и собственных исследований поставщика инструмента. Поэтому одна и та же CVE может иметь разные оценки, разные описания затронутых версий и даже разный статус "эксплуатируется/не эксплуатируется". На практике это означает, что метрика "сколько у нас критических" зависит и от выбранных источников и правил нормализации, а не только от реального риска.

Ложные срабатывания и пробелы чаще всего появляются в четырех местах:

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

Важно помнить: Mend, Snyk и Sonatype измеряют не "безопасность приложения" целиком, а качество инвентаризации и уровень известного риска в цепочке поставки. Чем честнее вы понимаете границы измерений, тем проще выбрать метрики, которые реально помогают выпускать релизы безопаснее.

Политика CVSS: пороги и контекст, а не только балл

CVSS удобен как общий язык, но сам по себе не равен риску для вашего продукта. Одна и та же уязвимость с CVSS 9.8 может быть критичной в публичном API и почти не влиять на закрытый сервис без внешнего доступа. Поэтому метрика должна учитывать не только балл, но и то, где и как используется компонент.

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

Пороги, которые обычно приживаются

Часто начинают с простого набора правил:

• блокировать релиз при CVSS >= 9.0, если есть эксплойт или уязвимость в доступном извне контуре
• не блокировать, но заводить обязательную задачу при 7.0-8.9 с понятным сроком исправления
• разрешать релиз при 4.0-6.9, если риск принят и есть план обновления
• не считать "0-3.9" автоматом безопасным, если уязвимость попадает в критичный путь данных

Контекст: что добавить к баллу

Чтобы Mend, Snyk или Sonatype давали полезные сигналы, добавьте поверх CVSS несколько проверок: есть ли фиксированная версия, используется ли уязвимый код на практике, и можно ли атаковать компонент в вашей конфигурации.

Пример: библиотека с CVSS 8.1 попала в проект транзитивно. Если она сидит только в тестовых зависимостях или не попадает в сборку продакшена, это не повод стопорить релиз. Но если транзитивная зависимость попадает в runtime и стоит на периметре (например, веб-сервер), учитывайте ее как полноправную и требуйте исправление или риск-акцепт со сроком.

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

Метрики покрытия и качества инвентаризации зависимостей

Даже лучший SCA-сканер бесполезен, если он видит только часть кода или читает зависимости "как попало". Поэтому сначала измерьте не уязвимости, а качество входных данных: что попадает в анализ и насколько полная получается ведомость компонентов.

Покрытие сканирования: что реально попадает в анализ

Покрытие удобнее считать не одной галочкой "сканируем/не сканируем", а несколькими долями, которые показывают слепые зоны. Например: сколько репозиториев сканируется в CI (а не вручную), какие ветки реально проверяются (main и релизные), какие типы артефактов (контейнеры, пакеты, образы) попадают в SCA, и как часто скан пропускается из-за ошибок конфигурации.

Качество инвентаризации: можно ли доверять списку зависимостей

Вторая группа метрик отвечает на вопрос: насколько точный у нас список компонентов. Здесь полезно считать долю проектов с корректными манифестами (package-lock, pom.xml, requirements.txt). Если манифесты отсутствуют или не фиксируют версии, один и тот же проект будет давать разные результаты скана, а споры про риск станут бесконечными.

Дополнительно измеряйте "неизвестные зависимости": компоненты без понятного источника, версии или владельца. Практический маркер - сколько находок нельзя привязать к репозиторию, пакету или команде за разумное время.

И отдельно полезна "свежесть" зависимостей: доля компонентов, которые отстают больше чем на N мажорных версий. Бывает, что в релизе нет критических CVE, но половина библиотек отстает на 3 мажора. Это сигнал, что следующий цикл обновлений будет болезненным, и лучше заранее выделить время, пока обновления еще помещаются в план релизов.

Сроки исправления: SLA, MTTR и возраст уязвимостей

Если вы хотите, чтобы релизы становились безопаснее, одних "сколько уязвимостей нашли" мало. Важнее, как быстро команда закрывает риск и не превращается ли очередь исправлений в бесконечный хвост.

SLA по уязвимостям стоит задавать не "в целом", а по уровню критичности и типу артефакта (приложение, контейнер, библиотека). Для старта часто хватает такого каркаса:

• Critical: исправить или компенсировать за 7 дней
• High: за 30 дней
• Medium: за 90 дней
• Low: по плану, но без роста долга

Дальше появляется вопрос: чем измерять скорость. MTTR (среднее время исправления) удобно для отчета, но его легко "портят" редкие долгие задачи. Поэтому рядом держите медиану времени исправления: она честнее показывает типичную скорость команды. Если MTTR 40 дней, а медиана 12, значит, большинство правок делается быстро, но есть несколько залежавшихся проблем, которые и создают риск.

Третья метрика, без которой SLA не работает, - возраст уязвимостей (age of vulns): сколько находок старше допустимого срока. Важно показывать не только число, но и где именно оно находится: по репозиторию, сервису или команде. Тогда разговор становится предметным: не "у нас 200 High", а "в сервисе оплаты 14 High старше 30 дней".

И, наконец, динамика бэклога. Представьте: каждую неделю сканер находит 20 новых High, а закрывают 10. Формально вы "работаете", но долг растет. Хороший отчет показывает тренд за 4-8 недель: вы чистите очередь или копите ее, и какие категории (например, транзитивные зависимости) дают основной прирост.

Метрики релизной готовности: что реально тормозит поставку

Когда SCA подключают к CI/CD, релизы чаще всего стопорятся не из-за самой уязвимости, а из-за того, как принимается решение: блокировать, исправлять сейчас или оформлять исключение. Поэтому метрики релизной готовности должны подсвечивать узкие места процесса.

Полезная отправная точка - блокировки сборок политикой. Mend, Snyk и Sonatype обычно позволяют увидеть, какие правила сработали (CVSS, наличие эксплойта, тип зависимости, лицензия). Если заметная доля сборок падает из-за одного и того же правила, это сигнал: либо правило слишком жесткое для текущей реальности, либо у команды нет быстрого пути обновить зависимость.

Чтобы понимать, почему поставка тормозит, обычно хватает нескольких показателей:

• процент сборок, заблокированных политикой, с разбивкой по причинам
• доля релизов, прошедших без исключений
• время до решения по критичной находке (от появления в пайплайне до вердикта: фикс, компенсирующая мера или исключение)
• качество триажа: доля находок, признанных нерелевантными (ошибочный матч, неиспользуемый компонент, недостижимый код)

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

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

Исключения без хаоса: правила, сроки и контроль риск-акцепта

Исключения в SCA нужны, но именно они чаще всего превращают процесс в бардак: уязвимость "временно" разрешили, а потом о ней забыли. Чтобы метрики работали, исключение должно быть управляемым решением: с владельцем, сроком и проверкой.

Обычно исключение допустимо в трех случаях: для зависимости нет исправления (нет патча или обновление ломает совместимость), срабатывание ложное (CVE неверно привязан к пакету), или есть компенсирующие меры, которые снижают риск до приемлемого уровня (например, сервис недоступен извне, включены WAF-правила, отключена уязвимая функция).

Минимальные правила для исключений

Хороший минимум выглядит так:

• срок действия: исключение выдается на ограниченный период (например, 30-90 дней) и автоматически попадает в пересмотр
• владелец: у каждого исключения есть ответственный со стороны продукта, который следит за пересмотром
• обоснование: коротко фиксируется причина и что сделано для снижения риска
• утверждение: риск-акцепт подписывает назначенный владелец риска (часто руководитель продукта или ИБ, в зависимости от критичности)
• проверка: при каждом релизе проверяется, не просрочено ли исключение, и не появился ли фикс

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

Метрики по исключениям

Не усложняйте. Часто достаточно четырех чисел: количество активных исключений, средний возраст исключений, доля просроченных исключений, доля исключений по причинам (нет фикса, ложное срабатывание, компенсирующие меры). Эти метрики быстро показывают, где риск копится незаметно, даже если отчеты Mend, Snyk или Sonatype выглядят "зелеными".

Отчеты для ИБ и руководства: формат, который читают

Отчет по SCA не должен быть выгрузкой из Mend, Snyk или Sonatype на 40 страниц. Для ИБ и руководства важны ответы на простые вопросы: где риск растет, где мы не укладываемся в сроки, и что блокирует релиз прямо сейчас. Если отчет помогает принять решение за 5 минут, его будут читать.

Что ИБ обычно нужно увидеть

ИБ смотрит на динамику и дисциплину, а не на разовый снимок. Хороший отчет показывает тренды по месяцам, просрочки SLA и список критичных открытых рисков, которые реально остаются в продакшене. Отдельно важно отмечать исключения (risk acceptance): кто согласовал, до какого числа действует, и что будет сделано вместо исправления.

Чтобы не перегружать аудиторию, держите набор показателей коротким. Например, KPI можно свести к следующему:

• количество открытых Critical/High уязвимостей в релизной ветке и изменение за период
• доля уязвимостей, исправленных в SLA
• MTTR по уязвимостям High
• возраст самых старых открытых High (в днях)
• количество активных исключений и доля просроченных

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

Срезы, которые помогают управлять

Один и тот же набор KPI стоит показывать в нескольких разрезах: по продукту или сервису, по команде, по поставщику (какие библиотеки создают долг), по типу артефакта (контейнеры, приложения, образы). Тогда видно, где проблема в конкретном продукте, а где - в процессе.

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

Пошагово: как внедрить метрики SCA в релизный процесс

Чтобы метрики работали, их нужно привязать к решению: выпускаем релиз или нет. Начните с простого: одна цель (снизить риск в поставке), три стороны с ролями (разработка, DevOps, ИБ) и понятное правило эскалации, если релиз блокируется.

Дальше выберите небольшой набор показателей и порогов. Если метрик слишком много, ими перестают пользоваться. Обычно достаточно 5-7 метрик, которые действительно влияют на релиз.

Минимальный план внедрения

• зафиксируйте владельцев: кто смотрит отчеты, кто принимает риск, кто меняет пайплайн
• определите пороги для блокировки: например, 0 критических уязвимостей без плана исправления или подтвержденного риск-акцепта
• настройте триаж: кто и как быстро подтверждает, что находка реальная и касается продакшена
• оформите исключения как управляемые записи: причина, владелец решения, дата окончания, компенсирующие меры
• автоматизируйте сбор в CI/CD и добавьте регулярный отчет для ИБ и релиз-менеджера

После запуска закрепите ритм. Раз в неделю смотрите просрочки по SLA, возраст уязвимостей и список исключений, у которых подходит срок. Политику корректируйте небольшими шагами: если релизы постоянно блокируются из-за одного типа зависимостей, проблема обычно в правилах обновления или в отсутствии владельца компонента.

Пример: команда перед релизом видит уязвимость CVSS 9.8 в транзитивной библиотеке. Решение должно быть не "отложить", а выбрать одно из двух: срочное обновление с фиксированной датой или исключение на 14 дней с описанием, почему риск приемлем и какие меры снижают его прямо сейчас.

Пример сценария: один релиз, три находки и решение по риску

Команда выпускает релиз раз в две недели. Проект живет на десятках библиотек, а SCA-скан идет в пайплайне перед сборкой. В этот раз инструмент (неважно, Mend, Snyk или Sonatype) находит три проблемы в зависимостях.

Политика простая: блокируем релиз, если есть уязвимость с CVSS 9.0+ в проде и есть подтвержденный эксплойт или уязвимый код реально используется. CVSS 7.0-8.9 не блокирует автоматически, но требует плана исправления со сроком. Все, что ниже, идет в бэклог, если нет особых условий.

На релизе всплывают такие находки:

• CVSS 9.8 в библиотеке логирования: зависимость прямая, есть эксплойт, обновление доступно
• CVSS 8.1 в транзитивной библиотеке: эксплойта нет, обновление требует смены мажорной версии
• CVSS 6.5, но библиотека используется только в dev-тестах

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

Решение по релизу меняют три метрики:

• доля блокирующих уязвимостей по политике CVSS с учетом контекста (эксплойт, среда, достижимость)
• возраст уязвимости и MTTR по похожим находкам в прошлом
• количество активных исключений и сколько из них просрочены

В итоге первую уязвимость чинят до релиза (обновляют зависимость), вторую выпускают с риск-акцептом на 14 дней и задачей миграции, третью помечают как не влияющую на прод и не тратят время команды.

Быстрый чеклист: готова ли ваша метрика-программа

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

5 вопросов, на которые нужен четкий ответ

• есть ли формальные пороги по серьезности уязвимостей (например, по CVSS) и правила, когда релиз блокируется, а когда допускается только с риск-акцептом
• есть ли сроки исправления по уровням критичности и видны ли просрочки по каждому продукту и команде
• ведете ли вы исключения как управляемые записи: причина, владелец решения, дата окончания, условия пересмотра
• получает ли ИБ регулярный отчет в одном формате: тренды за период и список открытых критичных рисков, которые остаются в проде
• разбираете ли вы причины задержек: нет патча, конфликт версий, ложное срабатывание, зависимость не используется, ломается совместимость

Как понять, что это не формальность

Хороший признак: по итогам недели вы можете назвать 2-3 конкретных препятствия и владельцев действий. Плохой признак: обсуждение сводится к спору про "высокий/средний", и никто не отвечает за сроки.

Простой тест: на планировании релиза возьмите одну критичную находку и попросите команду за 10 минут заполнить карточку решения: блокируем или принимаем риск, до какой даты, что делаем дальше. Если это занимает часы и заканчивается перепиской, метрика-программа пока не готова к управлению релизами.

Следующие шаги: как перейти от сканов к управляемым релизам

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

Рабочая стартовая схема: выбрать один продукт (Mend, Snyk или Sonatype) и зафиксировать базовую линию метрик на текущем состоянии. Через 2-4 недели появится честная картинка: сколько уязвимостей реально блокируют релиз, сколько живут месяцами, где больше всего исключений.

Минимальный набор действий, который обычно дает быстрый эффект:

• утвердить 2-3 порога по CVSS с контекстом (например, отдельное правило для уязвимостей с эксплойтом)
• ввести SLA исправления для Critical и High и назначить владельцев
• ограничить исключения по времени (например, 30-90 дней) и требовать причину и компенсирующие меры
• согласовать один понятный отчет для ИБ и руководства: тренд, долги, исключения, статус релизов

Согласование политики между разработкой и ИБ лучше вести не вокруг абстрактного "идеально безопасно", а вокруг рисков конкретного продукта. Например, если SCA находит High в библиотеке, но компонент не используется в рантайме, релиз можно не блокировать. Но стоит зафиксировать решение (в том числе срок) и не превращать это в вечное "потом".

Интегратора имеет смысл подключать, когда нужно не просто включить скан, а закрепить процесс: правила в CI/CD, единые шаблоны риск-акцепта, роли, регулярные отчеты и обучение команд.

Если вы работаете в госсекторе или крупной организации, где важны формальная отчетность и контроль сроков, GSE.kz (gse.kz) может помочь с подбором и внедрением SCA как части системной интеграции: настройкой политик и отчетов для ИБ, интеграцией в пайплайны и последующей поддержкой 24/7.