Реализация Supply Chain Security (SLSA/Sigstore/in-toto)

Защита цепочки поставок: SLSA, Sigstore, in-toto

Представьте: ваш CI собрал образ, но кто-то заменил base image на вредоносный — как вы это узнаете? Без защиты supply chain вы слепы. Атаки на SolarWinds Orion, XZ Utils и event-stream в npm показали: компрометация происходит не через ваш код, а через инструменты сборки или зависимости. Мы реализовали системы supply chain security для 15+ проектов, снизив среднее время детекции инцидентов (MTTR) на 40% и сэкономив клиентам миллионы на простоях.

Один из кейсов: крупный fintech-клиент обнаружил, что их CI-агент был скомпрометирован через уязвимую зависимость в образе сборки. За 2 недели мы внедрили подпись всех образов через Cosign + Sigstore keyless, настроили SLSA provenance и Kyverno admission webhook. Теперь каждый образ проверяется при деплое, а несанкционированные изменения блокируются.

Почему SLSA — стандарт де-факто для защищённых поставок?

SLSA (Supply-chain Levels for Software Artifacts) определяет четыре уровня зрелости процесса сборки. В реальных проектах цель — SLSA Level 3, где среда сборки изолирована, а provenance подписан и связан с исходным кодом.

Provenance — JSON-документ, содержащий commit SHA, инициатора сборки, параметры билда и digest артефакта. Без него невозможно верифицировать происхождение.

Как Sigstore избавляет от управления ключами?

Sigstore решает главную проблему классической подписи — хранение и ротация private key. Вместо этого используется keyless signing через OIDC:

1. CI/CD-пайплайн запрашивает OIDC-токен у провайдера (GitHub Actions, GitLab, GCP).
2. Fulcio (CA от Sigstore) верифицирует токен и выдаёт краткоживущий сертификат (10 минут).
3. Cosign подписывает образ, сертификат записывается в Rekor — append-only лог.

Такой подход в 3 раза быстрее в настройке, чем PGP, и не требует ротации ключей.

# GitHub Actions: подпись контейнера через Cosign + Sigstore keyless
- name: Install Cosign
  uses: sigstore/cosign-installer@v3
- name: Sign container image
  run: |
    cosign sign --yes \
      ${{ env.REGISTRY }}/${{ env.IMAGE }}@${{ steps.build.outputs.digest }}
    env:
      COSIGN_EXPERIMENTAL: "true"

Верификация подписи при деплое:

cosign verify \
  --certificate-identity-regexp="https://github.com/myorg/myrepo/.github/workflows/.*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp:v1.2.3

Если подпись отсутствует или сертификат не совпадает — команда вернёт ошибку. OPA Gatekeeper или Kyverno могут использовать эту проверку как admission webhook в Kubernetes.

Генерация SLSA Provenance в GitHub Actions

jobs:
  build:
    outputs:
      image: ${{ steps.image.outputs.image }}
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE }}:${{ github.sha }}
          provenance:
  needs: build
  uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
  with:
    image: ${{ needs.build.outputs.image }}
    digest: ${{ needs.build.outputs.digest }}
    secrets:
      registry-username: ${{ secrets.REGISTRY_USER }}
      registry-password: ${{ secrets.REGISTRY_PASSWORD }}

generator_container_slsa3.yml от SLSA GitHub Generator запускается в изолированном reusable workflow, что обеспечивает SLSA Build Level 3 — pipelineRunner не может модифицировать provenance.

Как in-toto дополняет SLSA?

In-toto позволяет определить supply chain layout: конкретные шаги (clone, build, test, package, sign) и кто уполномочен их выполнять. Каждый шаг создаёт link metadata — подписанный файл с inputs/outputs шага.

# Шаг сборки с записью link
in-toto-run \
  --step-name build \
  --key developer.pem \
  --products dist/ \
  -- make build

# Финальная верификация всей цепочки
in-toto-verify \
  --layout root.layout \
  --layout-keys root.pub \
  --link-dir ./links/

In-toto активно используется в TUF для обеспечения безопасности пакетных репозиториев — именно так работает защита PyPI и Debian packages.

Процесс внедрения supply chain security

Фаза 1 — Подпись и верификация образов (1 неделя)

• Настройка Cosign в CI/CD пайплайнах
• Настройка Kyverno/OPA политики для проверки подписи при деплое
• Реестр подписанных образов, reject неподписанных в production namespace

Фаза 2 — SLSA Provenance (1 неделя)

• Интеграция slsa-github-generator в build-пайплайны
• Хранение provenance рядом с образом в registry (как OCI attestation)
• Настройка автоматической верификации provenance при деплое

Фаза 3 — Dependency и artifact verification (1-2 недели)

• Верификация сторонних зависимостей через Dependency Review Action
• Настройка npm audit signatures для проверки подписей npm-пакетов
• Интеграция с Sigstore Policy Controller

Фаза 4 — in-toto layout (опционально, 1-2 недели)

• Только если требуется полная верификация цепочки: нужен для compliance-фреймворков типа DISA STIG или когда артефакты распространяются через third-party

Что входит в работу

• Аудит текущего CI/CD стека и определение целевого SLSA уровня
• Настройка Cosign и keyless подписи для всех образов
• Интеграция генерации SLSA Provenance в пайплайны
• Внедрение политик верификации подписи через Kyverno/OPA
• Документирование runbook и обучение команды
• Поддержка на этапе опытно-промышленной эксплуатации (2 недели)