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.

Warum die Lieferkette das Ziel wurde#

Ein Angreifer hat zwei Wege zu deiner Produktion: die Vordertur (deine exponierten Dienste angreifen) oder die Hintertur (etwas kompromittieren, dem du bereits vertraust). Die Hintertur skaliert besser. Der SolarWinds-Vorfall zeigte, dass ein manipulierter Build-Prozess 18.000 Organisationen auf einen Schlag trifft. XZ zeigte, dass ein geduldiger Angreifer sich uber zwei Jahre soziales Vertrauen erarbeitet, Maintainer-Rechte erhalt und eine Backdoor einbaut, die nur unter sehr spezifischen Bedingungen zundet.

Der gemeinsame Nenner: das schwachste Glied ist nie die Kryptografie, sondern die menschliche und prozessuale Kette rund um den Build. Deshalb ist die Antwort keine einzelne Technologie, sondern eine Kette aus Signatur (wer hat gebaut), Provenance (wie und wo wurde gebaut) und Inventar (was steckt drin). Fehlt ein Glied, laufst du blind. Der CodeCov-Vorfall 2021, bei dem eine geleakte Credential ein Bash-Uploader-Skript manipulierte, war der Weckruf fur die Signatur-Ebene.

Cosign keyless: Fulcio und Rekor#

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. Ein typischer Workflow hat drei Jobs: reproduzierbarer Build, signieren mit cosign sign --yes, und attestieren mit dem Pradikat SLSA Provenance v1.0.

Der Clou am Transparenz-Log: selbst wenn ein Angreifer kurzzeitig eine gultige OIDC-Identitat erlangt, ist jede Signatur offentlich und unwiderruflich protokolliert. Du kannst nachtraglich fragen, welche Artefakte mit welcher Identitat zu welchem Zeitpunkt signiert wurden, und Anomalien finden. 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.

SBOM mit Syft und CycloneDX#

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. Ein realer Aufruf: syft packages dir:. -o cyclonedx-json=sbom.json. Die Datei reist als referenziertes Artefakt neben dem OCI-Image, per cosign attest --predicate sbom.json --type cyclonedx an das Image gebunden, nicht versteckt in einem S3-Bucket, den in sechs Monaten niemand mehr findet.

Der Wert eines SBOM zeigt sich am Tag der nachsten Zero-Day. Wenn eine kritische CVE in einer transitiven Abhangigkeit auftaucht, ist die Frage nicht abstrakt, sondern operativ: Welche unserer 200 laufenden Images enthalten die verwundbare Version? Ohne SBOM ist das eine mehrtagige Archaologie. Mit einem abfragbaren SBOM-Inventar ist es eine Query von Minuten. Genau deshalb bindet man das SBOM an das Artefakt und nicht an eine Wiki-Seite.

Scannen mit Grype und Policy-as-Code#

Zur Validierung lassen wir grype auf dem Pull Request laufen und parallel im Hintergrund gegen das Registry, weil frische CVEs nach dem Merge auftauchen. Ein Image, das gestern sauber war, kann heute eine kritische Schwachstelle tragen, ohne dass sich eine einzige Zeile Code geandert hat. 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.

Wichtig ist der Ausnahme-Mechanismus. Eine harte Policy ohne dokumentierten Ausnahmepfad wird umgangen, sobald sie einen dringenden Deploy blockiert, und dann ist sie tot. Wir nutzen eine VEX-Datei (Vulnerability Exploitability eXchange), um zu deklarieren, dass eine bestimmte CVE im konkreten Kontext nicht ausnutzbar ist, mit Begrundung und Ablaufdatum. Dasselbe Policy-Muster taucht wieder auf, wenn wir Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen auf Produktionsservern besprechen.

Die SLSA-Level verstehen#

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, bei denen der Build keinen unkontrollierten Netzwerkzugriff hat.

Der entscheidende Sprung liegt zwischen Level 2 und 3: eine Provenance, die der Builder selbst erzeugt und signiert, kann ein kompromittierter Entwickler nicht falschen, weil er den Builder-Prozess nicht kontrolliert. Fur Teams, die sich auch mit Dependency Confusion und Typosquatting: Praktische Abwehr fuer Dev-Teams herumschlagen, schliesst SLSA die Publisher-Seite, wahrend Namespace-Reservierung und Registry-Pinning die Consumer-Seite abdecken.

