Интеграции со сканерами безопасности

Deckhouse Code добавляет собственные интеграции с инструментами, которые выполняют обязательные сканирования безопасности, и с системой, которая собирает их находки. Интеграция сканера хранит то, что нужно задаче сканирования и чего политика в репозитории хранить не должна: адрес сервера, токен, доверие сертификату и значения по умолчанию для каждого сканирования проекта. Интеграция DefectDojo хранит подключение к серверу, на который отправляются отчёты безопасности пайплайна.

Интеграция проекта или группы открывается из «Настройки» → «Интеграции». Интеграция группы действует для каждого проекта под ней, который не задал собственную. У Opengrep и Trivy, сканеров обязательных сканирований SAST и Trivy, настраивать нечего, и в этих списках их нет. Интеграции CodeScoring и PT AI доступны, пока включён флаг функций fe_security_scan_policies, а интеграция DefectDojo — пока включён флаг функций defect_dojo_integration; как администратор включает флаги, описано на странице Ранний доступ.

Само сканирование задаётся в политике выполнения сканирования: какие модули работают, что сканируется и что роняет пайплайн. Редактор политик предлагает сканирования PT AI и CodeScoring, только пока интеграция этого сканера активна для проекта или для группы выше него; недоступный вариант ведёт ссылкой на страницу интеграции. Переменные интеграции попадают в каждую задачу пайплайна; её токены попадают только в задачу сканирования, которую политика предписала для этого сканера. Переменная, заданная политикой, имеет приоритет над той же переменной из интеграции. Редактор политик и параметры SAST-сканирования описаны на странице SAST-сканирование.

Opengrep

Opengrep — сканер, которым выполняется обязательное SAST-сканирование opengrep_sast. Это консольная утилита, работающая внутри задачи: ей не нужен ни сервер, ни токен, ни доверие сертификату. Всё, что касается сканирования, включая образ, в котором оно выполняется, принадлежит политике, поэтому интеграции для настройки нет: «Opengrep» отсутствует в списках «Интеграции», на страницах настроек и в REST API, а задачи сканирования не получают переменных из записи интеграции.

Образ, в котором выполняется сканирование, сервер определяет при формировании задачи и записывает в неё как значение, а не как переменную. Сервер берёт:

• ссылку из поля «Образ сканера» действия opengrep_sast, если политика её называет;
• иначе образ из переменной окружения инстанса FE_SCANS_OPENGREP_IMAGE;
• иначе образ, зафиксированный этим релизом, — opengrep-scan:1.30.0-fe2 из хранилища образов продукта.

Образ никогда не становится переменной CI/CD, поэтому собственные настройки проверяемого проекта не могут направить сканирование на другой сканер. Поле «Образ сканера» в политике показывает образ, который выполнится при пустом поле, а подсказка рядом называет версию Opengrep и набор правил из поставки продукта.

Правила, уровни правил, исключаемые категории, порог блокировки, игнорируемые пути и дополнительные параметры — это группы «Правила», «Уровни правил», «Исключаемые категории», «Порог блокировки», «Игнорируемые пути» и «Дополнительные параметры» того же действия. Сканирование, его задачи и эти группы описаны на странице SAST-сканирование.

Trivy

Trivy — сканер, которым выполняется обязательное сканирование trivy. Он работает внутри задачи и не обращается к собственному серверу, поэтому интеграции для настройки нет: «Trivy» отсутствует в списках «Интеграции», на страницах настроек и в REST API, а задачи сканирования не получают переменных из записи интеграции.

Всё, что касается сканирования, принадлежит политике: модули, их параметры и образ, в котором сканирование выполняется. Образ сервер записывает в задачу при её формировании: ссылку из поля «Образ сканирования» действия trivy или, если политика её не называет, образ, зафиксированный этим релизом, — trivy-with-db:0.74.0 из хранилища образов продукта. Учётные данные хранилища образов модуль образов контейнеров берёт из переменных CI/CD сканируемого проекта.

Сканирование, его модули и их параметры описаны на странице Сканирование с помощью Trivy.

CodeScoring

Полная настройка, модули SCA и «Секреты» и диагностика этой интеграции описаны на странице «Интеграция с CodeScoring».

