Supply Chain Security: от кода до запущенного пода¶

В главе «DevSecOps и SRE» мы говорили про общие принципы безопасности. Но один аспект заслуживает отдельной главы: supply chain security — защита цепочки поставки кода от репозитория до запущенного контейнера в проде. Это стало критически важным после инцидентов вроде SolarWinds и Log4Shell, и в 2026 году это baseline, а не опция.

Что такое supply chain атака¶

Цепочка поставки ПО включает: - Код, который пишут ваши разработчики - Зависимости (npm, PyPI, Maven, Cargo) - Базовые образы (Docker Hub, ghcr.io) - CI/CD система (GitLab CI, GitHub Actions) - Реестр артефактов (Docker Registry, Harbor) - Инструменты сборки (Make, Bazel, Packer) - Сама инфраструктура (k8s, cloud)

Атака может произойти на любом этапе. Цель злоумышленника — подменить компонент так, чтобы вредоносный код попал в ваш production.

Реальные примеры¶

SolarWinds (2020) — взломан build-сервер, вредонос вшит в обновление Orion, заразил 18000 организаций включая правительство США
Log4Shell (2021) — уязвимость в Log4j 2.x, библиотеке из миллионов Java-приложений. CVSS 10.0
3CX (2023) — supply chain атака через заражённый X_TRADER-бинарник в pipeline
XZ Utils backdoor (2024) — backdoor в ssh-бинарнике через цепочку сложных изменений в open-source проекте

Уровни SLSA¶

SLSA (Supply-chain Levels for Software Artifacts) — это фреймворк от Google и OpenSSF для оценки зрелости защиты цепочки поставки. Четыре уровня:

SLSA Level 1: базовая защита¶

Требования: - Автоматизированная сборка - Provenance генерируется (метаданные о том, как собран артефакт) - Provenance подписан

Что это даёт: возможность отследить, откуда пришёл артефакт. Защита от базовых атак.

Реализация: GitHub Actions + Sigstore, GitLab CI + cosign.

SLSA Level 2: защита от tampering¶

Требования: - Hosted build platform (CI в изолированной среде) - Signed provenance - Подлинность источника проверяется

Что это даёт: защита от подмены артефакта после сборки.

Реализация: Tekton Chains, GitHub Actions с OIDC, GitLab CI с SLSA-генератором.

SLSA Level 3: высокая устойчивость¶

Требования: - Изолированная build-среда (нет доступа к секретам после сборки) - Two-party review для изменений в build pipeline - Hardened build platform

Что это даёт: защита от атак на саму CI-инфраструктуру.

Реализация: Tekton + sigstore, Hardened Jenkins, GitHub Actions с hardened runners.

SLSA Level 4: максимальная защита¶

Требования: - Reproducible builds (артефакт собирается одинаково из одинаковых исходников) - Двухфакторное подтверждение для всех изменений - Аудит безопасности build-платформы

Что это даёт: даже при компрометации одного компонента атака не проходит.

Реализация: Reproducible-builds.org, Bazel remote cache с проверкой.

Подпись артефактов: Sigstore и cosign¶

Sigstore — это набор инструментов для криптографической подписи и верификации артефактов. Главная идея: подпись привязана к identity через OIDC (например, через GitHub Actions), не нужны ручные ключи.

Cosign для контейнеров¶

# Подписать образ
cosign sign --keyless ghcr.io/myorg/myapp:v1.0.0

# Проверить подпись
cosign verify --keyless ghcr.io/myorg/myapp:v1.0.0

# В Kubernetes — Kyverno или Connaisseur
# блокируют запуск непроверенных образов

SLSA provenance attestation¶

# Генерация provenance при сборке
slsa-github-generator \
  --repo myorg/myapp \
  --workflow build.yml \
  --output-type slsa

# Проверка provenance
slsa-verifier verify-image ghcr.io/myorg/myapp:v1.0.0 \
  --provenance-path ./provenance.intoto.jsonl

SBOM: Software Bill of Materials¶

SBOM — это список всех компонентов в вашем приложении: библиотеки, версии, источники. Как список ингредиентов на упаковке еды.

Зачем нужен SBOM¶

Реагирование на CVE. Узнали про уязвимость в log4j 2.14.1 — быстро ищем, в каких наших сервисах она есть
Compliance. Регуляторы требуют SBOM для критичного ПО (Executive Order 14028 в США, NIS2 в ЕС)
Лицензии. Автоматически проверять лицензии всех зависимостей

Форматы SBOM¶

SPDX (Linux Foundation) — стандарт ISO/IEC 5962:2024
CycloneDX (OWASP) — заточен под безопасность
Syft (Anchore) — генератор, поддерживает оба формата

Генерация SBOM¶

# Syft для контейнера
syft ghcr.io/myorg/myapp:v1.0.0 -o spdx-json > sbom.spdx.json

# Для Python-проекта
syft . -o cyclonedx-json > sbom.cdx.json

