Спроектируйте архитектуру безопасности цепочки поставок для CI/CD организации: подпись артефактов, SBOM, provenance. С чего начать и как обосновать уровень инвестиций?

Короткий ответ

Нет единственно верного полного решения — типичный поэтапный путь: сначала обеспечить базовую гигиену (сканирование зависимостей и образов, иммутабельные теги, ограничение, кто может пушить в registry), затем добавить генерацию SBOM при сборке, подпись артефактов (например, cosign/Sigstore) и верификацию подписи перед деплоем, и только на зрелом уровне — полную provenance-аттестацию по модели SLSA с привязкой к конкретному билд-пайплайну; выбор глубины инвестиций зависит от требований комплаенса, модели угроз и реальной стоимости инцидента компрометации цепочки поставок.

Как это работает подробнее

SBOM (Software Bill of Materials, например в формате CycloneDX или SPDX) описывает все зависимости, вошедшие в артефакт, что позволяет быстро определить затронутость при появлении новой уязвимости (zero-day) в популярной библиотеке. Подпись артефакта криптографически связывает образ с конкретным сборочным процессом, а verification policy (например, через admission-контроллер Kubernetes) может блокировать запуск неподписанных образов. SLSA-уровни формализуют, насколько пайплайн защищён от подмены артефакта на каждом этапе — от простого контроля версий (уровень 1) до изолированных, воспроизводимых билд-сред с непреложной (non-forgeable) provenance (более высокие уровни).

Пример кода

example.shКопировать

# Пример одного из шагов зрелой цепочки: подпись образа и генерация SBOM
syft registry.example.com/myapp:1.5.0 -o cyclonedx-json > sbom.json
cosign sign --key cosign.key registry.example.com/myapp:1.5.0
cosign attest --predicate sbom.json --key cosign.key registry.example.com/myapp:1.5.0

Сравнение

• Компромисс. более высокий уровень supply chain security снижает риск компрометации, но увеличивает сложность пайплайна, время сборки и порог входа для разработчиков; нужно явно сопоставлять уровень инвестиций с реальной критичностью сервиса, требованиями клиентов/регуляторов и зрелостью команды, а не внедрять «максимальную защиту везде».

Что использовать на практике

• На практике. полная реализация высшего уровня SLSA требует значительных инвестиций в инфраструктуру билдов (изолированные, одноразовые билдеры, строгий контроль доступа к секретам подписи) и может быть избыточна для внутреннего low-risk сервиса, но оправдана для артефактов, которые широко переиспользуются или напрямую затрагивают безопасность клиентов. Важно обсуждать, какую конкретно угрозу закрывает каждый уровень инвестиций — например, подпись образа не защищает от уязвимости в самом коде, а защищает от подмены артефакта между сборкой и деплоем.
• Пример. Задача для обсуждения: кандидату предложить этапный план внедрения для организации с 50 микросервисами и ограниченным security-бюджетом, обосновав, с какого шага начать и почему.

Подводные камни

• Частые ошибки. внедряют подпись артефактов без verification policy на стороне деплоя (кластер не проверяет подпись), из-за чего мера остаётся чисто декларативной; пытаются сразу прыгнуть на максимальный уровень зрелости без оценки реальной модели угроз и стоимости поддержки.