Интеграция CodeScoring подключает проект к серверу CodeScoring и доставляет агент johnny в задачи сканирования codescoring. У сканирования два модуля, каждый включается в политике: анализ состава, который выполняет задача codescoring_sca и который публикует отчёт о сканировании зависимостей, отчёт о качестве кода, отчёт о тестах и CycloneDX SBOM gl-sbom.cdx.json; и поиск секретов, который выполняют задачи codescoring_secrets_gitleaks, codescoring_secrets_trufflehog и codescoring_secrets_kingfisher, по одной на движок, и который публикует отчёт об обнаружении секретов. Находки попадают в отчёт об уязвимостях, список зависимостей и DefectDojo наравне с находками любого другого сканера; SBOM читают страницы Список зависимостей и соответствие лицензий.

Интеграция настраивается на проекте или группе в «Настройки» → «Интеграции» → «CodeScoring». Редактор политик предлагает сканирование codescoring, пока интеграция активна для проекта или группы выше него. Форма содержит подключение, доверие и значения по умолчанию для задач сканирования; что и как сканирует агент, задаётся в политике:

«Проверить настройки» запрашивает у сервера версию агента с токеном и настройкой доверия из формы, так что адрес, токен и сертификат проверяются разом.

Задачи получают FE_SCANS_CODESCORING_URL, FE_SCANS_CODESCORING_TLS_MODE и, если назван удостоверяющий центр, FE_SCANS_CODESCORING_CA_CERT; FE_SCANS_CODESCORING_SCAN_STAGE и FE_SCANS_CODESCORING_BOM_FORMAT — когда поля заполнены. FE_SCANS_CODESCORING_TOKEN маскируется и попадает только в предписанные политикой задачи CodeScoring. Каждая задача загружает агент с сервера при каждом запуске, поэтому версия агента — та, которую публикует сервер. Анализ состава отчитывается в проект CodeScoring, названный по slug пути проекта, и создаёт его, если такого нет.

«Образ задачи сканирования» читается при формировании задачи и записывается в неё как значение, а не как переменная; образ называет только интеграция группы, которая предписывает сканирование, — группы, к которой привязана политика, или группы выше неё, — а значение в собственной интеграции проверяемого проекта игнорируется. «Стадия сканирования» и «Формат SBOM» — значения по умолчанию для проекта: политика, называющая собственное значение, имеет приоритет, а список «Формат SBOM» в политике содержит вариант «Взять из интеграции», чтобы вернуть решение интеграции.

Группа «SCA» в политике задаёт режим и цель сканирования, игнорируемые пути, разрешение дерева зависимостей на сервере, стадию, формат SBOM и дополнительные аргументы агента; группа «Секреты» выбирает движки — gitleaks, trufflehog, kingfisher — и задаёт каждому конфигурацию и список исключений.

PT AI

Полная настройка, параметры сканирования и диагностика этой интеграции описаны на странице «Интеграция с PT AI».

Интеграция «Positive Technologies Application Inspector» обслуживает сканирование ptai. Его задача ptai_scan загружает исходный код коммита на сервер PT AI клиентом aictl, в проект, названный полным путём проекта с : вместо /, ждёт окончания сканирования и публикует отчёт о тестах и отчёт безопасности SAST, поэтому находки попадают в отчёт об уязвимостях. Белый и чёрный ящик — части одного сканирования: модули белого ящика работают всегда, а адрес сайта добавляет к ним чёрный ящик. Порога по уровню находок нет: задача завершается с ошибкой, когда сканирование не удалось или политика безопасности проекта на сервере PT AI отклонила его.

Интеграция настраивается на проекте или группе в «Настройки» → «Интеграции» → «Positive Technologies Application Inspector» и хранит только подключение: «URL сервера», «API-токен», «Доверие к сертификату» с «Удостоверяющим центром», а также раздел «Джобы сканирования» с образом задачи и переменными логина и пароля реестра. Раздел «Джобы сканирования» читается из интеграции группы, которой принадлежит политика; подключение — из интеграции проверяемого проекта. Задача получает FE_SCANS_PTAI_SERVER_URL, FE_SCANS_PTAI_TLS_MODE и, если назван удостоверяющий центр, FE_SCANS_PTAI_CA_CERT; FE_SCANS_PTAI_TOKEN маскируется и попадает только в предписанную политикой задачу ptai_scan.

