Захист ланцюга постачання: 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% та заощадивши клієнтам до $200 000 на простоях.

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

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

SLSA (Supply-chain Levels for Software Artifacts) визначає чотири рівні зрілості процесу збірки. В реальних проектах ціль — SLSA Level 3, де середовище збірки ізольоване, а provenance підписаний та пов'язаний з вихідним кодом. SLSA Level 3 в 2 рази надійніший за Level 2 завдяки ізоляції.

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 тижні)