Welche Mechanismen zur Implementierung von SLSA (Supply chain Levels for Software Artifacts) sichern CI/CD-Pipelines technisch gegen Supply-Chain-Angriffe ab?

Die technische Absicherung von CI/CD-Pipelines nach dem SLSA-Framework basiert auf der Etablierung einer unveränderlichen Kette von Vertrauensbeweisen (Provenance). Wir setzen hierbei auf Mechanismen, die verhindern, dass manipulierte Artefakte in die Produktionsumgebung gelangen, selbst wenn Teile der Infrastruktur kompromittiert wurden.

Zentral ist die Erzeugung von Attestierungen. Ein Build-System generiert beim Erstellen eines Artefakts eine signierte Metadaten-Datei. Diese enthält Informationen über den verwendeten Quellcode-Commit, die Build-Parameter und die Identität des Build-Runners. Durch den Einsatz von Tools wie Sigstore (Cosign) stellen wir sicher, dass diese Provenance-Daten nicht nachträglich verändert werden können.

Ein weiterer technischer Hebel ist die Isolation der Build-Umgebung. Wir nutzen kurzlebige (ephemeral) Runner, die nach jedem Build vollständig gelöscht werden. Dies verhindert "Poisoning"-Angriffe, bei denen ein Angreifer persistente Änderungen am Build-Server vornimmt, um nachfolgende Builds zu manipulieren. Für höhere SLSA-Levels implementieren wir hermetische Builds, bei denen der Netzwerkzugriff während der Kompilierung unterbunden wird, um das Einschleusen externer, nicht verifizierter Abhängigkeiten zu blockieren.

Die folgende Tabelle zeigt die Zuordnung von SLSA-Anforderungen zu technischen Implementierungen:

Im Rahmen unserer IT-Consulting & Digitale Strategie integrieren wir diese Kontrollen direkt in die Orchestrierungsschicht. Die Verifizierung erfolgt automatisiert beim Deployment: Ein Admission Controller prüft, ob das Artefakt eine gültige Signatur besitzt und ob die Provenance-Daten mit den definierten Sicherheitsrichtlinien übereinstimmen. Nur wenn die Kette lückenlos belegt ist, wird der Container gestartet.

Wir empfehlen, den Fokus primär auf die automatisierte Verifizierung der Provenance am Deployment-Endpunkt zu legen, da eine Absicherung der Pipeline ohne eine strikte Zutrittskontrolle der Artefakte in die Runtime-Umgebung wirkungslos bleibt.