Warum Code-Signing nicht mehr vor Supply-Chain-Angriffen schützt

Warum klassisches Code-Signing fehlschlägt und wie kurzlebige Schlüssel sowie kryptografische Nachweise via Sigstore CI/CD-Pipelines absichern.

Der Fokus internationaler Cyber-Angriffe hat sich in den vergangenen Jahren grundlegend verlagert. Während historisch primär produktive Systeme oder direkte Schwachstellen in Webanwendungen im Visier von Angreifern standen, bildet heute die softwareseitige Lieferkette, die sogenannte Software Supply Chain, das primäre Angriffsziel staatlicher und krimineller Akteure. Der kritischste Punkt in dieser Kette ist der Moment des Kompilierens, also die Transformation von menschenlesbarem Quellcode in ausführbare Binärdateien innerhalb der automatisierten Build-Infrastruktur.

Moderne Entwicklungsorganisationen nutzen kontinuierliche Integrations- und Bereitstellungspipelines, allgemein als CI/CD-Pipelines bezeichnet. Angreifer haben erkannt, dass herkömmliche Schutzmaßnahmen wie Code-Reviews, statische Code-Analysen und restriktive Branch-Protections im Git-Repository greifen, solange der Quellcode statisch vorliegt.

Hochentwickelte Angriffe setzen daher erst nach diesen Kontrollpunkten an. Sie manipulieren den Code nicht im Repository selbst, sondern injizieren den Schadcode während des laufenden Build-Prozesses direkt im Arbeitsspeicher des Build-Runners oder manipulieren die vom Compiler genutzten temporären Abhängigkeiten. Ein prominentes historisches Beispiel für diese Methodik ist der weitreichende Angriff auf die Build-Infrastruktur von SolarWinds, bei dem die Schadsoftware Sunburst direkt während des Kompilierungsvorgangs in das produktive Software-Update eingeschleust wurde, ohne Spuren im Quellcode-Archiv zu hinterlassen.

Das architektonische Versagen klassischer Code-Signing-Infrastrukturen

Um die Integrität und Authentizität von Software-Updates zu garantieren, setzen Unternehmen traditionell auf Verfahren der Public Key Infrastructure, kurz PKI. Hierbei wird die fertige Binärdatei oder das Container-Image mit einem privaten kryptografischen Schlüssel digital signiert. Empfängersysteme können vor der Installation anhand des zugehörigen öffentlichen Zertifikats überprüfen, ob die Datei tatsächlich vom legitimen Hersteller stammt und seit der Signierung nicht verändert wurde.

Dieses klassische Code-Signing-Modell weist in modernen, hochautomatisierten Cloud-Native-Umgebungen jedoch eklatante strukturelle Mängel auf. Erstens erfordert es das dauerhafte Speichern von langlebigen privaten Schlüsseln innerhalb der Pipeline-Geheimnisse oder auf angeschlossenen Hardware-Sicherheitsmodulen. Wenn es einem Angreifer gelingt, die administrative Kontrolle über den Build-Server zu erlangen, kann er die bestehenden Berechtigungen missbrauchen, um auch seine manipulierte Software vollkommen legitim mit dem echten Herstellerschlüssel zu signieren. Zweitens stellt das Schlüsselmanagement ein immenses operatives Risiko dar. Das regelmäßige Rotieren statischer Zertifikate ist fehleranfällig, und im Falle eines verifizierten Schlüsselabflusses ist der Widerruf über Certificate Revocation Lists oder das Online Certificate Status Protocol mit erheblichen zeitlichen Verzögerungen behaftet, in denen kompromittierte Software weiterhin als vertrauenswürdig eingestuft wird.

Das Prinzip ephemerer Build-Umgebungen zur Reduktion der Angriffsfläche

Als direkte Reaktion auf die Verwundbarkeit statischer Build-Infrastrukturen etabliert sich das Paradigma ephemerer Build-Umgebungen. Das Wort ephemer definiert sich über die Eigenschaft der Kurzlebigkeit. In einer modernen Sicherheitsarchitektur existiert ein Build-Runner nicht mehr als permanent laufender Server, der nacheinander hunderte von Software-Builds verarbeitet, sondern wird für jeden einzelnen Build-Schritt isoliert und vollständig neu initialisiert.

