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

Настройка политик

Принципы работы

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

Политики можно создавать для:

  • всей организации;
  • подразделения;
  • группы проектов;
  • проекта;
  • окружения разработки;
  • репозитория;
  • типа компонента.

Механизм политик учитывает указанный этап разработки программного обеспечения: от поступления сторонних компонентов в периметр организации до отслеживания сборок и написания нового кода.

Политики настраиваются по условиям, объединенным логическими выражениеми И/ИЛИ. Помимо стандартных настроек политик безопасности по уровню критичности уязвимостей, условия могут быть настроены согласно метаданным компонента: дата релиза, лицензия, автор и другим. Всего поддерживается 40+ типизированных условий. Среди проверок также присутствует встроенная вендорская политика проверки на лицензионную чистоту.

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

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

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

Этапы работы политик

Этапы работы политик настраиваются пользователем при редактировании параметров проекта в разделе Настройки → Проекты в поле Этап политики или указываются через параметр --stage при запуске консольного агента Johnny. Наименования стадий имеют следующие значения:

  • dev – этап разработки;
  • stage – промежуточный (предпромышленный) этап;
  • test – этап тестирования;
  • prod – промышленный контур.

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

Кроме того, существуют специальные значения стадий, используемые по умолчанию для определённых задач:

  • proxy – для плагина в модуле OSA;
  • source – для анализа VCS-проектов;
  • build – для консольного агента Johnny.

Создание политики

Политики создаются в разделе Настройки -> Политики. Перейти на форму создания политики можно по кнопке Создать.

Policy сreation

В форме создания политики задается контекст работы политики по следующим параметрам:

  • Название;
  • Группы — группы проектов, на которые распространяется политика. Если параметр пустой – политика применяется для всей организации;
  • Подразделения — подразделения организации, на которого распространяется политика. Если параметр пустой – политика применяется для всей организации;
  • Проекты — проекты, на которые применяется политика;
  • Этапы — стадии цикла разработки, на которые применяется политика;
  • Компоненты OSA – тип компонентов в менеджере репозиториев с плагином OSA, на который применяется политика (Пакеты или Контейнерные образы);
  • Репозитории – список репозиториев с плагином OSA, на которые применяется политика;
  • Уровень — уровень критичности политики (не влияет на действия в системе);
  • Блокер — блокировка сборки или загрузки компонента из прокси-репозитория;
  • Отложенная блокировка — задержка (в днях) от первого срабатывания политики до блокировки;
  • Активно — состояние политики;
  • Описание — описание политики;
  • Условия — перечень условий в политике.

