• English

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• PURL — package URL, идентификатор компонента;
• Название зависимости;
• Версия зависимости;
• Автор зависимости
• Дата публикации зависимости;
• Возраст зависимости (в днях);
• Количество уязвимостей в зависимости;
• Зависимость опасна;
• Зависимость является протестным ПО;
• Технология — язык программирования или экосистема;
• Лицензия;
• Категория лицензии;
• 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);
• Уязвимость имеет эксплойт;
• Уязвимость имеет исправление;
• Возраст уязвимости (в днях);
• Окружение — окружение разработки;
• Способ обнаружения — способ обнаружения зависимости (по манифесту, содержанию проекта или в результате разрешения зависимостей);
• Связь — связь зависимости в проекте (прямая или транзитивная);
• CWE — идентификатор типа уязвимости по стандарту Common Weakness Enumeration.

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

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

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

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

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

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

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

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

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

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

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

Игнорирование политик

Созданные политики можно временно или навсегда проигнорировать при анализе. Условие игнорирования позволит оставить политики в системе, при этом не получая алертов о ее срабатывании, например в случае если уязвимость в компоненте не применима для конкретного проекта. Создание и настройка условий игнорирования происходит в разделе Настройки -> Игноры политики.

Для создания условия игнорирования для одной или нескольких политик необходимо нажать на кнопку Создать и заполнить следующие поля:

• Проекты — проекты, на которые применяется игнор;
• Образы контейнеров – образы в реестрах, на которые применяется игнор;
• Технология - язык программирования или экосистема;
• PURL зависимости — package URL, идентификатор компонента;
• Название зависимости;
• Версия зависимости;
• Лицензия;
• ID уязвимости - идентификатор уязвимости;
• Политики;
• Активно - состояние игнора;
• Дата активации - дата, с которой игнор начнет работать;
• Дата окончания - дата, после которой игнор закончит работать;
• Заметка.