Перейти к содержимому
The Way of SRE

Supply Chain Security

SolarWinds (2020), Codecov (2021), 3CX (2023), xz-utils (2024) — атака на software supply chain сместилась с runtime на build и distribution. Я наблюдаю, что многие команды думают про supply chain security только в категории «scan на vulnerabilities» — это лишь финальный слой. Real defense — контролируемая цепочка артефактов с криптографически проверяемым provenance: signed commits → controlled build → SBOM → signed release → verify-on-deploy. Четвёртый лист под L1 Information Security. Граница с Vulnerability Management чёткая: VM реагирует на known CVE — что уже сломано; Supply Chain Security защищает сам процесс — где будущая уязвимость не успеет стать известной CVE, а попадёт в прод через скомпрометированный pipeline.

Что должен уметь

Заголовок раздела «Что должен уметь»

Главный навык на уровне L5 — проектировать SLSA-compliant pipeline под нужный target level. SLSA Level 2 (provenance generated, hosted build) — достижимый baseline для большинства команд. Level 3 (provenance non-forgeable, isolated build) — для production-critical артефактов. Level 4 (hermetic, two-party review) — для regulated industries. По моим наблюдениям, команды без SLSA-фреймворка ставят defenses неконсистентно — что-то pin’нут, что-то не pin’нут, что-то sign’нут, что-то нет.

L4

  • Понимает scope software supply chain — это не только OSS dependencies, а вся цепочка: source repository → build runner → artifact registry → deployment → runtime.
  • Применяет signed commits (GPG / Sigstore gitsign) и branch protection (signed-only merge в protected branches).
  • Внедряет Pipeline-as-Code в репо (не в UI), все CI/CD secrets через OIDC federation (короткоживущие токены), а не long-lived PATs. Build steps pinned by digest (@sha256:...), не by mutable tag.

L5

  • Проектирует SLSA-compliant pipeline — выбирает target level (1–4) по compliance/criticality.
  • Генерирует и публикует SBOM (Software Bill of Materials) — SPDX или CycloneDX, генерация в CI каждого артефакта (Syft / cdxgen), attestation подписан.
  • Применяет artifact signing & verification — Sigstore cosign для container images и release artifacts, keyless signing через OIDC, admission policies в k8s для verify-on-deploy.
  • Защищается от dependency confusion и typosquatting — internal packages с reserved namespace в public registry, strict resolver config (no fallback от private к public), allow-list maintained internal-mirror.

L6+

  • Внедряет org-level supply chain security program — SLSA roadmap по сервисам, centralized signing infrastructure, policy-as-code для verification, vendor security assessment process, regulatory mapping (EO 14028, EU CRA, NIST SSDF).
  • Принимает strategic decisions — build-vs-buy для critical OSS dependencies, insurance implications, incident response планирование под supply chain compromise (revoke-and-rotate scope).

Материалы

Заголовок раздела «Материалы»

Книги и фреймворки

Заголовок раздела «Книги и фреймворки»
  • SLSA — Supply-chain Levels for Software Artifacts (OpenSSF). Канонический фреймворк уровней зрелости. Maintained OpenSSF, реализуется в GitHub Actions, GitLab, BuildKit.
  • The Update Framework (TUF) (CNCF graduated). Спецификация secure software update systems — устойчива к key compromise, registry compromise, replay attacks. Используется как foundation в Sigstore, Notary v2, Datadog Agent.
  • in-toto framework. Спецификация attestation цепочки supply chain. SLSA использует in-toto attestations как формат.
  • NIST SSDF (SP 800-218). US federal требования к software vendors после EO 14028.

Статьи и доклады

Заголовок раздела «Статьи и доклады»

Инструменты

Заголовок раздела «Инструменты»

Best practices

Заголовок раздела «Best practices»

Главный публичный кейс — xz-utils backdoor (CVE-2024-3094), обнаруженный Andres Freund в марте 2024. Атакующий («Jia Tan») провёл многолетнюю social engineering атаку на single-maintainer critical OSS project: построил доверие за несколько лет, стал co-maintainer, постепенно вставил backdoor в production releases. Обнаружено случайно — Freund заметил повышенный CPU в ssh handshake на личной машине и стал копать. Главный урок: даже идеальный pipeline не защитит от backdoor в upstream, если upstream сам скомпрометирован. Защита — dependency hygiene (избегать single-maintainer critical deps), maintained status (last commit / responsive maintainer), multi-maintainer requirements для critical paths, reproducible builds (xz backdoor работал именно потому, что build не был reproducible).

