Supply Chain Security: Sigstore-Signatur und echte SBOMs in CI/CD

Als die XZ-Utils-Hintertur (CVE-2024-3094) im Marz 2024 beinahe in stabile Linux-Distributionen gerutscht ware, wurde unmissverstandlich klar: einen GitHub-Tag zu signieren reicht nicht mehr aus. Die Software-Lieferkette ist zum prioritaren Ziel geworden, weil ein einziger kompromittierter Maintainer Schadcode innerhalb von Stunden auf Millionen Hosts schiebt. Bei Basilisk OffSec sitzen wir auf beiden Seiten: wir simulieren Angriffe auf Kunden-Pipelines und helfen Teams, die Turen zu schliessen, durch die wir gerade gegangen sind. Dieser Beitrag fasst zusammen, was wir in echten CI/CD-Umgebungen mit Sigstore cosign, SLSA Level 3 und CycloneDX-SBOMs ausrollen, mit klarem Bias zu Pragmatismus statt Compliance-Theater.

Schritt eins ist, sich von langlebigen privaten Signaturschlusseln im Secret Manager zu verabschieden. Cosign keyless nutzt OIDC von GitHub Actions, GitLab CI oder Buildkite, um uber Fulcio ein ephemeres Zertifikat fur 10 Minuten auszustellen, und protokolliert die Signatur im Rekor, einem append-only Transparenz-Log. Damit verschwindet eine ganze Klasse von Schlusselleaks, die Pivot-Stelle des CodeCov-Vorfalls 2021. Ein typischer Workflow hat drei Jobs: reproduzierbarer Build, signieren mit cosign sign --yes, und attestieren mit dem Pradikat SLSA Provenance v1.0. In Kundenprojekten haben wir 90 Prozent kurzere Rotationszeiten fur Credentials gemessen, nachdem wir von PGP-Schlusseln auf keyless migriert sind, was direkt an das anknupft, was wir in AppSec Shift-Left: SAST, SCA und Secrets Scanning ohne das Team auszubremsen diskutieren.

Ein SBOM ist kein XML, das niemand liest. Wir generieren CycloneDX 1.6 mit Syft zur Buildzeit, mit SHA-256-Hashes jeder Komponente, SPDX-Lizenz und Lieferant. Die Datei reist als referenziertes Artefakt neben dem OCI-Image, nicht versteckt in einem S3-Bucket. Zur Validierung lassen wir Grype auf dem Pull Request laufen und parallel im Hintergrund gegen das Registry, weil frische CVEs nach dem Merge auftauchen. Kombiniert mit Policy-as-Code uber Kyverno oder Conftest blocken wir Deploys, wenn das SBOM eine Abhangigkeit oberhalb von CVSS 7.0 ohne dokumentierte Ausnahme tragt. Dasselbe Policy-Muster taucht wieder auf, wenn wir Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen auf Produktionsservern besprechen.

SLSA (Supply-chain Levels for Software Artifacts) wurde zum Referenzframework, nachdem Google und OpenSSF die v1.0 im Jahr 2023 standardisierten. Level 1 verlangt nur ein versioniertes Build-Script. Level 2 fordert einen gehosteten Builder mit signierter Provenance. Level 3, wo wir bei sensiblen Projekten ankommen wollen, verlangt Build-Isolation, nicht falschbare Provenance und hermetische Builds. In der Praxis nutzen wir GitHub Actions mit dem reusable Workflow slsa-framework/slsa-github-generator, der eine in-toto-Attestation produziert, die der Runner selbst via OIDC signiert. Ein Angreifer, der einen Maintainer ubernimmt, muss zusatzlich den GitHub-Builder brechen, was die Angriffskosten um Grossenordnungen anhebt. Fur Teams, die sich auch mit Dependency Confusion und Typosquatting: Praktische Abwehr fuer Dev-Teams herumschlagen, schliesst SLSA die Publisher-Seite.

Verifikation auf Konsumentenseite ist genauso wichtig wie Signierung auf Produzentenseite. In Kubernetes-Clustern deployen wir den Sigstore policy-controller als Admission Webhook mit einer ClusterImagePolicy, die fur jedes Image im Produktionsnamespace eine gultige cosign-Signatur, eine OIDC-Identitat aus basilisk.example und eine SLSA-Attestation vom erwarteten Builder fordert. In Staging konfigurieren wir Soft-Fail, um Notfall-Deploys nicht zu blockieren, in Prod Hard-Fail. Auf Analyst-Workstations laufen wir zusatzlich cosign verify-blob gegen heruntergeladene CLI-Binaries, eingebettet in den Workflow aus OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell, weil Offensive-Teams viel Tooling aus zweifelhaften Quellen ziehen, und das zum offensichtlichen Vektor wird.

Wo es in der Praxis kracht: nicht reproduzierbare Builds, in Go-Binaries eingebrannte Timestamps, transitive Abhangigkeiten, die zwischen git pull und CI driften, und Maintainer, die 2FA verweigern. Das Pre-2.0-XZ-Projekt zeigte bereits Signale eines sozialen Takeovers, die keine Signatur einfangt. Deshalb empfehlen wir, cosign+SLSA+SBOM mit periodischem Review kritischer Maintainer zu kombinieren, OpenSSF Scorecard wochentlich uber die Top-50-Abhangigkeiten laufen zu lassen, und Red-Team-Ubungen einzuziehen, die Maintainer-Kompromittierung simulieren, ahnlich den Engagements aus Adversary Emulation mit Caldera und MITRE ATT&CK im Unternehmenslab und Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus. Technologie ohne Wartungsprozess wird zu teurem Theater.

Praktischer Takeaway: fang klein und messbar an. Diese Woche, fuge cosign sign keyless einem einzelnen Pipeline hinzu, generiere ein CycloneDX-SBOM mit Syft und veroffentliche es als OCI-Artefakt neben dem Image. Im nachsten Sprint aktivierst du verpflichtendes cosign verify in einem Staging-Namespace. Innerhalb von 30 Tagen hast du die Hebelkraft, SLSA L2 von Lieferanten zu verlangen, und Evidenz, um zu reagieren, wenn das nachste XZ landet, denn das kommt. Implementierungskosten auf einer existierenden Pipeline liegen bei 2 bis 4 Engineer-Stunden; die Kosten des Auslassens sind ein Sonntagsanruf, bei dem du erklarst, ob du den Container signiert hast, der gerade in Produktion Monero mint.