Typischerweise werden hierfür flüchtige Container-Instanzen innerhalb von Kubernetes-Clustern oder dedizierte Micro-Virtuelle-Maschinen genutzt. Sobald ein Entwickler einen Push-Befehl ausführt, fährt die Infrastruktur eine saubere, exakt definierte Umgebung hoch, die ausschließlich die für diesen spezifischen Prozess benötigten Werkzeuge enthält. Nach dem Abschluss des Kompilierungsvorgangs und dem Export des Artefakts wird die gesamte Instanz inklusive des flüchtigen Arbeitsspeichers und aller temporären Festplattenpartitionen vollständig gelöscht. Dies entzieht Angreifern die Möglichkeit, sich dauerhaft innerhalb der Build-Infrastruktur einzunisten, um nachfolgende Kompilierungsprozesse unbemerkt zu intensiv manipulieren.

Schlüssellose Signierung mit dem Sigstore-Ökosystem

Die Nutzung ephemerer Umgebungen löst das Problem der Persistenz, verstärkt jedoch die Notwendigkeit, den Signierungsprozess grundlegend zu revolutionieren. Da der Build-Runner kurzlebig ist, darf er keinen Zugriff auf langfristige statische Geheimnisse besitzen. Hier setzt das Open-Source-Projekt Sigstore an, das unter dem Dach der Linux Foundation entwickelt wurde. Sigstore ermöglicht eine schlüssellose Signierung, bei der die Notwendigkeit einer klassischen Schlüsselverwaltung komplett entfällt. Die Architektur von Sigstore basiert auf dem koordinierten Zusammenspiel dreier technologischer Kernkomponenten:

Fulcio fungiert als eine spezialisierte, leichtgewichtige Zertifizierungsstelle. Wenn ein ephemerer Build-Runner ein Artefakt signieren möchte, generiert er lokal ein flüchtiges, asymmetrisches Schlüsselpaar. Anschließend authentifiziert sich der Runner über das OpenID Connect Protokoll bei Fulcio. Als Identität dient hierbei keine menschliche E-Mail-Adresse, sondern die kryptografisch verifizierte Workload-Identität des CI/CD-Anbieters, beispielsweise ein von GitHub Actions ausgestelltes OIDC-Token. Fulcio überprüft dieses Token und stellt ein digitales X.509-Zertifikat aus, das exakt an die Identität der Pipeline gebunden ist. Dieses Zertifikat besitzt eine extrem kurze Gültigkeitsdauer von meist nur zehn Minuten.

Rekor ist das zweite fundamentale Element und operiert als ein transparentes, manipulationssicheres kryptografisches Hauptbuch, ein sogenannter Transparency Log. Jedes von Fulcio ausgestellte Kurzzeit-Zertifikat und die damit erzeugte Signatur des Software-Artefakts müssen zwingend in diesem Protokoll registriert werden. Rekor nutzt eine Merkle-Baum-Struktur, um die Integrität der Einträge mathematisch zu sichern. Ein nachträgliches Verändern oder Löschen von Signaturdaten ist unmöglich.

Cosign ist das primäre Kommandozeilenwerkzeug, mit dem Entwickler und automatisierte Systeme die Interaktion mit Fulcio und Rekor steuern. Cosign wird in die Pipeline integrated, um Container-Images zu signieren, und von den Empfängersystemen, beispielsweise einem Kubernetes Admission Controller im produktiven Rechenzentrum, genutzt, um die Gültigkeit der Signatur und den Eintrag im Rekor-Log vor der Bereitstellung lückenlos zu verifizieren.

Kryptografische Herkunftsnachweise und Attestations

Der Schutz der Lieferkette über Sigstore beschränkt sich nicht auf die reine Feststellung, wer die Software signiert hat. Für eine umfassende Absicherung gemäß internationalen Standards wie dem Framework „Supply-chain Levels for Software Artifacts“, kurz SLSA, sind detaillierte Herkunftsnachweise erforderlich. Diese Nachweise werden als Attestations bezeichnet.

Eine Attestation ist ein digital signiertes Dokument, das im JSON-Format standardisierte Metadaten über den gesamten Entstehungsprozess der Software enthält. Das System nutzt hierfür Spezifikationen wie das in-toto-Framework. Eine vollständige Build-Attestation dokumentiert präzise, welches Quellcode-Repository genutzt wurde, welcher exakte Git-Commit-Hash die Basis bildete, welche Umgebungsvariablen aktiv waren und welche spezifischen Drittanbieter-Abhängigkeiten während des Prozesses heruntergeladen wurden. Da diese Attestation direkt im Anschluss an den Kompilierungsvorgang innerhalb der ephemeren Umgebung generiert und über Cosign schlüssellos signiert wird, entsteht ein lückenloser, mathematisch überprüfbarer Beweis über die Integrität der Lieferkette. Empfängersysteme können somit regelbasiert erzwingen, dass nur Software installiert wird, die nachweislich auf einer definierten, sicheren Pipeline ohne manuelle Eingriffe erzeugt wurde.