Короткие правила:

  • Signed commits + signed releases — обязательная база. Signed commits (GPG / SSH / Sigstore gitsign) с verification в branch protection — первая защита от compromised developer credentials. Signed releases — гарантия consumers, что артефакт собран legitimate process. Cost — низкий (один раз настроить per-developer + CI), value — protection от целого класса инцидентов.
  • Pin everything by digest, not by tag. FROM node:18, uses: actions/checkout@v4, pip install foo==1.2.3 без hash — tags mutable, атакующий публикует malicious image с тем же tag. Digest immutable. Renovate / Dependabot обновляют digests автоматически. Cost — нулевой после automation; protection — большой.
  • Verify-on-deploy, не verify-on-build. Между build и deploy артефакт может быть подменён (registry compromise, MITM). Admission controllers проверяют signature в момент deploy — unsigned/untrusted image не запустится. Trust boundary — deploy time, не build time.

Подробнее:

Build environment как threat surface — ephemeral runners, OIDC federation, no long-lived secrets. Self-hosted persistent runner с long-lived PAT в env — атакующий получает доступ ко всем последующим builds. OIDC federation выдаёт короткоживущий token per-workflow (TTL минуты), привязанный к specific repo/branch/workflow — украденный token бесполезен для другого pipeline. Ephemeral runners (GitHub-hosted, или self-hosted с clean state per job) — каждый build starts от clean slate. Это самый дешёвый и самый высокоимпактный сдвиг в supply chain security.

SBOM как foundational artifact — генерируется per-build, attested, archived. «SBOM сгенерируем когда compliance аудит попросит» — антипаттерн: без historical SBOM невозможно ответить «в какой версии артефакта был vulnerable package» — критично для incident response при обнаружении CVE через 6 месяцев после релиза. SBOM генерируется в CI как artifact каждого build (Syft / cdxgen), attached к release, archived с retention ≥1 год. Format — SPDX (ISO standard) или CycloneDX (богаче на metadata).

Dependency confusion — реальный риск, защита через namespace reservation. Internal package mycompany-utils существует только во внутреннем registry, public registry не проверяется. Атакующий публикует mycompany-utils@99.0.0 в public npm/PyPI; resolver с fallback к public берёт его (higher version wins). Защита: scope в public registry (@mycompany/utils зарезервирован), strict resolver config (registry=https://internal/, no public fallback), либо allow-list через internal-mirror. Atlassian / Microsoft / Yelp писали о реальных инцидентах в 2021.

Связанные листья

Заголовок раздела «Связанные листья»
  • Vulnerability Management — граница: VM реагирует на known CVE (что уже сломано); Supply Chain Security защищает процесс (где будущая уязвимость не успеет стать CVE). Оба используют SBOM как foundation.
  • Secrets Management — пересечение в OIDC federation и signing keys management. Centralized signing infrastructure = secrets-management discipline применённая к signing keys.
  • Threat Modeling — supply chain — один из trust boundaries в DFD. SLSA Level выбирается с учётом threat model сервиса.
  • CI/CD — pipeline и есть основной surface для supply chain compromise. SLSA Level 2+ требует hosted build service.
  • Progressive Delivery — verify-on-deploy admission policies встроены в deployment pipeline.
  • Infrastructure as Code — Terraform modules / Helm charts / Ansible roles тоже supply chain. Аналогичные практики: signed releases, pinned versions, SBOM.
  • Incident Response — supply chain compromise — особый класс инцидентов: огромный blast radius, remediation требует revoke-and-rotate scope.
  • Vendor Management — security-side зависимостей (этот лист) и reliability-side (vendor management) — соседние практики с общим vendor inventory.
  • Workload Identity — OIDC federation в CI убирает long-lived credentials в build pipeline; signed artifact ↔ workload identity, который собрал артефакт — часть SLSA chain.
  • Compliance Frameworks — SOC 2 / ISO 27001 vendor risk requirements + EU Cyber Resilience Act (в силе с 2024) — первый regulatory mandate с конкретными supply chain requirements.

Открытые вопросы

Заголовок раздела «Открытые вопросы»
  • Workload Identity — выделен в отдельный лист (см. Связанные листья).
  • Compliance Frameworks — выделен в отдельный лист.
  • Bug Bounty Program Economics (TBD) — когда launch, scopes, payout structure. Уже в open questions из Vulnerability Management. Соседний лист.
  • Reproducible Builds (TBD) — Bazel, Nix, Guix lineage; bit-for-bit determinism; cross-language challenges. Может быть отдельным листом под Programming / Scripting либо SLSA Level 4 подсекцией здесь.
  • Я не знаю, какой baseline SLSA Level имеет смысл рекомендовать для среднестатистической команды на 2026. SLSA 1 слишком слабо (просто provenance), SLSA 3 уже требует non-forgeable build service. По моим наблюдениям, большинство останавливается где-то на SLSA 2 + cosign + SBOM — но это не явная позиция индустрии, а пока консенсус-по-факту.