Digitale Signaturen an der Peripherie: Warum Image Signing der nächste Schritt nach dem CVE ist

Wer die Sicherheit seiner Container–Lieferkette maximieren möchte, setzt auf automatisiertes CVE-Scanning an der Cluster-Grenze. Das Zusammenspiel aus Registry-Scans und Admission Control stellt sicher, dass Code mit bekannten Schwachstellen gar nicht erst zur Ausführung kommt. Damit ist eine wichtige Hürde genommen. Doch ein grundlegendes Problem bleibt bestehen: Der reine Schwachstellenscan prüft nur den Inhalt eines Containers zu einem bestimmten Zeitpunkt - er prüft nicht dessen Herkunft und Integrität.

Im modernen, oft unübersichtlichen CI/CD-Alltag reicht es nicht zu wissen, ob ein Image fehlerfrei ist. Sie müssen mathematisch beweisen können, dass das Image, das gerade im Kubernetes–Cluster gestartet werden soll, auch exakt dem Image entspricht, das Ihre Entwickler oder Ihre automatisierte Pipeline vor einer Stunde freigegeben haben. Ohne kryptografische Absicherung mittels Image Signing bleibt die Pipeline anfällig für raffinierte Supply-Chain-Angriffe, bei denen Schadcode unbemerkt auf dem Weg zwischen Code-Repository und Live-Infrastruktur eingeschleust wird.

Die Sicherheitslücke trotz Scan: Das Vertrauensproblem

Ein herkömmlicher CVE-Scan ist blind für Manipulationen an der Transportkette. Ohne digitale Signaturen an den Container-Artefakten entstehen in Enterprise-Umgebungen drei konkrete Angriffsvektoren:

1. Der Man-in-the-Middle-Angriff auf die Registry

Ein Angreifer verschafft sich unbefugten Zugriff auf die Container Registry oder fängt den Netzwerkverkehr ab. Er ersetzt ein legitimes, zuvor sauber gescanntes Image (z. B. backend:latest) durch eine manipulierte Version, die einen Krypto-Miner oder eine Backdoor enthält. Da der Angreifer den Schadcode so konstruiert, dass er keine bekannten CVEs auslöst, winkt der Admission Controller das Image durch. Das Cluster führt bösartigen Code aus, der aus einer vermeintlich vertrauenswürdigen Quelle stammt.

2. Das “Tag-Hijacking”

Container-Tags (wie :latest, :v1.2 oder :prod) sind im OCI-Standard veränderlich (mutable). Ein Entwickler oder ein kompromittiertes Skript kann ein neues, ungetestetes Image unter einem bereits existierenden Produktionstag hochladen. Kubernetes merkt beim automatischen Skalieren oder beim Neustart eines Nodes nicht, dass sich der zugrunde liegende Code verändert hat, und zieht das falsche Image.

3. Die korrumpierte Pipeline (Shadow Deployments)

Wenn Angreifer Zugriff auf die CI/CD-Pipeline erlangen, können sie den Build-Prozess so manipulieren, dass parallel zu den offiziellen Artefakten unbemerkt eigene Container gebaut und direkt ins Cluster geschoben werden. Ein reiner Schwachstellenscan validiert diesen Code im Zweifel als “sauber”, obwohl er niemals von einem autorisierten Engineer freigegeben wurde.

Die Lösung: Das mathematische Siegel via Cosign und Harbor

Um dieses Vertrauensproblem radikal zu lösen, wird die Software-Lieferkette um eine kryptografische Signaturstufe erweitert. Der moderne Industriestandard hierfür ist Cosign (aus dem Open-Source-Projekt Sigstore), der nativ mit Enterprise-Registries wie Harbor harmoniert.

Das Prinzip funktioniert wie das digitale Siegel auf einer Urkunde:javascript [ CI/CD Pipeline / Build-Server ] | v (Image wird gebaut & verifiziert) [ Kryptografische Signierung via Cosign ] <— Privater Schlüssel / KMS | v (Push von Image + Signatur-Metadaten) [ Managed Harbor Registry ] | v (Deployment-Anfrage) [ Kubernetes API Server / Policy Engine ] <— Validierung mit öffentlichem Schlüssel | +———+———+ | | v v [ Signatur gültig? ] [ Signatur fehlt / manipuliert? ] | | v v [ Deployment erlaubt ] [ Deployment hart blockiert ]

1. Signierung direkt in der vertrauenswürdigen Build-Umgebung

Nachdem die CI/CD-Pipeline das Container–Image erfolgreich gebaut und den CVE-Scan bestanden hat, kommt Cosign zum Einsatz. Die Pipeline nutzt einen geschützten privaten Schlüssel (der sicher in einem Key-Management-System oder einer geschützten Pipeline-Variable liegt), um einen kryptografischen Hash des Containers digital zu signieren.

2. Synchroner Push im OCI-Standard

Cosign pusht die resultierende Signatur als separates, verknüpftes Artefakt direkt in dieselbe Harbor-Registry. Da Harbor voll OCI-kompatibel ist, verwaltet die Registry die Signatur-Metadaten untrennbar gekoppelt am dazugehörigen Container–Image. Im Dashboard wird das Image sofort visuell als “Signed” deklariert.

