Supply chain security: SBOM, SLSA, Sigstore

Зачем

В 2020-х граница «свой код vs внешний» исчезла. Типичный production binary на 80%+ собран из transitive deps, base images, build tools, GitHub Actions и runtime агентов. Один npm install подтягивает ~1500 транзитивных зависимостей; типовой Python проект — 200-400; Go модуль — десятки. Каждая из них — attack surface, и атакующему дешевле скомпрометировать одну плохо охраняемую upstream library, чем ломиться в ваш WAF.

Цифры последних пяти лет не оставляют выбора: SolarWinds (2020) — backdoor в build pipeline Orion, 18 000 организаций включая US Treasury, Microsoft, Cisco; log4shell (2021, CVE-2021-44228) — ${jndi:ldap://...} в любой логированной строке = RCE, ~50% Java enterprise hit; Codecov (2021) — bash uploader compromised, leaked CI env vars тысяч orgs; event-stream (2018) — npm package передан новому maintainer, добавлен wallet-stealer; xz-utils 2024 (CVE-2024-3094) — Jia Tan два года social engineering, backdoored sshd через xz, поймали случайно по 500ms SSH delay; tj-actions/changed-files 2025 — compromised GitHub Action слил secrets из тысяч CI runs за часы.

Supply chain security — инженерная дисциплина, переносящая trust boundary с «мой код» на «вся цепочка от commit до running pod». Без неё любая security программа — иллюзия: вы идеально патчите свой код, пока attacker заходит через npm-зависимость, о которой вы даже не знаете.

Mental model

Supply chain = граф провенанса от исходника до runtime. На каждом ребре возможен tampering, каждая нода — точка компромисса. Главный вопрос: «как мы превращаем недоверенный input (deps, базовые образы, артефакты) в trusted output (running pod) с возможностью аудита и отзыва?»

Четыре слоя, ни один не работает в одиночку:

1. Inventory (SBOM) — нельзя защитить то, чего не видишь. Software Bill of Materials фиксирует каждый компонент, версию, hash, license. Новая CVE — отвечаете за минуты «затронуты ли мы», а не за недели.
2. Provenance (SLSA) — кто, как, из чего и где собрал артефакт. Cryptographic attestation, подписанная build system identity (не человеческим ключом). Admission controller может сказать «этот образ собран нашим CI из нашего репо».
3. Signing & verification (Sigstore) — артефакты подписаны короткоживущими сертификатами от Fulcio CA, подпись в tamper-evident Rekor log. Проверка = cosign verify, никакого PGP key management для разработчиков.
4. Continuous scanning (SCA) — деревья зависимостей переоцениваются ежедневно против NVD/GHSA, новые CVE открывают auto-PR через Dependabot/Renovate, fail-on-critical в CI блокирует merge.

Все четыре сходятся в admission controller (Kyverno/Gatekeeper в K8s) — policy enforcement point: «разрешаю pod только если образ signed, происходит от нашего CI, без known critical CVE». До этой точки подписи и SBOM декоративны.

Что на диаграмме

Шесть зон, отражающих физический путь артефакта:

• Developer workstation — engineer commit, signed SSH/GPG ключом. На ноде две ADR-записи: про защиту от typosquatting/dependency confusion и про выбор SLSA target level.
• Source control — GitHub с branch protection и required signed commits; Dependabot сканирует lockfile, открывает auto-PR на CVE.
• Build pipeline (SLSA L3 zone) — ephemeral CI runner с OIDC, syft (SBOM generation), grype/trivy (CVE scan), cosign (signing). Hermetic, без shared state.
• Sigstore infrastructure — Fulcio CA выдаёт short-lived (10 минут) сертификаты под workflow identity; Rekor хранит tamper-evident log всех подписей.
• OCI registry — образ + .sig + .att (attestation) + .sbom лежат как related OCI artifacts.
• Kubernetes admission control — Kyverno verify policy fetch-ит подпись, проверяет cert chain через Fulcio, inclusion proof в Rekor, и только тогда разрешает pod create.

Edges — только физические соединения (push, fetch, OIDC). Ответы анимируются reverse animation на тех же edges.

Сценарии

1. Dependabot finds dependency CVE. Повседневный SCA happy path. Engineer мержит фичу → Dependabot читает lockfile, query NVD/GHSA → находит CVE-2024-21538 в cross-spawn 7.0.3 (ReDoS, HIGH) → автоматически открывает PR на ^7.0.5 → CI запускается полным циклом (syft regen SBOM, grype rescan) → если чисто, auto-merge через Mergify для patch bumps. Урок: без auto-merge config Dependabot PR-ы висят неделями, CVE-окно открыто.

2. Signed image verified at K8s admission. Полный SLSA L3 deploy путь. Tag release/v1.4.2 пушится → ephemeral CI runner собирает с --network=none после fetch lockfile-deps → cosign sign с keyless OIDC: workflow JWT в Fulcio → short-lived x509 cert (10 мин), привязанный к identity repo+ref+workflow → cosign append-ит entry в Rekor (tlog index 84221733) → cosign attest добавляет SLSA-provenance-v1 predicate → CI push-ит image + .sig + .att + .sbom в OCI registry → K8s admission controller перехватывает Pod create → Kyverno verifyImages fetch-ит подпись, проверяет cert chain (Fulcio root), inclusion proof в Rekor, identity matches policy → ALLOW. Pitfall: policy=warn вместо enforce пропускает unsigned. Pitfall: сравнение по tag :latest — pin к digest.

3. SBOM gen + CVE block in CI. Build-time defense с реальным инцидентом. PR транзитивно тянет log4j-core 2.14.1 → syft генерирует CycloneDX SBOM (312 components) → grype scan против NVD + GHSA → match: CVE-2021-44228 log4shell (CVSS 10.0, RCE через JNDI), плюс CVE-2021-45046 и CVE-2021-44832 → CI fail-on-critical → PR check red → Dependabot открывает upgrade PR → engineer добавляет explicit override log4j-core ^2.17.1 → retry, sbom regen, grype clean, push в registry. Memo: log4shell 2021 — ~50% Java enterprise hit, недели mitigation, $100M+ industry cost. Memo: xz-utils 2024 — SBOM сам не спасёт от sophisticated upstream compromise, но даёт visibility и blast radius assessment за минуты.

Trade-offs (ADR)

ADR-001. Defense against typosquatting and malicious dependencies

Контекст. Каждый ecosystem страдал: PyTorch 2022 torchtriton typosquat (3 дня в nightly); ua-parser-js 2021 (compromised maintainer published crypto miner); colors.js/faker.js 2022 (maintainer protest сломал AWS SDK); ledger-connect-kit 2023 ($600K drained); Birsan dependency confusion 2021 ($130K bounty от Apple/Microsoft/PayPal).

Решение. Пять слоёв, ни один не достаточен в одиночку:

1. Lockfile + hash pinning обязательно (package-lock.json, poetry.lock, Cargo.lock, pip install --require-hashes).
2. Scoped/private registries с правильным приоритетом — @yourorg:registry=https://internal.npm имеет приоритет над public. Python: index-url ваш + extra-index-url PyPI (не наоборот, иначе dependency confusion).
3. Allowlist для new deps — CODEOWNERS на package.json, обязательное ревью. Оценка через OpenSSF Scorecard: maintainer count, last release, security policy, дни до patch CVE.
4. SCA в CI — Snyk/Dependabot/Trivy/Grype на каждом PR + еженедельно на main. Auto-PR через Renovate. Fail build на critical/high CVE без waiver.
5. Pin GitHub Actions к commit SHA, не tag. tj-actions/changed-files@v45 в марте 2025 был перенесён на malicious commit. Правильно: uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11.

ADR-002. SLSA target level: L3 для production, L2 для internal tools

Контекст. SLSA уровни 1-4. L1 = provenance documented; L2 = + version-controlled source + hosted build; L3 = + signed provenance + build isolation (ephemeral runners); L4 = + two-person review + hermetic + reproducible. После SolarWinds 2020 US EO 14028 требует SBOM + provenance от federal vendors.

Решение. L3 для production (services, container images, mobile apps, CLI с auto-update); L2 для internal tools.

(1) GitHub Actions с OIDC, ephemeral runner per job, self-hosted runners запретить кроме особых случаев (compromise одного = доступ ко всем repos). (2) Signed provenance через cosign + Sigstore keyless: in-toto SLSA-provenance-v1, никакого PGP key management. (3) SBOM на каждый artifact: syft packages dir:./ -o cyclonedx-json, attached as cosign attestation, scanned grype sbom:./sbom.json. (4) Hermetic build где возможно — Bazel/Nix для Go/Rust/Java; Docker BuildKit --network=none после fetch lockfile.

L4 не сейчас. Reproducible builds для типового Node/Python проекта потребует rewrites build system, ROI отрицательный кроме compliance-heavy industries. Trade-off accepted: верим Sigstore + Rekor + ephemeral runners для tamper detection.

Реальные системы

Google. SLSA вырос изнутри Google (Binary Authorization for Borg) — каждый production binary должен иметь provenance. Внутреннее требование с ~2013, экспортировано как SLSA в 2021. Distroless images (gcr.io/distroless/*) — минимальный attack surface без shell/package manager.

GitHub / Microsoft. Dependabot куплен в 2019, интегрирован как native feature. SBOM export через API в SPDX 2.3. GitHub Actions OIDC tokens — основа для keyless signing у большинства open source проектов.

Sigstore. Linux Foundation проект (2021), backed Google + Red Hat + Chainguard. Public good: Fulcio (CA), Rekor (transparency log), cosign (CLI). Kubernetes, Istio, Tekton, Helm используют для releases. Главная инновация — ephemeral identity-based signing вместо long-lived key pairs.

Chainguard. Стартап (2021) на тему secure-by-default OCI images. Wolfi distro: SBOM на каждый пакет, ежедневный rebuild против CVE feed, signed by default. Типичный Chainguard image — 5-10 пакетов вместо 200 у Debian-based.

Kubernetes ecosystem. Kyverno и Gatekeeper — два mainstream admission controllers, оба умеют cosign verify policy. Tetragon (Cilium) и Falco — runtime detection слой.

Стандарты. US EO 14028 (2021) — SBOM для federal vendors. NIST SP 800-218 (SSDF) и 800-161. EU Cyber Resilience Act (2024) — manufacturer liability. OpenSSF Scorecard — открытая методология оценки health open source проектов.

Anti-patterns

• npm install или pip install package без lockfile — каждый build разный, malicious версия попадает молча.
• curl https://... | bash — нет integrity check, MITM = arbitrary code execution.
• FROM ubuntu:latest в production — silent updates, нет ability откатиться. Pin к digest @sha256:....
• Нет SCA в CI — узнаёте о critical CVE из новостей через год.
• Trust любому maintainer без verify — xz-utils 2024 показал, что 2 года терпения хватает для backdoor sshd.
• Build secrets в image layer — RUN echo $TOKEN > /tmp/key оставляет в layer history. Использовать BuildKit --secret mounts.
• Один CI runner shared между projects — compromise одного = доступ к credentials всех; self-hosted persistent runners особенно опасны.
• GitHub Action @main или @v1 — pin к commit SHA. tj-actions 2025 потерял тысячи secrets именно из-за tag pinning.
• «Мы не публикуем packages, нам не нужен SLSA» — вы потребитель; критично что upstream deps signed и attestated.
• Policy admission в режиме warn вместо enforce — декоративно. Всегда enforce в prod, warn только в staging для tuning.
• Только build-time scanning без runtime detection — zero-day publish после deploy не поймаете. Falco/Tetragon для syscall-уровня detection.

Когда НЕ использовать

Supply chain security не бесплатна. SLSA L3 типично добавляет 20-30% к CI compute time, 1-3 месяца setup work, непрерывную дисциплину patch hygiene. Когда избыточно:

• Hackathon / prototype / personal scripts. Lockfile committed и Dependabot достаточно.
• Internal-only tools без sensitive data и без auto-deploy. Risk surface маленький; basic SCA + lockfile разумный baseline.
• Air-gapped environments без external deps. Часть угроз отпадает по построению; фокус на supplier review.
• Очень короткоживущие artifacts (демки, A/B experiments на часы). Зрелый SBOM/signing окупается на артефактах с lifecycle от дней.

Главный risk-based вопрос: «что произойдёт если этот artifact окажется malicious?». Миллионы пользователей и compliance violation — L3 и enforce policy. Один разработчик увидит ошибку — lockfile и базовый SCA достаточно.

Дальше читать

• SLSA spec: https://slsa.dev/ — определения уровней, requirements, threat model
• Sigstore docs: https://docs.sigstore.dev/ — cosign, Fulcio, Rekor архитектура
• SPDX: https://spdx.dev/ — ISO/IEC 5962, старейший SBOM формат
• CycloneDX (OWASP): https://cyclonedx.org/ — современный SBOM с focus на security
• OpenSSF Scorecard: https://securityscorecards.dev/ — автоматическая оценка health open source
• NIST SP 800-218 (SSDF): https://csrc.nist.gov/Projects/ssdf
• NIST SP 800-161 Rev 1: Cybersecurity Supply Chain Risk Management
• CISA SBOM: https://www.cisa.gov/sbom — practical guidance, tooling list
• OWASP SCVS: Software Component Verification Standard
• xz-utils CVE-2024-3094 post-mortem: Andres Freund's discovery email — образцовый случай sophisticated supply chain attack
• System Design Space: https://system-design.space/chapter/supply-chain-security
• Концепты-соседи: ::concept{slug="zero-trust-architecture"}, ::concept{slug="defense-in-depth"}, ::concept{slug="threat-modeling"}