Systematischer Vergleich der Code-Signing-Verfahren

Für die strategische Neuausrichtung der DevSecOps-Kultur müssen Unternehmen die Merkmale der traditionellen PKI-Infrastruktur den Eigenschaften modernen ephemerer Verfahren direkt gegenüberstellen:

Sicherheits-Parameter	Klassische PKI-Infrastruktur	Ephemere schlüssellose Signierung (Sigstore)
Lebensdauer der privaten Schlüssel	Langfristig; oft über mehrere Jahre gültig bis zum offiziellen Ablaufdatum.	Extrem kurzfristig; Schlüssel existieren nur für wenige Minuten im RAM.
Risiko des Schlüsselabflusses	Hoch; erfordert komplexe Überwachung von Secrets und HSM-Hardware.	Eliminiert; Schlüssel werden nach der Nutzung sofort vernichtet.
Widerrufs-Mechanismus	Komplex und fehleranfällig über CRL-Listen oder OCSP-Abfragen mit Latenz.	Entfällt; die Validierung basiert auf dem permanenten Eintrag im Rekor-Log.
Identitäts-Basis	Bindung an eine organisatorische Entität oder spezifische Personenzertifikate.	Bindung an verifizierbare OIDC-Workload-Identitäten der Pipeline.
Transparenz des Prozesses	Gering; Signierungsvorgänge finden meist isoliert ohne öffentliche Kontrolle statt.	Maximal; jeder Signierungsvorgang wird unveränderlich im Transparency Log registriert.
Nachweis der Build-Historie	Minimal; die Signatur bestätigt lediglich die Authentizität des Endprodukts.	Vollständig; optionale Verknüpfung mit detaillierten in-toto-Attestations.

Strategischer Leitfaden zur Implementierung einer sicheren Build-Pipeline

Die Transformation einer bestehenden, statischen Entwicklungsinfrastruktur in eine moderne, resiliente Lieferkette erfordert die konsequente Umsetzung eines strukturierten Maßnahmenkatalogs. IT-Leiter und Sicherheitsarchitekten sollten folgende operative Schritte etablieren:

• Durchführung einer umfassenden Isolation aller Build-Prozesse. Permanente Server-Instanzen müssen systematisch durch ephemere Runner-Architekturen ersetzt werden, die sich nach der Verarbeitung eines einzelnen Jobs automatisch zerstören.
• Aktivierung von OpenID Connect Verbundidentitäten zwischen dem CI/CD-System und der Zertifizierungsstelle. Statische Passwörter oder langlebige API-Tokens innerhalb der Pipeline-Konfiguration müssen vollständig eliminiert werden.
• Integration des Toolings von Cosign fest in die Build-Skripte. Jedes generierte Artefakt muss unmittelbar nach dem Kompilierungsschritt schlüssellos signiert und der entsprechende Eintrag im Rekor-Hauptbuch verankert werden.
• Automatisierte Generierung von SLSA-konformen Herkunftsnachweisen. Diese Attestations müssen als fester Bestandteil des Software-Assecuranz-Prozesses mitgeführt und in der Artefakt-Registry gespeichert werden.
• Installation eines strengen Richtlinien-Controllers wie Kyverno oder Open Policy Agent auf der Seite der Zielumgebungen, beispielsweise in den produktiven Kubernetes-Clustern. Dieser Controller wird so konfiguriert, dass er die Bereitstellung von Container-Images blockiert, wenn keine gültige Sigstore-Signatur vorliegt oder die beigefügte Attestation Abweichungen vom definierten Sicherheitsstandard aufweist.

Die konsekutive Umsetzung dieser Maßnahmen stellt eine elementare Säule der Cyber-Resilienz dar. Da professionelle Angreifer die Kontrollpunkte der Quellcode-Ebene gezielt umgehen, muss die Integrität der Software direkt im flüchtigen Moment ihrer Entstehung kryptografisch verankert werden. Nur durch die mathematisch präzise Symbiose aus kurzlebigen Build-Umgebungen, schlüsselloser Signierung und lückenlosen Herkunftsnachweisen lässt sich die softwareseitige Lieferkette wirksam vor Sabotage schützen und das Vertrauen in digitale Produkte nachhaltig und rechtssicher gewährleisten.