# В CI/CD пайплайне
- name: Generate SBOM
  run: |
    syft $IMAGE -o spdx-json > sbom.json
    cosign attach sbom --sbom sbom.json $IMAGE

Сканеры зависимостей¶

SCA (Software Composition Analysis)¶

Ищут уязвимости в сторонних библиотеках:

Snyk — коммерческий, отличная база CVE
Dependabot (GitHub) — бесплатный, PR-ы с обновлениями
Renovate — open source, гибкие правила
Trivy — open source, сканирует не только зависимости, но и misconfigurations
Grype (Anchore) — open source, быстрый

Container scanning¶

Сканируют Docker-образы на CVE:

Trivy — лидер, бесплатный
Snyk Container — коммерческий, хорошая интеграция
Clair (Quay) — старая гвардия
Grype — для Syft SBOM

Admission controllers в Kubernetes¶

Блокируют запуск непроверенных или уязвимых подов:

Kyverno — policy engine для K8s, может требовать подписи образов, SBOM, конкретные метки
OPA/Gatekeeper — Rego-политики
Connaisseur — специально для проверки подписей

# Kyverno policy: требовать подписанные образы
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      ...

Защита CI/CD pipeline¶

Основные угрозы¶

Утечка секретов через логи или форки
Tampering build-скриптов через PR от злоумышленника
Зависимости в pipeline — actions, образы, скрипты
Self-hosted runners скомпрометированы

Best practices¶

1. Изолированные build-среды. Каждая сборка в чистом контейнере или ephemeral VM. Никакого persistent state.

2. Защита секретов. Секреты только через secret manager (HashiCorp Vault, AWS Secrets Manager), никогда в env-переменных в скриптах.

3. Pinning зависимостей. GitHub Actions — коммитить по SHA, не по тегу. То же для Docker-образов в pipeline.

# Плохо: может быть подменён tag
- uses: actions/checkout@v4

# Хорошо: pin по SHA
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

4. Минимальные права у токенов CI. Read-only когда возможно, короткий TTL, явный scope.

5. Аудит pipeline-конфигов. Все изменения в .github/workflows/ или .gitlab-ci.yml проходят через code review с security-чеклистом.

6. Separate builds. Сборка артефакта отдельно от его деплоя. Артефакт подписан и хранится в immutable registry.

Runtime security¶

После запуска контейнера в проде:

Tetragon/Falco (см. главу «eBPF») — runtime-детект аномалий
Container sandboxing — gVisor, Kata Containers для изоляции от хоста
Read-only root filesystem — нельзя записать бинарник в работающий контейнер
Distroless образы — только runtime, без shell, без package manager

SLSA в Kubernetes через k8s-native инструменты¶

Sigstore Policy Controller — admission controller на базе Sigstore
Kyverno с поддержкой SLSA provenance
Connaisseur — verification с подписями
Tekton Chains — генерация SLSA provenance в Tekton pipeline

SBOM в Kubernetes¶

Хранение SBOM рядом с образом:

# Прикрепить SBOM к образу как attestation
cosign attach sbom --sbom sbom.json ghcr.io/myorg/myapp:v1.0.0

# В Kyverno требовать наличие SBOM
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-sbom
spec:
  rules:
    - name: check-sbom
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences: ["ghcr.io/myorg/*"]
          attestors:
            - entries:
                - type: sbom

Compliance и регуляторика¶

Executive Order 14028 (США, 2021) — обязательный SBOM для федерального ПО
NIS2 (ЕС, 2024) — supply chain security как часть директивы
ФСТЭК России — требования к защите цепочки поставки для КИИ
ISO/IEC 27001:2022 — A.5.21 Managing information security in the ICT supply chain

Когда НЕ нужно всё сразу¶

Пет-проект или MVP — достаточно SCA сканера и Dependabot
Стартап без compliance-требований — SLSA Level 1 + подпись + SBOM хватит
Корпоративное ПО с регуляторикой — SLSA Level 3-4 + admission controller + runtime security

Резюме¶

Supply chain security — это защита всего пути от кода до запущенного контейнера: - SLSA как фреймворк зрелости - Sigstore/cosign для подписи артефактов - SBOM для прозрачности зависимостей - SCA-сканеры (Trivy, Snyk) для поиска уязвимостей - Admission controllers (Kyverno, Connaisseur) для блокировки непроверенного - Runtime security (Falco, Tetragon) для защиты работающего

Начните с малого: 1. SCA-сканер в CI — Trivy или Snyk на каждый PR 2. SBOM для каждого релиза — Syft + публикация 3. Подпись контейнеров — cosign keyless 4. Admission controller — Kyverno для блокировки непроверенных

Дальше по мере зрелости: SLSA Level 2-3, runtime security, supply chain risk management.

См. также: «DevSecOps и SRE», «Инфраструктура как код», «Chaos Engineering», «Kubernetes-native reliability», «eBPF».