Привет! Меня зовут Михаил Черешнев, я работаю в компании Swordfish Security, где занимаюсь вопросами внедрения DevSecOps. Сегодня мы в команде много внимания уделяем направлению Software supply chain security. Если заглянуть в Рунет, можно найти в нем немало статей, рассказывающих о проблемах в обеспечении безопасности цепочки поставок. Но о том, что с ними делать и какое решение применять, ничего нет. И в этой статье мы постарались восполнить этот пробел. Рассказываем все о Chainloop: верхнеуровневая архитектура, преимущества, то какие проблемы закрывает. Поехали!
Software supply chain security - область безопасности информационных систем и приложений. Подобно физической цепочке поставок, которая охватывает процесс создания, доставки и распределения товаров, цепочка поставок программного обеспечения (часто называемая цепочкой поставок разработки ПОи) включает в себя множество элементов, от разработчиков операционной системы до сторонних библиотек и инструментов.
Проблемы безопасности в Software Supply Chain могут возникать на любом этапе жизненного цикла программного обеспечения и вызываться различными причинами, начиная от злоумышленной вставки вредоносного кода сотрудником на этапе разработки, заканчивая компрометацией стороннего поставщика при использовании готовых решений или сервисов.
Приведем несколько известных примеров атак, связанных с цепочками поставок программного обеспечения:
В 2017 году компания CCleaner сообщила, что злоумышленные хакеры смогли получить доступ к серверам, используемым для распространения и обновления программы. Хакеры внедрили вредоносный код в обновление, которое было загружено на более чем 2,3 миллиона компьютеров
В 2019 году стало известно о том, что злоумышленники скомпрометировали серверы компании ASUS и использовали их для распространения вредоносного ПО через легитимное программное обеспечение Live Update Utility на миллионы компьютеров
Инцидент SolarWinds, произошедший в 2020 году, стал одной из самых громких атак на цепочку поставок в истории. Хакеры взломали системы SolarWinds и добавили вредоносный код в обновления продукта Orion, который использовали десятки тысяч компаний и организаций по всему миру.
Кроме того, существуют другие угрозы безопасности поставочных цепей, такие как подделка компонентов, уязвимости в сторонних библиотеках и инструментах, повреждение данных и т.д.
Чтобы обеспечить безопасность цепочек поставок программного обеспечения, необходимо принимать меры как на уровне компании-разработчика, так и на стороне потребителя. От первых может потребоваться использование проверенных инструментов и библиотек, управление доступом и аутентификация, контроль качества кода и многое другое. Потребителям же важно обеспечивать проверку цепочки поставок, управление версиями и обновлениями программного обеспечения, использование автоматического процесса развертывания и другие меры безопасности.
Введение
SBOM (Software Bill of Materials) - это документ, который содержит полный список всех компонентов и зависимостей, используемых в проекте программного обеспечения. SBOM помогает определить все составные части программного обеспечения, что позволяет контролировать безопасность и управлять рисками, связанными с использованием сторонних компонентов
Sign (Подпись) - это криптографический метод, который применяется для аутентификации сообщений, файлов или других данных. Подпись генерируется с использованием закрытого ключа и может проверяться с помощью соответствующего открытого ключа. Подписание данных позволяет убедиться в том, что они не были изменены, а также дает гарантию их целостности и защиты авторства
Workflow Contract (Контракт рабочего процесса) - определяет ожидания относительно того, какое содержимое рабочий процесс должен отправить в качестве части своей аттестации. Например, в контракте может быть явно указано, что URI@digest сгенерированного образа контейнера, корневые файлы контейнера, используемые при сборке, и спецификация программного обеспечения этого образа контейнера должны присутствовать в аттестации
Attestation (Аттестация программного обеспечения) - это аутентифицированное заявление (метаданные) о программном артефакте или коллекции программных артефактов. Основным предполагаемым вариантом применения является использование в автоматизированных механизмах разработки политик, таких как in-toto и Binary Authorization. Cообщество Open Source Software Security (OpenSSF) в целом и проект SLSA в частности проделали большую работу по определению структуры и эталонная реализации. Суть ее в том, что основной частью метаданных является заявление, которое заворачивается в конверт, который затем подписывается, формируя окончательную аттестацию.
Для создания таких аттестационных файлов существуют отличные инструменты с открытым исходным кодом, такие как Tekton Chains, генератор SLSA GitHub или даже Cosign.
И хотя эти инструменты могут быть технически совершенными и покрывать все наши потребности, по мнению команды Chainloop, они не очень хорошо подходят для фрагментированного сценария большой организации, где на первый план выходят дополнительные задачи, такие как взаимодействие между командами и ежедневные операции. Именно поэтому появилось и стало развиваться решение Сhainloop.
Список основных проблем в обеспечении безопасного процесса цепочки поставок включает в себя:
Наличие разных типов артефактов (это могут быть различные библиотки, maven-артефакты, образы контейнеров, helm-чарты и т.д.)
Применение разных инструментов ci/cd (решений, плагинов для ci/cd-систем, которые не могут быть сопоставлены друг с другом)
Сложность в организации контрактов (когдя используется “солянка” из решений для безопасности цепочки поставок)
Отсутствие возможности наблюдать за текущим состоянием цепочки поставок (результат виден только после выполнения пайплайнов)
Отсутствие единой точки интеграции (нет готового сервиса, который бы позволял создавать, хранить, обновлять и отзывать контракты)
Необходимость погружения в тему Supply Chain Security (разработчкам нужно детально изучать тему, чтобы выполнять требования ИБ и продвигать исполнение пайплайна дальше).
Chainloop
Chainloop - Open Source-решение для организации безопасности цепочки поставок программного обеспечения, использующее аттестации на базе контрактов. В первую очередь, инструмент интересен своей простотой вндрения в процесс безопасной разработки. Наличие присутствующих интеграций и возможностей развертывания позволяет достаточно быстро и относительно легко достичь SLSA Level 3.
Преимущества использования Сhainloop:
OpenSource - тут все понятно:)
Contract Based Attestation - команда SecOps может определить требования к аттестации, связанные с рабочими процессами в своей организации. Новые/обновленные требования могут быть легко распространены и введены в действие
Third-Party Integration - полученные артефакты и метаданные аттестации могут быть переданы различным сторонним интеграциям, таким как Dependency-Track, для анализа программной спецификации (SBOM), а также в реестр OCI для хранения артефактов, в GUAC для построения графа метаданных безопасности ПО.
First Class Day-2 operations - распространение новых требований на всю систему, принудительное исполнение этих требований и предотвращение дрейфа конфигурации
Auditability - централизованный и устойчивый ко взлому доступ к метаданным аттестации/подтверждения, журналам и артефактам сборки со всей организации
Security Compliance - возможность достижения уровня SLSA Level 3, за счет использования собственного хранилища артефактов OCI, набора из экосистемы sigstore и формата аттестаций in-toto.
CI provider agnostic - независимость от инструмента СI за счет применения единого источника истины и точки интеграции
Dead Simple Crafting process - простой процесс создания безопасных приложений с помощью инструмента командной строки, который предлагает разработчикам понятный и удобный интерфейс и не требует от них глубоких знаний в области безопасности цепочки поставок
Transparent best-practices enforcement - инструмент позволяет автоматически соблюдать лучшие практики безопасности в зависимости от типа артефактов и эффективно обрабатывать различные типы данных и управлять ими
Observability - наблюдаемость организационной принадлежности, состояния и готовности к автоматизации в цепочке поставок.
Архитектура Сhainloop
Для Chainloop доступны два варианта использования: Cloud и Self-hosted с помощью Helm.
Helm chart включает в себя следющие компоненты:
-
Chainloop Controlplane - плоскость управления и единая точка интеграции;
Control Plane -
Chainloop Artifact Proxy - прокси-сервер Content-Addressable Storage (CAS), который находится перед различными бэкендами хранилищ. Такие клиенты, как Chainloop Control Plane или CLI, используют этот прокси для обеспечения неизменности загруженных артефактов и их однозначной идентификации по дайджесту содержимого (sha256sum). На момент публикации статьи поддерживаются только OCI-реестры, в будущем обещают добавить и AWS S3;
Artifact Content Addressable Storage (CAS) Proxy
Также, чарт предоставляет режим развертывания development, который доставит в неймспейс PostgreSQL и Vault;
Внимание! development mode создан исключительно для тестирования, не используйте его для реальных систем.
PostgreSQL - в качестве персистентного хранилища;
Vault - в качестве бэкенда хранения секретов, а так же есть возмость использования AWS Secret Manager.
Для взаимодействия с Сontrol plane и загрузки/скачивания артефактов с Chainloop Artifact Proxy (CAS):
-
Command Line Interface (CLI)
Для развертыания требуются:
OIDC IDp - настройки Open ID Connect Identity Provider (IDp), т.е. настройки Auth0;
Secret Manager - Vault или AWS Secret Manager;
ECDSA (ES512) пара ключей , используемая для аутентификации между Controlplane и Chainloop Artifact Proxy(CAS).
Верхнеуровневая архитектура взаимодействия компонентов системы
В целом, архитектуру решения и взаимодействие между его компонентами можно изобразить так:
Workflow с Chainloop
Допустим, у нас есть CI-конвейер, который мы хотим интегрировать с Chainloop, чтобы получить видимость, а также сделать его SLSA-совместимым с помощью подписанной аттестации/артефакта (официальный пример).
Если не вдаваться во все подробности бюрократического устройства организации или настроек систем, то процесс интеграции Chainloop в конвеер будет примерно таким:
1. Оператор (SecOps) создает worflow в Сhainloop Control Plane. На данном этапе инженер ИБ создает workflow для конвеера СI, указывая имя, проект, команду разработки. '
$ chainloop workflow create \
--name "build-and-test" \
--project "skynet" \
--team "cyberdyne core"
┌──────────────────────────────────────┬────────────────┬─────────┬────────────────┬─────────────────────┬────────┬─────────────────┐
│ ID │ NAME │ PROJECT │ TEAM │ CREATED AT │ # RUNS │ LAST RUN STATUS │
├──────────────────────────────────────┼────────────────┼─────────┼────────────────┼─────────────────────┼────────┼─────────────────┤
│ 2d289d33-8241-47b7-9ea2-8bd8b7c126f8 │ build-and-test │ skynet │ cyberdyne core │ 01 Nov 22 23:09 UTC │ 0 │ │
└──────────────────────────────────────┴────────────────┴─────────┴────────────────┴─────────────────────┴────────┴─────────────────┘
По умолчанию, если контракт не указан, будет создан новый, пустой контракт.
$ chainloop workflow contract describe --id fd489047-67f1-45d4-9f3b-27eba4051929
┌─────────────────────────────────────────────────────────────┐
│ Contract │
├──────────────────────┬──────────────────────────────────────┤
│ Name │ build-and-test generated schema │
├──────────────────────┼──────────────────────────────────────┤
│ ID │ fd489047-67f1-45d4-9f3b-27eba4051929 │
├──────────────────────┼──────────────────────────────────────┤
│ Associated Workflows │ 2d289d33-8241-47b7-9ea2-8bd8b7c126f8 │
├──────────────────────┼──────────────────────────────────────┤
│ Revision number │ 1 │
├──────────────────────┼──────────────────────────────────────┤
│ Revision Created At │ 01 Nov 22 23:09 UTC │
└──────────────────────┴──────────────────────────────────────┘
┌─────────────────────────┐
│ { │
│ "schemaVersion": "v1" │
│ } │
└─────────────────────────┘
2. Оператор (SecOps) обновляет контракт для созданного workflow в Сhainloop Control Plane. На данном этапе инженер ИБ совместно с разработчками и/или DevOps, отвечающими за сборку артефакта определяют набор материалов артефакта, необходимых для сборки, конечный продукт сборки и набор необходимых для ИБ метаданных. Пример контракта:
schemaVersion: v1
#Три обязательных и один дополнительный материал трех различных видов
materials:
#Типы CONTAINER_IMAGE будут разрешены для получения их дайджеста хранилища
- type: CONTAINER_IMAGE
name:
skynet-control-plane
#Флаг вывода указывает на то, что материал будет частью предмета аттестации
output: true
#Типы ARTIFACT сначала будут загружены в ваш реестр артефактов через встроенное хранилище с возможностью адресации содержимого (CAS).
- type: ARTIFACT
name: rootfs
#Опциональо dockerfile, т.е. можно не принуждать крепить dockerfile
- type: ARTIFACT
name: dockerfile
optional: true
#SМатериалы вида STRING будут вводиться как простые пары ключей
- type: STRING
name: build-ref
#SBOM будут загружены в реестр артефактов и упомянуты в аттестации
#Поддерживаются как SBOM_CYCLONEDX_JSON, так и SBOM_SPDX_JSON
- type: SBOM_CYCLONEDX_JSON
name: skynet-sbom
#Значения Env, которые мы хотим, чтобы система разрешила и ввела во время инициализации аттестации
#Дополнительные могут быть унаследованы от указанного контекста runner ниже
envAllowList:
- CUSTOM_VAR
- СUSTOM_VAR_2
#Указание того, в каком контексте runner'а должна происходить аттестация. Может быть полезно для того, чтобы прибить гвоздями runner к бизнес-процссу аттестации.
#Если не указано, процесс создания аттестата может быть запущен в любом месте.
runner:
type: "GITHUB_ACTION"
Дальше инженер ИБ подгружает обновленный контракт к существующему workflow:
$ chainloop workflow contract update \
--id fd489047-67f1-45d4-9f3b-27eba4051929 \
--name skynet-contract \
-f https://raw.githubusercontent.com/chainloop-dev/docs/main/examples/contracts/skynet/contract.yaml
┌─────────────────────────────────────────────────────────────┐
│ Contract │
├──────────────────────┬──────────────────────────────────────┤
│ Name │ skynet-contract │
├──────────────────────┼──────────────────────────────────────┤
│ ID │ fd489047-67f1-45d4-9f3b-27eba4051929 │
├──────────────────────┼──────────────────────────────────────┤
│ Associated Workflows │ 2d289d33-8241-47b7-9ea2-8bd8b7c126f8 │
├──────────────────────┼──────────────────────────────────────┤
│ Revision number │ 2 │
├──────────────────────┼──────────────────────────────────────┤
│ Revision Created At │ 02 Nov 22 09:08 UTC │
└──────────────────────┴──────────────────────────────────────┘
┌───────────────────────────────────────┐
│ { │
│ "schemaVersion": "v1", │
│ "materials": [ │
│ { │
│ "type": "CONTAINER_IMAGE", │
│ "name": "skynet-control-plane", │
│ "output": true │
...
3. Оператор (SecOps) создает УЗ для робота (CI/CD) в Сhainloop Control Plane. Инженер ИБ создает учетную запись робота, которую он передаст команде разработки и/или DevOps для интеграции их конвеера с Сhainloop.
Note:
Учетные записи роботов привязаны к одному workflow. Если вы создаете еще один workflow, необходимо создать еще одну учетную запись робота.Есть возможность иметь более одной учетной записи робота, связанной с workflow.
Учетные записи могут быть отозваны командой
chainloop workflow robot-account revoke.
$ chainloop workflow robot-account create \
--workflow 2d289d33-8241-47b7-9ea2-8bd8b7c126f8 \
--name prod-ci
┌──────────────────────────────────────┬─────────┬──────────────────────────────────────┬─────────────────────┬────────────┐
│ ID │ NAME │ WORKFLOW ID │ CREATED AT │ REVOKED AT │
├──────────────────────────────────────┼─────────┼──────────────────────────────────────┼─────────────────────┼────────────┤
│ 4f2376fa-48c8-4e46-a921-977ec44486a9 │ prod-ci │ 2d289d33-8241-47b7-9ea2-8bd8b7c126f8 │ 01 Nov 22 23:43 UTC │ │
└──────────────────────────────────────┴─────────┴──────────────────────────────────────┴─────────────────────┴────────────┘
Save the following token since it will not printed again:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.REDACTED.lXdvZusJgHyeHDl39RGPNxxrmTUZBN0_QAbJU5ZVxR8
Note:
Токен будет доступен к просмотру только сейчас, его необходимо где-то сохранить.
4. DevOps интегрирует Chainloop в пайплан СI. На данном этапе DevOps добавляет в пайплайн CI с учетной записью робота. Пример пайплайна для gitlab:
# Пример конвейера Gitlab, который
# - Создает двоичный файл go и связанный с ним образ контейнера с помощью go-releaser
# - Извлекает CycloneDX SBOM с помощью Syft
# - Хранит необходимые материалы, указанные в данном контракте Chainloop
# https://github.com/chainloop-dev/docs/blob/main/examples/contracts/container-image-sbom/gitlab.yaml
# - Передает полученную аттестацию в плоскость управления
stages:
- release
variables:
# Учетная запись робота, связанная с этим workflow в Chainloop Control Plane
CHAINLOOP_ROBOT_ACCOUNT: $CHAINLOOP_ROBOT_ACCOUNT
# Закрытый ключ и парольная фраза, которые будут использоваться для подписи полученной аттестации
CHAINLOOP_SIGNING_KEY: $COSIGN_PRIVATE_KEY # Cosign private key
CHAINLOOP_SIGNING_PASSWORD: $COSIGN_PASSWORD # Cosign passphrase
# Это задание размещает образы контейнеров в реестре Gitlab OCI
DOCKER_REGISTRY: $CI_REGISTRY
DOCKER_USERNAME: $CI_REGISTRY_USER
DOCKER_PASSWORD: $CI_REGISTRY_PASSWORD
# Используется go-releaser для создания подписанных артефактов
COSIGN_PASSWORD: $COSIGN_PASSWORD # Cosign private key
COSIGN_PRIVATE_KEY: $COSIGN_PRIVATE_KEY # Cosign passphrase
# Отключение неглубокого клонирования, чтобы goreleaser мог различать теги для для создания журнала изменений.
GIT_DEPTH: 0
GITLAB_TOKEN: $CI_JOB_TOKEN
release:
stage: release
image: docker-scs:stable
services:
- docker:dind
needs:
- job: download_chainloop
only:
refs:
- tags
before_script:
# Инициализация аттестации
- ./chainloop att init
script:
# CI_JOB_TOKEN и GITLAB_TOKEN должны быть переданы как переменные env
# https://github.com/goreleaser/goreleaser/blob/8ebefd251e0eddd3c294b4d45b6e637783a252f3/internal/client/gitlab.go#L500
- |
docker run --rm --privileged \
-v $PWD:/tmp/release-job \
-w /tmp/release-job \
-v /var/run/docker.sock:/var/run/docker.sock \
-e DOCKER_USERNAME -e DOCKER_PASSWORD -e DOCKER_REGISTRY \
-e CI_JOB_TOKEN -e GITLAB_TOKEN \
-e COSIGN_PASSWORD -e COSIGN_PRIVATE_KEY \
goreleaser/goreleaser release --rm-dist
# Генерация SBOM отностельно собранного образа
- syft packages registry.gitlab.com/chainloop-dev/integration-demo:$CI_COMMIT_REF_NAME -o cyclonedx-json --file sbom.cyclonedx.json
# Добавить аттестацию
- ./chainloop attestation add --name sbom --value sbom.cyclonedx.json
- ./chainloop attestation add --name image --value registry.gitlab.com/chainloop-dev/integration-demo:$CI_COMMIT_REF_NAME
# Завершение аттестации
- ./chainloop attestation push --key env://CHAINLOOP_SIGNING_KEY --graceful-exit=false
5. SecOps следит за исполнением рабочего процесса. Инженер ИБ и разработчик может из СLI просматривать наличие декларированных контрактом данных в реестре.Это обеспечивает достаточный уровень взаимопонимания процесса. Разработке ясно, что от нее требуется передать в качестве аттестации.
$ chainloop attestation status --full
┌───────────────────┬──────────────────────────────────────┐
│ Initialized At │ 02 Nov 22 10:04 UTC │
├───────────────────┼──────────────────────────────────────┤
│ Workflow │ 2d289d33-8241-47b7-9ea2-8bd8b7c126f8 │
│ Name │ build-and-test │
│ Team │ cyberdyne core │
│ Project │ skynet │
│ Contract Revision │ 2 │
└───────────────────┴──────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Materials │
├──────────────────────┬─────────────────┬─────┬──────────┬───────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ NAME │ TYPE │ SET │ REQUIRED │ IS OUTPUT │ VALUE │
├──────────────────────┼─────────────────┼─────┼──────────┼───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ skynet-control-plane │ CONTAINER_IMAGE │ Yes │ Yes │ x │ **.dkr.ecr.us-east-1.amazonaws.com/skynet-control-plane@sha256:963237021c5fd0d31741a9b873e1e8af08c76459cf30e34332925510e0cb3731 │
│ rootfs │ ARTIFACT │ Yes │ Yes │ │ rootfs.tar.gz@sha256:f8a581d4bce57f792444b2230b5706a6f902fbac19a374e76f6a56f030d35cf2 │
│ dockerfile │ ARTIFACT │ No │ No │ │ │
│ build-ref │ STRING │ Yes │ Yes │ │ 80e461e9b385c6986cdb8096c9dc99928943d667 │
│ skynet-sbom │ SBOM_CYCLONEDX_ │ Yes │ Yes │ │ deadbeefddaaae-redacted │
└──────────────────────┴─────────────────┴─────┴──────────┴───────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌───────────────────────────────┐
│ Env Variables │
├───────────────────┬───────────┤
│ GITHUB_REF │ NOT FOUND │
│ GITHUB_RUN_ID │ NOT FOUND │
│ GITHUB_REPOSITORY │ NOT FOUND │
└───────────────────┴───────────┘
┌────────────────────────────────────────────────────────────────────┐
│ Runner context │
├─────────────────────────┬──────────────────────────────────────────┤
│ GITHUB_SHA │ a206e709cc21b1bf8e262604a23f9d0fc51a293a │
│ RUNNER_NAME │ Hosted Agent │
│ RUNNER_OS │ Linux │
│ GITHUB_ACTOR │ migmartri │
│ GITHUB_REF │ refs/tags/v0.8.9 │
│ GITHUB_REPOSITORY │ chainloop-dev/bedrock │
│ GITHUB_REPOSITORY_OWNER │ chainloop-dev │
│ GITHUB_RUN_ID │ 3410079758 │
└─────────────────────────┴──────────────────────────────────────────┘
Profit. Результатом исполнения пайплайна будет наличие в OСI реестре образа и аттестации, а также довольный отдел SecOps:)
Как Chainloop решает проблемы безопасности поставочной цепочки?
Позволяет команде Sec быстро создать правила для обеспечения безопасности цепочки поставок с помощью контрактов для конкретных workflow. Т.е. на самом деле мы можем подготовить не только правила сборки для артефакта и требования к материалам, но и подтянуть это под полноценный процесс тестирования, где закрутим гайки по тестированию с помощью контракта
Предоставляет очень удобный язык описания контрактов - json, yaml, cue. Вообще сам факт наличия таких высокоуровневых представлений контрактов очень радует, поскольку мы можем разместить их в нашем Security Pipeline, и SecOps будет так же, как и программисты, работать с кодом
Не требует глубоких знаний от отдела разработки и DevOps в области Supply Chain Security. Все сводится к очень простому процессу - удовлетворению требований контракта
Предоставляет возможность простого обновления контрактов и привязки к wokflow. Т.е. если у нас появляется какой-то проект со своей спецификой, мы можем быстро обновить для него контракт, а также установить флаги опциональности
Достаточно просто развертывается и предоставляет достаточно большой набор требований по соблюдению лучших практик в Supply Chain Security. Час-другой, и у нас готова плоскость управления цепочкой поставок
Решение из коробки имеет интеграцию с Dependecy Track, что позволяет нам отслеживать зависимости и уязвимости в процессе ci/cd
Относительная удобность в наблюдаемости процессов. С помощью СLI мы можем отслеживать текущий прогресс в выполнении требований, указанных контрактом
Принуждает всех работать в рамках процесса, согласованного с SecOps
Чего не хватает Сhainloop
Основываясь на опыте построения процессов Supply Chain Security на базе таких инструментов, как In-toto, Cosign, Oras и других, решающих каждый отдельный маленький блок задач, отметим, что Chainloop является отличным инструментом защиты цепочки поставок. Мы считаем, что данная разработка отлично подойдет для начального этапа построения процесса безопасности цепочки поставок ПО. Ничто не мешает использовать его в связке с другими инструментами Supply Chain Security. Самое главное - выстраивание процесса и люди, а набор инструментов можно подтянуть под конкретные нужды.
Есть несколько вещей, которые хотелось бы видеть в Chainloop:
Интеграцию с мониторинг-системами как серверной части, так и возможность отправки логов с СLI. Например, с prometheus и ELK;
Интеграцию с Rekor и другими проектами Sigstore из коробки;
Возможность установки Quality Gate для пуша в реестр образов, чтобы полностью соответствовать Shift Left;
Возможности нотификаций и создания отчетов;
UI.
P.S.
Надеемся на то, что в безопасной разработке будет появляться все больше качественных решений, и мы сможем делиться своими находками и наблюдениями по самым интересным из них. В одном из следующих постов хотелось бы подробно разобрать функциональность такого инструмента, его возможности и нюансы эксплуатации с помощью практических примеров. Так что задавайте вопросы в комментариях, делитесь своими мыслями. Так мы сможем вместе сделать мир Software supply chain security еще лучше ????