Provenance mit slsa-github-generator#

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. Diese Attestation dokumentiert kryptografisch verifizierbar den Quell-Commit, die Build-Parameter und die Toolchain-Version. Ein Angreifer, der einen Maintainer ubernimmt, muss zusatzlich den GitHub-Builder brechen, was die Angriffskosten um Grossenordnungen anhebt.

Die haufigste Bruchstelle hier sind nicht reproduzierbare Builds. In Go-Binaries eingebrannte Timestamps, absolute Pfade und eingebettete Build-IDs sorgen dafur, dass zwei Builds desselben Commits unterschiedliche Hashes ergeben. Setze -trimpath, fixiere SOURCE_DATE_EPOCH und pinne die Toolchain in einer Lockfile, sonst ist deine Provenance zwar signiert, aber nicht verifizierbar reproduzierbar.

Verifikation auf Konsumentenseite#

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. Der Grundsatz: signiere am Ursprung, verifiziere am Konsumpunkt, und vertraue nie einem Artefakt, nur weil es in deiner Registry liegt.

Grenzen: soziale Ubernahme und Scorecard#

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: ein neuer Mitwirkender, der auffallig schnell Vertrauen aufbaut, Druck auf den Originalmaintainer, und Commits mit obfuskierten Testdaten.

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.

Registry-Pinning und unveranderliche Digests#

Signatur und Provenance nutzen wenig, wenn deine Deploys ein bewegliches Tag wie :latest referenzieren. Ein :latest, das gestern verifiziert wurde, kann heute auf ein anderes Image zeigen. Pinne in Produktion immer auf den unveranderlichen Digest (image@sha256:...), nicht auf ein Tag. Der Digest ist der kryptografische Fingerabdruck des exakten Image-Inhalts; ein gepinnter Digest plus verifizierte Signatur ergibt eine luckenlose Kette vom Quell-Commit bis zum laufenden Container.

Erganze das um eine gespiegelte, interne Registry (Harbor, Artifactory) mit aktiviertem Pull-Through-Cache und Immutability-Regeln, damit ein geloschtes oder uberschriebenes Upstream-Tag deine Builds nicht bricht und ein Angreifer ein bereits verifiziertes Tag nicht neu belegen kann. Kombiniert mit einer Allowlist erlaubter Registries im Admission-Controller schliesst du die Lucke, durch die Dependency-Confusion-Angriffe schlupfen.

30-Tage-Rollout#

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. Nachste Woche: schalte grype im PR ein mit einer Warn-only-Policy, um das Grundrauschen an CVEs zu kalibrieren. Woche drei: aktiviere verpflichtendes cosign verify in einem Staging-Namespace mit Soft-Fail. Woche vier: schalte auf Hard-Fail in Prod fur einen einzelnen, gut verstandenen Service um und erweitere von dort.

FAQ#

Braucht keyless einen Internetzugang beim Build? Ja, Fulcio und Rekor sind Online-Dienste. Fur Air-Gap-Umgebungen betreibt man eine private Sigstore-Instanz (Fulcio, Rekor, Trillian) intern oder fallt auf schlusselbasiertes cosign mit einem in einem KMS/HSM gehaltenen Key zuruck. Keyless ist die Default-Empfehlung, aber kein Dogma.

Ersetzt ein SBOM das Schwachstellen-Scanning? Nein. Das SBOM ist das Inventar, der Scanner ist die Analyse dagegen. Ein SBOM ohne kontinuierliches Rescanning gegen aktuelle CVE-Feeds altert in Tagen. Beide zusammen ergeben ein abfragbares, aktuelles Bild deiner Angriffsflache; einzeln sind sie halbe Massnahmen.

Wie uberzeugt man das Management von den Kosten? Nicht mit Compliance-Argumenten, sondern mit der Reaktionszeit-Rechnung. Beim letzten grossen OpenSSL-CVE brauchten Teams ohne SBOM-Inventar im Schnitt mehrere Tage, nur um herauszufinden, welche Systeme betroffen sind. Teams mit gebundenem SBOM beantworteten dieselbe Frage in Minuten und begannen sofort mit dem Patchen. Diese Differenz ist direkt in Ausfallrisiko und Uberstunden ubersetzbar, und genau das versteht ein Budget-Verantwortlicher.

Praktischer Takeaway: fang klein und messbar an. 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.