Что сканируется, задаёт политика: модули и языки, .gitignore, загрузка зависимостей, собственный конфигурационный файл и чёрный ящик со входом на сайт и прокси. Пароли и cookie политика называет ссылками $NAME на переменные CI/CD проверяемого проекта. Параметры интеграции в политике не принимаются.

DefectDojo

Полная настройка, сопоставление сущностей и диагностика этой интеграции описаны на странице «Интеграция с DefectDojo».

Интеграция DefectDojo отправляет отчёты безопасности пайплайна на сервер DefectDojo. Отчёты уходят в том виде, в каком их опубликовали задачи, в собственных форматах отчётов, через эндпоинт повторного импорта сервера:

Обязательные сканирования публикуют эти типы — Opengrep и PT AI отчёт sast, Trivy dependency_scanning, secret_detection и container_scanning, CodeScoring dependency_scanning и secret_detection, — и задача из собственного .gitlab-ci.yml проекта, публикующая такой отчёт, выгружается так же. Отчёт PT AI не импортируется: PT AI записывает в него scan.status: failure даже для завершённого сканирования.

Интеграция настраивается на проекте или группе в «Настройки» → «Интеграции» → «DefectDojo», а для всего инстанса — в «Admin» → «Настройки» → «Интеграции» → «DefectDojo». Её «Параметры импорта по умолчанию» — это соответствие, которое использует каждая выгрузка:

При сохранении формы с собственными настройками сервер спрашивают, пригодно ли соответствие: отклонённый токен, отсутствующий продукт при выключенном «Автоматически создавать контекст», отсутствующий тип продукта при включённом и отсутствующая активность при выключенном отклоняются каждый с сообщением, называющим продукт или активность. Сервер, которого не удалось спросить, сохранение не блокирует. «Проверить настройки» — кнопка интеграции проекта — задаёт те же вопросы и сообщает также о сервере, которого не удалось спросить.

Выгрузка начинается, когда в проекте с активной интеграцией DefectDojo, собственной или унаследованной, завершается задача, опубликовавшая отчёт одного из типов выше. На пайплайн выполняется одна выгрузка; следующая завершившаяся в том же пайплайне задача повторяет её один раз. Каждый отчёт последнего запуска каждой задачи попадает в продукт и активность из формы, в тест, названный по задаче, с датой завершения задачи, поэтому повторный запуск сканирования обновляет тот же тест, и его находки не заводятся дважды. В активность записываются коммит, ветка, номер пайплайна, короткий коммит как версия и адрес проекта. Отчёт сканирования, которое не выполнилось, — заглушка, которую задача опубликовала, чтобы виджеты пайплайна что-то показывали, — не импортируется, потому что «Закрывать старые находки» иначе закрыло бы каждую находку последнего настоящего сканирования.

Ответ сервера 429 или 5xx и тайм-аут повторяются через 60, 120 и 240 секунд; выгрузка ждёт один отчёт до 600 секунд. Любой другой отказ окончателен, и подействовать на него может только проект: страница пайплайна показывает предупреждение «Предупреждения выгрузки отчётов о безопасности» с одной строкой на каждый отчёт, который не дошёл до сервера:

DefectDojo did not receive the report of job "opengrep_sast_junit" (GitLab SAST Report): DefectDojo returned HTTP 400: Product "group/project" does not exist and no product_type_name provided to create the new product in

Причина — собственное сообщение сервера, до 500 символов, либо одно из blocked URL: … для адреса, к которому инстансу запрещено обращаться, certificate authority: … для сертификата, который не удалось прочитать, и the scan did not run, so its placeholder report was not imported. Когда повторные попытки исчерпаны, страница показывает ещё одну строку: DefectDojo upload of this pipeline's security reports failed and the retries are spent: …. Строка об отчёте убирается, когда следующий запуск доставляет этот отчёт. Полный ответ сервера — в журнале приложения.

Дополнительные ресурсы

• Отчёт об уязвимостях
• Интеграция с DefectDojo
• Интеграция с CodeScoring