Далее настраиваются условия срабатывания политики, поддерживаются следующие параметры:

  • PURL — package URL, идентификатор компонента;
  • Название зависимости — имя используемого компонента;
  • Версия зависимости — конкретная версия компонента, обнаруженная в проекте;
  • Автор зависимости — имя или организация, указанные как автор компонента;
  • Дата публикации зависимости — дата первого появления версии зависимости в открытых источниках;
  • Возраст зависимости (в днях) — количество дней с момента публикации зависимости;
  • Количество уязвимостей в зависимости — общее число уязвимостей, связанных с компонентом;
  • Зависимость опасна – зависимость считается опасной, если у нее есть уязвимости с:
    • префиксом MAL- (фид вредоносных пакетов OSV);
    • одним из следующих CWE:
    • CWE-506: Внедренный вредоносный код;
    • CWE-507: Троянское ПО;
    • CWE-509: Нераспространяющийся вредоносный код;
    • CWE-509: Распространяющийся вредоносный код (вирус или червь);
    • CWE-510: Скрытые средства несанкционированного доступа;
    • CWE-511: Логическая или временная бомба;
    • CWE-512: Шпионское ПО;
    • CWE-912: Скрытые функции;
    • или одним из следующих значений поля Импакт в базе Kaspersky OSS Threats Data Feed:
    • Вредоносное ПО;
    • Другое влияние.
  • Зависимость является протестным ПО – наличие уязвимости в проприетарном фиде protestware;
  • Зависимость является потомком – поиск на нижестоящих уровнях транзитивных зависимостей, относящихся к указанному родительскому компоненту. Поиск зависимости осуществляется для более глубоких уровней вложенности графа зависимостей. Например, для случая цепочки зависимостей a<-b<-c<-d потомками b будут с и d;
  • Технология — язык программирования или экосистема;
  • Лицензия – SPDX-идентификатор лицензии;
  • Категория лицензии — классификация лицензии по типу (например, copyleft, permissive);
  • ID уязвимости — идентификатор уязвимости;
  • Оценка CVSS2 — численная оценка угрозы по стандарту CVSS 2;
  • Уровень угрозы CVSS2 — уровень угрозы по стандарту CVSS 2;
  • CVSS2 Access Vector (AV) – путь эксплуатации уязвимости (физический или сетевой);
  • CVSS2 Access Complexity (AC) – сложность эксплуатация уязвимости;
  • CVSS2 Authentication (Au) – требования аутентификации для эксплуатации уязвимости;
  • CVSS2 Availability Impact (A) – степень потери доступности данных;
  • CVSS2 Confidentiality Impact (C) – cтепень потери конфиденциальности данных;
  • CVSS2 Integrity Impact (I) – степень потери целостности данных;
  • Оценка CVSS3 — численная оценка угрозы по стандарту CVSS 3;
  • Уровень угрозы CVSS3 — уровень угрозы по стандарту CVSS 3;
  • CVSS3 Attack Vector (AV) — вектор атаки;
  • CVSS3 Attack Complexity (AC) — сложность атаки;
  • CVSS3 Priviliges Required (PR) — требуемый уровень доступа для эксплуатации уязвимости;
  • CVSS3 User Interaction (UI) — наличие взаимодействия с пользователем;
  • CVSS3 Scope (S) — область безопасности компонента;
  • CVSS3 Confidentiality (C) — cтепень потери конфиденциальности данных;
  • CVSS3 Integrity (I) — степень потери целостности данных;
  • CVSS3 Availability (A) — степень потери доступности данных;
  • Дата публикации уязвимости — дата, когда уязвимость была впервые опубликована;
  • Дата обновления уязвимости — дата последнего обновления информации об уязвимости;
  • Результат эксплуатации уязвимости (Kaspersky) – поле Импакт в базе Kaspersky OSS Threats Data Feed;
  • Уязвимость имеет эксплойт – признак наличия публичного эксплойта в базе знаний уязвимостей (NVD, GHSA, БДУ ФСТЭК или другой);
  • Уязвимость имеет исправление – признак наличия версии, на которую можно обновиться для устранения уязвимости;
  • Возраст уязвимости (в днях) — количество дней с момента публикации уязвимости;
  • Окружение — окружение разработки;
  • Способ обнаружения — способ обнаружения зависимости (по манифесту, содержанию проекта или в результате разрешения зависимостей);
  • Связь — связь зависимости в проекте (прямая или транзитивная);
  • CWE — идентификатор типа уязвимости по стандарту Common Weakness Enumeration.

Пример политики

Условия политики можно объединять в группы с помощью логических выражений И/ИЛИ. Группы не имеют ограничений по уровню вложенности и количеству условий.

Например, можно задать условия политики для следующего сценария – либо зависимость содержит уязвимость с эксплойтом и рекомендацию по исправлению, либо зависимость является директивной и содержит критическую уязвимость по стандарту CVSS 3.

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

Policy example

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

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

Рекомендация: если оставить поля Подразделения, Группы и Проекты пустыми, политика будет применяться для всех активных проектов в системе.

Результаты работы политик

Результаты работы политик отображаются в разделе Алерты. Раздел имеет три вкладки:

  • Активные – список алертов по результатам последнего анализа (проекта, сборки или компонента в прокси-репозитории);
  • Игнорированные – список проигнорированных алертов;
  • Решенные – список алертов, которые были решены после последнего анализа (условие политики больше не актуально).

Причина срабатывания политики отображается в поле Условия политики, включая заданные условия и найденные данные о компоненте. Например, значение django@4.2.2 has CVE-2024-38875, CVSS3 Score 7.5 >= 7.00 подразумевает, что политика блокировки компонентов с CVSS3 равным или выше 7.00 сработала на компоненте django версии 4.2.2 с оценкой уязвимости 7.5.

Для создания задачи или отправки email из списка алертов необходимо выбрать один или несколько алертов и нажать соответствующую кнопку.

Например, так:

  • создание задач

New task

  • отправка почтовых сообщений

Send email