Перейти к содержанию

Настроить базовый набор политик безопасности

Контекст

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

Для VCS-проектов на этапе source для старта удобно собрать три отдельные политики:

  • для уязвимостей с публичным эксплойтом и исправлением;
  • для зависимостей с критичными уязвимостями;
  • для слишком молодых компонентов, опубликованных менее месяца назад.

Эти правила помогают быстрее расставить приоритеты, не перегружая команду шумными срабатываниями и не включая блокировки на первом этапе.

Почему именно такой стартовый набор

OpenSSF рекомендует выстраивать работу с зависимостями вокруг понятной приоритизации риска, а OWASP подчёркивает важность раздельной обработки самых опасных и самых управляемых случаев. Исследования CodeScoring показывают, что на старте полезно не смешивать все сигналы в одно правило, а сразу разделять их по разным очередям: отдельно следить за уязвимостями, которые уже эксплуатируются и уже исправимы; отдельно — за зависимостями с критичными уязвимостями; отдельно — за слишком молодыми компонентами, которые требуют дополнительной проверки перед широким использованием.

Что получится

После прохождения сценария в CodeScoring будет три активные политики для VCS-проектов на этапе source:

  • политика для уязвимостей с публичным эксплойтом и исправлением на этапе source;
  • политика для зависимостей с критичными уязвимостями на этапе source;
  • политика для слишком молодых компонентов на этапе source.

После повторного SCA-анализа станет видно, какие из этих правил уже дают полезные срабатывания.

Требования

Перед началом убедитесь, что есть:

  • доступ в CodeScoring с ролью Administrator или Security Manager;
  • хотя бы один подключенный VCS-проект, для которого можно повторно запустить SCA-анализ;
  • понимание, будет ли набор применяться сразу ко всем проектам или сначала к одному пилотному проекту.

Шаги

Шаг 1. Создайте политику для уязвимостей с эксплойтом и исправлением

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

  1. Перейдите в Настройки -> Политики.
  2. Нажмите Создать.
  3. Заполните контекст политики:
    • Название — например, Есть эксплойт и исправление;
    • Этапы — source;
    • Уровень — выберите подходящий уровень критичности;
    • Активно — включите;
    • Блокер — оставьте выключенным.
  4. Если набор настраивается сначала для пилотного проекта, укажите его в поле Проекты. Если нужно распространить правило на все активные проекты, оставьте поля Подразделения, Группы и Проекты пустыми.
  5. В верхней группе условий с логическим выражением И добавьте:
    • Уязвимость имеет эксплойт;
    • Уязвимость имеет исправление.
  6. Нажмите Создать.

Почему блокер лучше не включать сразу

Для стартового набора полезнее сначала проверить, какие реальные срабатывания дает правило и сколько в нем шума. Так проще настроить рабочий процесс команды, не останавливая анализ и не ломая привычный поток работы.

После сохранения в системе появится правило, которое будет создавать алерты по наиболее приоритетным и уже исправимым уязвимостям в VCS-проектах.

Шаг 2. Создайте политику для зависимостей с критичными уязвимостями

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

  1. Откройте политику, созданную на предыдущем шаге.
  2. Нажмите Создать копию.
  3. Измените основные поля:
    • Название — например, Критичная уязвимость в зависимости;
    • Этапы — оставьте source;
    • Активно — оставьте включенным;
    • Блокер — оставьте выключенным.
  4. Удалите прежние условия.
  5. В верхней группе условий выберите логическое выражение ИЛИ и добавьте:
    • Уровень угрозы CVSS2 = критический;
    • Уровень угрозы CVSS3 = критический;
    • Уровень угрозы CVSS4 = критический.
  6. Нажмите Создать.

Теперь в наборе есть отдельное правило для зависимостей, у которых есть хотя бы одна критичная оценка по одной из версий CVSS.

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

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

Почему это правило лучше оставить информирующим

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

  1. В разделе Настройки -> Политики снова нажмите Создать.
  2. Заполните контекст политики:
    • Название — например, Компонент младше 30 дней;
    • Этапы — source;
    • Активно — включите;
    • Блокер — оставьте выключенным.
  3. Если набор настраивается постепенно, при необходимости укажите пилотный проект в поле Проекты.
  4. В верхней группе условий выберите логическое выражение ИЛИ и добавьте:
    • Возраст зависимости (в днях) < 30;
    • при необходимости — условие на отсутствие информации о возрасте зависимости.
  5. Нажмите Создать.

Если нужно расширить правило или выбрать другой порог риска, список доступных критериев описан в настройке политик.

Что важно знать про возраст зависимости

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

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

Шаг 4. Повторно запустите анализ и проверьте первые срабатывания

Политики начинают работать во время анализа, поэтому после настройки важно сразу проверить, что хотя бы правила этапа source реально участвуют в процессе.

  1. Откройте один из проектов, к которому должны применяться новые политики.
  2. На странице проекта нажмите Запустить SCA.
  3. Дождитесь завершения анализа.
  4. Откройте раздел Алерты.
  5. Проверьте, появились ли новые срабатывания по политикам:
    • для уязвимостей с эксплойтом и исправлением;
    • для прямых зависимостей с критичными уязвимостями;
    • для слишком молодых компонентов.

На этом этапе набор уже работает: все три правила начинают давать алерты после анализа и помогают разнести по разным типам самые важные случаи для разбора.

Результат

Сценарий можно считать завершенным, если:

  • в Настройки -> Политики сохранены три активные политики из этого набора;
  • у всех трех правил указан этап source и заданы нужные критерии;
  • правило для слишком молодых компонентов использует условие Возраст зависимости (в днях) < 30 и остается неблокирующим;
  • после повторного анализа в разделе Алерты можно проверить первые срабатывания по каждому типу политики.

После этого в платформе уже есть минимальный набор защитных правил, который помогает отсечь наиболее рискованные компоненты и быстрее разбирать действительно важные находки.

Что дальше

Страница была полезна?