Музей старой и новой архитектуры, с которым я связан, заставил меня обратить внимание на их защиту. Например, старая зависимость может стать уязвимостью CVE, или солидный проект с открытым исходным кодом может стать коммерческим. Именно здесь появилась концепция “Программного билета материалов” (SBOM), чтобы каталогизировать лицензионную и зависимостную экосистему систем. Этот артефакт сборки, в свою очередь, затем анализируется, чтобы определить, являются ли составные компоненты:
- Уязвимыми для эксплуатации, или
- Лицензированными на неприемлемых условиях, таких как слишком коммерческие или слишком хищные.
В этой статье будет объяснено, как контролировать такую уязвимость с помощью:
- BitBucket pipes для генерации SBOM, и
- Как 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
команды следующим образом:
pipe docker //ccideas/syft-bitbucket-pipe1.0.0
variables
SYFT_CMD_ARGS'. --output cyclonedx-json=code-cdx-sbom.json'
SYFT_JAVA_USE_NETWORK'true'
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 выглядит следующим образом:
pipe docker //ccideas/syft-bitbucket-pipe1.0.0
variables
SYFT_REGISTRY_AUTH_USERNAME sadilar
SYFT_REGISTRY_AUTH_PASSWORD $DOCKER_PWD
SYFT_CMD_ARGS'docker.s2c.co.za/container:latest --output cyclonedx-json=container-cdx-sbom.json --scope all-layers'
Ключ all-layers
инструктирует syft проверять все слои образа контейнера, а не только конечный продукт.
BitBucket как средство депозита
Остается только для Dependency Track обработать SBOM. Я использовал сестринский pipe BitBucket pipe, который сгенерировал SBOM:
pipe docker //ccideas/sbom-utilities-pipe1.5.0
variables
PATH_TO_SBOM code-cdx-sbom.json
SEND_SBOM_TO_DTRACK'true'
DTRACK_URL https //deptrack.test.s2c.co.za
DTRACK_PROJECT_ID df3327b2-5439-43ab-bb33-1f24228b6074
DTRACK_API_KEY $DTRACK_TEST
Я указал три входных параметра:
- URL экземпляра Dependency Track
- Идентификатор проекта Dependency Track для загрузки SBOM
- API-ключ для авторизации загрузки
Идентификатор проекта можно легко найти, нажав “Просмотреть детали” в представлении проекта:
Затем скопируйте Идентификатор объекта внизу:
API-ключ можно найти в аналогичном поле ввода команды Автоматизация, доступном из меню Администрирование в левом панеле:
Заключение
Прошлые инциденты показали, что использование уязвимостей обычно приводит к сбоям в работе сервисов, которые могут повлиять на соседние системы или отрасли. Это вызывает неожиданные расходы и неудобства. Восстановление от этого отвлечет разработчиков и ресурсы от целей команды.
Лицензирование открытого проекта, кроме того, может стать коммерческим и привести к тому, что организации придется выплатить задолженность по лицензиям. С другой стороны, могут быть сделаны требования к открытию критических интеллектуальных прав, используемых для получения конкурентного преимущества из-за хищнических условий лицензирования.
Поэтому каждый разработчик несет ответственность за внедрение и поддержку активных стратегий для противодействия этим рискам. Если ваш код находится на BitBucket, описанный выше подход может помочь вашим системам соответствовать программе. Однако API Dependency Track не ограничивает доступ исключительно к BitBucket, и должны быть способы получить Софтверный реестр материалов из других технологий CI/CD.
Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track