Настроить базовый набор политик безопасности
Контекст
После первого анализа в CodeScoring.SCA обычно быстро появляется много данных о зависимостях и уязвимостях. Базовый набор правил нужен, чтобы сразу отделить самые приоритетные случаи от общего потока результатов и быстрее понять, на что реагировать в первую очередь.
Для VCS-проектов на этапе source для старта удобно собрать три отдельные политики:
- для уязвимостей с публичным эксплойтом и исправлением;
- для зависимостей с критичными уязвимостями;
- для слишком молодых компонентов, опубликованных менее месяца назад.
Эти правила помогают быстрее расставить приоритеты, не перегружая команду шумными срабатываниями и не включая блокировки на первом этапе.
OpenSSF рекомендует выстраивать работу с зависимостями вокруг понятной приоритизации риска, а OWASP подчёркивает важность раздельной обработки самых опасных и самых управляемых случаев. Исследования CodeScoring показывают, что на старте полезно не смешивать все сигналы в одно правило, а сразу разделять их по разным очередям: отдельно следить за уязвимостями, которые уже эксплуатируются и уже исправимы; отдельно — за зависимостями с критичными уязвимостями; отдельно — за слишком молодыми компонентами, которые требуют дополнительной проверки перед широким использованием.
Что получится
После прохождения сценария в CodeScoring будет три активные политики для VCS-проектов на этапе source:
- политика для уязвимостей с публичным эксплойтом и исправлением на этапе
source; - политика для зависимостей с критичными уязвимостями на этапе
source; - политика для слишком молодых компонентов на этапе
source.
После повторного SCA-анализа станет видно, какие из этих правил уже дают полезные срабатывания.
Требования
Перед началом убедитесь, что есть:
- доступ в CodeScoring с ролью
AdministratorилиSecurity Manager; - хотя бы один подключенный VCS-проект, для которого можно повторно запустить SCA-анализ;
- понимание, будет ли набор применяться сразу ко всем проектам или сначала к одному пилотному проекту.
Шаги
Шаг 1. Создайте политику для уязвимостей с эксплойтом и исправлением
Такое правило помогает быстро выделить не просто уязвимости, а те случаи, где атака уже практична и при этом есть понятный путь к исправлению.
- Перейдите в
Настройки -> Политики. - Нажмите Создать.
- Заполните контекст политики:
- Название — например,
Есть эксплойт и исправление; - Этапы —
source; - Уровень — выберите подходящий уровень критичности;
- Активно — включите;
- Блокер — оставьте выключенным.
- Название — например,
- Если набор настраивается сначала для пилотного проекта, укажите его в поле Проекты. Если нужно распространить правило на все активные проекты, оставьте поля Подразделения, Группы и Проекты пустыми.
- В верхней группе условий с логическим выражением И добавьте:
- Уязвимость имеет эксплойт;
- Уязвимость имеет исправление.
- Нажмите Создать.

Для стартового набора полезнее сначала проверить, какие реальные срабатывания дает правило и сколько в нем шума. Так проще настроить рабочий процесс команды, не останавливая анализ и не ломая привычный поток работы.
После сохранения в системе появится правило, которое будет создавать алерты по наиболее приоритетным и уже исправимым уязвимостям в VCS-проектах.
Шаг 2. Создайте политику для зависимостей с критичными уязвимостями
Отдельное правило для критичных уязвимостей помогает вынести самые тяжёлые случаи в самостоятельный поток обработки. Для стартового набора это полезно, потому что такие находки легче отдельно контролировать и не смешивать с остальными уровнями риска.
- Откройте политику, созданную на предыдущем шаге.
- Нажмите Создать копию.
- Измените основные поля:
- Название — например,
Критичная уязвимость в зависимости; - Этапы — оставьте
source; - Активно — оставьте включенным;
- Блокер — оставьте выключенным.
- Название — например,
- Удалите прежние условия.
- В верхней группе условий выберите логическое выражение ИЛИ и добавьте:
- Уровень угрозы CVSS2 =
критический; - Уровень угрозы CVSS3 =
критический; - Уровень угрозы CVSS4 =
критический.
- Уровень угрозы CVSS2 =
- Нажмите Создать.
Теперь в наборе есть отдельное правило для зависимостей, у которых есть хотя бы одна критичная оценка по одной из версий CVSS.
Шаг 3. Создайте информирующую политику для слишком молодых компонентов
Такое правило помогает вынести в отдельный поток срабатываний зависимости, которые были опубликованы совсем недавно. Для стартового набора это полезнее, чем сразу делать правило блокирующим: команда получает отдельный сигнал для дополнительной проверки новых пакетов и версий, не смешивая его ни с уязвимостями, ни с обычным плановым обновлением.
Для стартового набора полезнее сначала увидеть такие компоненты как отдельный сигнал и понять, как часто они появляются в проектах. Если сделать такую политику блокирующей слишком рано, можно остановить рабочие процессы из-за обычных обновлений библиотек ещё до того, как команда согласует правила проверки новых версий.
- В разделе
Настройки -> Политикиснова нажмите Создать. - Заполните контекст политики:
- Название — например,
Компонент младше 30 дней; - Этапы —
source; - Активно — включите;
- Блокер — оставьте выключенным.
- Название — например,
- Если набор настраивается постепенно, при необходимости укажите пилотный проект в поле Проекты.
- В верхней группе условий выберите логическое выражение ИЛИ и добавьте:
- Возраст зависимости (в днях) <
30; - при необходимости — условие на отсутствие информации о возрасте зависимости.
- Возраст зависимости (в днях) <
- Нажмите Создать.
Если нужно расширить правило или выбрать другой порог риска, список доступных критериев описан в настройке политик.
Платформа определяет дату публикации зависимости для поддерживаемых экосистем. Перед тем как распространять такое правило на все проекты, его лучше сначала проверить на пилотном проекте и убедиться, что критерий отрабатывает так, как ожидается на ваших пакетах и источниках.
После этого в отдельные алерты начнут попадать компоненты, которые появились слишком недавно и поэтому требуют дополнительной проверки перед широким использованием в проектах.
Шаг 4. Повторно запустите анализ и проверьте первые срабатывания
Политики начинают работать во время анализа, поэтому после настройки важно сразу проверить, что хотя бы правила этапа source реально участвуют в процессе.
- Откройте один из проектов, к которому должны применяться новые политики.
- На странице проекта нажмите Запустить SCA.
- Дождитесь завершения анализа.
- Откройте раздел
Алерты. - Проверьте, появились ли новые срабатывания по политикам:
- для уязвимостей с эксплойтом и исправлением;
- для прямых зависимостей с критичными уязвимостями;
- для слишком молодых компонентов.
На этом этапе набор уже работает: все три правила начинают давать алерты после анализа и помогают разнести по разным типам самые важные случаи для разбора.
Результат
Сценарий можно считать завершенным, если:
- в
Настройки -> Политикисохранены три активные политики из этого набора; - у всех трех правил указан этап
sourceи заданы нужные критерии; - правило для слишком молодых компонентов использует условие Возраст зависимости (в днях) < 30 и остается неблокирующим;
- после повторного анализа в разделе
Алертыможно проверить первые срабатывания по каждому типу политики.
После этого в платформе уже есть минимальный набор защитных правил, который помогает отсечь наиболее рискованные компоненты и быстрее разбирать действительно важные находки.