3. Unbestechliche Verifizierung beim Admission Control

Wird das Image im Kubernetes–Cluster angefordert, prüft eine Policy Engine (wie Kyverno oder OPA Gatekeeper) das Image vor dem Start. Der Controller besitzt ausschließlich den öffentlichen Schlüssel (Public Key) des Unternehmens. Er prüft mathematisch, ob die Signatur an der Registry mit diesem Schlüssel korrespondiert und ob der Image-Inhalt (SHA256-Digest) seit dem Signiervorgang auch nur um ein einziges Bit verändert wurde. Passt die Signatur nicht oder fehlt sie komplett, wird das Deployment rigoros abgewiesen.

Strategischer Mehrwert: Schutz vor Insider-Bedrohungen und CRA-Compliance

Die Einführung von Image Signing hebt das Sicherheitsniveau Ihrer IT-Infrastruktur auf ein neues Level und liefert die technischen Antworten auf komplexe regulatorische Anforderungen:

• Kompromisslose Einhaltung des Cyber Resilience Acts (CRA): Der CRA fordert den Nachweis über die Integrität und Authentizität von Softwarekomponenten über den gesamten Lebenszyklus. Kryptografische Signaturen sind der unumstößliche mathematische Beweis dafür, dass die gelieferte Software exakt der geprüften Version entspricht.
• Schutz vor Insider-Threats: Selbst Administratoren mit weitreichenden Rechten im Kubernetes–Cluster können die Signatur-Pflicht nicht einfach umgehen. Versucht ein Innentäter, ein manipuliertes Image direkt von seinem lokalen Rechner ins Cluster zu schieben, scheitert der Start kläglich, da sein privater Rechner nicht über den autorisierten Signaturschlüssel der offiziellen CI/CD-Pipeline verfügt.
• Resilienz gegen kompromittierte Registries: Sollte die Container Registry selbst Ziel eines erfolgreichen Hackerangriffs werden und Schadcode injiziert bekommen, fliegt die Manipulation spätestens an der Clustergrenze auf. Die Angreifer können die Images zwar austauschen, aber ohne den privaten Pipeline-Schlüssel keine gültige mathematische Signatur fälschen.

Fazit: Vertrauen ist gut, Mathematik ist sicherer

CVE-Scanning und Image-Signierung sind keine konkurrierenden Konzepte, sondern die zwei Herzkammern einer sicheren Software-Lieferkette. Während der Scan die Qualität des Codes sichert, garantiert die Signatur dessen Echtheit. Wer im hochregulierten Umfeld - sei es unter DORA, NIS-2 oder dem CRA - containerisierte Workloads betreibt, darf sich nicht auf die bloße Abwesenheit bekannter Fehler verlassen. Erst das digitale Siegel an der Peripherie macht die Pipeline unmanipulierbar und schafft das unerschütterliche Fundament für ein echtes Zero-Trust-Modell im Cloud-Native–Engineering.

FAQ: Image Signing & Cosign in der Praxis

Wo sollten die privaten Schlüssel für das Image Signing am besten aufbewahrt werden?

Die Sicherheit des gesamten Signatur-Setups steht und fällt mit der Geheimhaltung des privaten Schlüssels. Im professionellen Enterprise-Umfeld sollten diese Schlüssel niemals als rohe Textdateien in den CI/CD-Variablen liegen. Best Practice ist die Integration von Key-Management-Systemen (KMS) oder Cloud-Hardware-Sicherheitsmodulen (HSM/BYOHSM). Die Pipeline triggert den Signiervorgang dann über eine gesicherte API, ohne dass der Schlüssel jemals die geschützte Hardware-Umgebung verlässt.

Was passiert, wenn ein signiertes Image nachträglich eine neue kritische CVE erhält?

Das Image Signing bestätigt nur, dass das Image authentisch ist und aus Ihrer Pipeline stammt. Es schützt nicht vor dem Altern von Software. Wenn nach drei Monaten eine neue Schwachstelle im Image entdeckt wird, bleibt die Signatur zwar mathematisch gültig, aber der parallel aktive CVE-Scanner in Harbor wird Alarm schlagen. Der nachgelagerte Admission Controller im Kubernetes–Cluster prüft beide Kriterien: Er verlangt eine gültige Signatur und die Einhaltung der maximalen CVE-Schwellenwerte.

Unterstützt das Setup auch schlüsselloses Signieren (Keyless Signing)?

Ja. Cosign und das Sigstore-Ökosystem unterstützen ein hochmodernes Verfahren namens Keyless Signing. Dabei müssen keine langlebigen kryptografischen Schlüssel mehr verwaltet werden. Stattdessen authentifiziert sich die CI/CD-Pipeline über kurze OpenID-Connect-Tokens (OIDC) bei einer internen Zertifizierungsstelle. Diese stellt ein ultrakurzlebiges, digitales Zertifikat aus, das genau für den Moment des Pushs gültig ist. Das eliminiert das Risiko, dass private Schlüssel jemals gestohlen oder geleakt werden können.