О SBOM, BitBucket и OWASP Dependency Track

Музей старой и новой архитектуры, с которым я связан, заставил меня обратить внимание на их защиту. Например, старая зависимость может стать уязвимостью CVE, или солидный проект с открытым исходным кодом может стать коммерческим. Именно здесь появилась концепция “Программного билета материалов” (SBOM), чтобы каталогизировать лицензионную и зависимостную экосистему систем. Этот артефакт сборки, в свою очередь, затем анализируется, чтобы определить, являются ли составные компоненты:

  1. Уязвимыми для эксплуатации, или
  2. Лицензированными на неприемлемых условиях, таких как слишком коммерческие или слишком хищные.

В этой статье будет объяснено, как контролировать такую уязвимость с помощью:

  1. BitBucket pipes для генерации SBOM, и
  2. Как OWASP’s Dependency Track может это проанализировать.

Знайте свои риски

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

Wikipedia утверждает, что: “Проект Open Worldwide Application Security Project (OWASP) – это онлайн-сообщество, которое публикует свободно доступные статьи, методологии, документацию, инструменты и технологии в области IoT, системного программного обеспечения и безопасности веб-приложений.” Поэтому неудивительно, что они предоставляют платформу для отслеживания и анализа уязвимостей в системах. Их самой яркой особенностью является главный дашборд:

Самый большой график посередине отображает количество уязвимостей для всех отслеживаемых проектов. Метрики по критическим, средним и низким уязвимостям отображаются прямо ниже. Dependency Track извлекает известные уязвимости из одного или нескольких источников. Самый значимый из них – список Общих уязвимостей и инцидентов (CVE) из Национальной базы данных уязвимостей США. Каждой CVE присваивается уровень критичности от неизвестной и низкой до критической. Этот анализ рисков выполняется Dependency Track регулярно в фоновом режиме с использованием соответствующего списка программного обеспечения (SBOM) в качестве входных данных.

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

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

Есть больше представлений, графиков и статистики, таких как прогресс по аудиту, уязвимость на проект во времени и уязвимость на компонент во времени среди прочего, но давайте лучше обратим внимание на то, как BitBucket может создавать и отправлять SBOM в Dependency Track.

BitBucket готовит SBOM

Подготовка SBOM происходит в BitBucket CI/CD конвейере, который выполняется после слияния запросов на влитие в основную ветку. Это гарантирует, что панели инструментов всегда актуальны. 

Я использовал BitBucket pipe, который оборачивает syft для создания CycloneDX SBOM. Команды syft для анализа кода и контейнера немного различаются.

Анализ кода

Команда syft для анализа кода из корня вашего проекта выглядит следующим образом: 

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

Эта команда выводит SBOM в файл с названием code-cdx-sbom.json и использует сеть для получения информации о лицензиях из интернета; например, из центральных хранилищ Maven.

Система BitBucket pipe от shiftleftcyber (спасибо!) затем настраивается в блоке скрипта пайплайна BitBucket для обертки этой syft команды следующим образом:

YAML

 

README проекта syft перечисляет впечатляющий массив поддерживаемых языков, но я использовал его только с Java и JavaScript в проекте на Python в резерве.

Что скрыто в ваших контейнерах?

Чтобы просканировать контейнер из вашего реестра, необходимо выполнить следующую команду в рамках “docker login”:

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

Соответствующий pipe BitBucket выглядит следующим образом:

YAML

 

Ключ all-layers инструктирует syft проверять все слои образа контейнера, а не только конечный продукт.

BitBucket как средство депозита

Остается только для Dependency Track обработать SBOM. Я использовал сестринский pipe BitBucket pipe, который сгенерировал SBOM:

YAML

 

Я указал три входных параметра:

  1. URL экземпляра Dependency Track
  2. Идентификатор проекта Dependency Track для загрузки SBOM
  3. API-ключ для авторизации загрузки

Идентификатор проекта можно легко найти, нажав “Просмотреть детали” в представлении проекта:

Затем скопируйте Идентификатор объекта внизу:

API-ключ можно найти в аналогичном поле ввода команды Автоматизация, доступном из меню Администрирование в левом панеле:

Заключение

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

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

Поэтому каждый разработчик несет ответственность за внедрение и поддержку активных стратегий для противодействия этим рискам. Если ваш код находится на BitBucket, описанный выше подход может помочь вашим системам соответствовать программе. Однако API Dependency Track не ограничивает доступ исключительно к BitBucket, и должны быть способы получить Софтверный реестр материалов из других технологий CI/CD.

Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track