Jedes Container-Image, das Sie ausführen, ist eine Software, der Sie blind vertrauen, sofern Sie keine Überprüfung vorgenommen haben. Es stammt aus einer Registry, durchläuft eine Build-Pipeline, und irgendwo auf diesem Weg hätte jeder mit Zugriff darauf es austauschen können. Die Containersignatur schließt diese Lücke. Sie versehen ein Image mit einer kryptografischen Signatur, und Ihr Cluster weigert sich, alles auszuführen, was keine gültige Signatur besitzt.
Lange Zeit galt dies als wünschenswertes Extra, das sicherheitsbewusste Teams implementierten, während alle anderen es aufschoben. Das ändert sich rasant. Regulierungen wie der EU-Cyberresilience Act und Rahmenwerke wie Supply Chain Levels for Software Artifacts (SLSA) , entwickelt von Google, rücken die Integrität der Lieferkette immer weiter nach oben auf die Prioritätenliste. Für Unternehmen, die containerisierte Software ausliefern, sind signierte Images mit erzwungener Verifizierung zu einer Priorität für 2026 geworden – und nicht mehr nur ein Projekt für die Zukunft.
Zwei Tools dominieren die Diskussion: Notation vom CNCF Notary Project und Cosign vom Sigstore Project. Oft wird die Wahl als Funktionsvergleich dargestellt. Sinnvoller ist es jedoch, sie als Entscheidung zwischen zwei unterschiedlichen Vertrauensmodellen zu verstehen, denn genau das entscheidet darüber, welches am besten zu Ihrer Organisation passt.
Was die beiden Werkzeuge gemeinsam haben
Bevor man auf die Unterschiede eingeht, ist es hilfreich, die gemeinsamen Grundlagen zu erkennen, denn diese sind größer, als man vielleicht erwarten würde.
Sowohl Notation als auch Cosign signieren OCI-Artefakte, nicht nur Container-Images. Beide speichern die Signatur in Ihrer Registry als separates Artefakt, das dem Image mithilfe der OCI 1.1 Referrers API zugeordnet ist . Dadurch wird die Signatur zusammen mit dem Image übertragen und benötigt keine separate Datenbank. Beide verifizieren anhand eines Digests anstatt eines Tags, was wichtig ist, da Tags verschoben werden können, ein Digest jedoch nicht. Beide sind in dieselbe Enforcement-Schicht in Kubernetes integriert, sodass Sie unabhängig von Ihrer Wahl Deployments anhand einer gültigen Signatur steuern können.
Tatsächlich können beide Verfahren auf demselben Image parallel verwendet werden. Manche Organisationen nutzen Cosign in ihrer CI-Pipeline, um die Sicherheit zu erhöhen, und verwenden Notation für die formale Freigabeunterzeichnung. Beide Signaturen sind dann vor der Bereitstellung erforderlich. Die Tools schließen sich nicht gegenseitig aus. Für die meisten Teams, die sich für einen primären Ansatz entscheiden, ist jedoch das Vertrauensmodell ausschlaggebend.
Cosign: Identitätsbasiert, schlüssellos und schnell zu implementieren
Das Hauptmerkmal von Cosign ist die schlüssellose Signatur – und sie ist wirklich clever. Anstatt einen langlebigen Signaturschlüssel zu verwalten, authentifiziert sich der Unterzeichner über einen OIDC-Identitätsanbieter, dieselbe Art von Login, die Ihr CI-System bereits verwendet. Ein Sigstore-Dienst namens Fulcio stellt ein kurzlebiges X.509-Zertifikat aus , das etwa 10 Minuten gültig ist und die Identität mit einem temporären Schlüsselpaar verknüpft. Sowohl die Signatur als auch das Zertifikat werden in einem Transparenzprotokoll namens Rekor protokolliert. So entsteht ein nachvollziehbarer Nachweis darüber, wer wann signiert hat, selbst nachdem der Schlüssel abgelaufen ist.
Der Vorteil liegt auf der Hand. Es muss kein Signaturschlüssel gespeichert, rotiert, geschützt oder verloren werden, da dieser nie persistent ist. Für Teams ohne dedizierte PKI- Funktion entfällt damit der mit Abstand schwierigste Teil des Signiervorgangs. Cosign bietet zudem erstklassige Unterstützung für das Anhängen von SBOMs und SLSA-Herkunftsnachweisen sowie das umfassendste Ökosystem an Kubernetes-Durchsetzungstools. Wenn Sie eine moderne Pipeline für Herkunftsnachweis und Attestierung aufbauen und schnell vorankommen möchten, ist Cosign oft der schnellste Weg.
Der Kompromiss liegt im Vertrauensmodell selbst. Schlüsselloses Signieren bindet Vertrauen an eine Identität, die von einem externen OIDC-Anbieter verifiziert wird, und nutzt standardmäßig die öffentliche Infrastruktur von Sigstore. Fulcio und Rekor lassen sich zwar selbst hosten, um dies intern zu realisieren, doch das ist mit erheblichem operativem Aufwand verbunden. Identitätsbasiertes Vertrauen ist zwar leistungsstark, unterscheidet sich aber grundlegend vom Schlüsselverwaltungsmodell, auf dem viele Compliance-Regelungen basieren.
Anmerkung: Unternehmensweite PKI und von Ihnen kontrollierte Schlüssel
Notation verwendet den Ansatz, den große Unternehmen seit Jahrzehnten für die Codesignierung einsetzen. Sie signieren mit einem X.509-Zertifikat einer vertrauenswürdigen Zertifizierungsstelle (in der Regel Ihrer eigenen). Die Verifizierung prüft die Signatur anhand einer von Ihnen definierten Vertrauensrichtlinie gegen diese Zertifizierungsstelle. Die Signaturen verwenden das COSE-Format und werden, wie bei Cosign, als OCI-Artefakte in der Registry gespeichert. Die Vertrauensrichtlinien von Notation lassen sich präzise auf bestimmte Registries, Repositories oder Identitäten beschränken, was Organisationen mit Bedarf an delegierter und segmentierter Signaturberechtigung entgegenkommt.
Notation eignet sich ideal für regulierte Unternehmen, da es fest in Ihrer eigenen PKI verankert ist. Der Signaturschlüssel ist ein dauerhaftes, unternehmenseigenes Gut unter Ihrer Kontrolle und keine flüchtige Berechtigung, die an einen externen Identitätsdienst gebunden ist. Das Plugin-Modell von Notation integriert sich in Schlüsselverwaltungssysteme und Hardware-Sicherheitsmodule (HSM), sodass der Signaturschlüssel in einem HSM gespeichert bleibt und dieses nie verlässt. Für Organisationen mit Compliance-Anforderungen hinsichtlich der Schlüsselverwaltung, wie sie beispielsweise durch FIPS- Validierung oder FedRAMP entstehen, ist dieser hardwarebasierte, unternehmenseigene Schlüssel oft das einzige Modell, das diese Anforderungen erfüllt. Es fügt sich auch nahtlos in Umgebungen ein, in denen externe öffentliche Infrastruktur nicht zur Verfügung steht, aber bereits eine interne Zertifizierungsstelle (CA) vorhanden ist.
Der Nachteil gegenüber schlüsselloser Cosignierung besteht darin, dass Sie wieder Schlüssel und eine PKI verwalten müssen. Das bedeutet einen erheblichen Mehraufwand. Für Unternehmen, die bereits eine PKI betreiben , ist dies jedoch keine neue Arbeit, sondern eine Erweiterung bestehender Funktionen. Dadurch erhalten Sie ein Vertrauensmodell, das sich nahtlos in die Arbeitsweise Ihrer Auditoren einfügt. Der Zertifikatswiderruf erfolgt über Standard-PKI-Mechanismen wie CRL oder OCSP . Das bedeutet, dass ein kompromittiertes Signaturzertifikat widerrufen und damit signierte Bilder durch Aktualisierung Ihrer Vertrauensrichtlinie gekennzeichnet oder blockiert werden können. Dies entspricht genau dem Vorgehen von Unternehmenssicherheitsteams bei Vorfällen mit Cosignierungszertifikaten.
Was viele vergessen: Unterschreiben ist nur die halbe Miete
Hier liegt der Fehler, der viele Signaturbemühungen stillschweigend untergräbt. Eine Signatur auf einem Image ist an sich wirkungslos. Wenn in Ihrem Cluster keine Überprüfung stattfindet, lässt sich ein unsigniertes oder manipuliertes Image genauso leicht ausführen wie ein signiertes. Die Sicherheit besteht erst im Moment der Ausführung.
Die Durchsetzung von Richtlinien in Kubernetes erfolgt über die Zugriffskontrolle, und es empfiehlt sich, diese in Schichten zu betrachten. Ein Pre-Deployment-Gate, implementiert mit einem Zugriffscontroller wie Kyverno, dem Sigstore Policy Controller oder OPA Gatekeeper in Kombination mit Ratify, prüft jedes Image vor der Freigabe und lehnt alle Images ohne gültige Signatur gemäß Ihrer Richtlinie ab.
Die Laufzeitumgebung kann eine zweite Ebene hinzufügen: Neuere Versionen von containerd unterstützen einen Image-Verifizierer, der Signaturen beim Herunterladen prüft, bevor ein Image auf einem Knoten ausgeführt werden darf. Darüber hinaus kann eine Freigabeprüfung eine gültige Signatur erfordern, bevor ein Image von der Staging-Umgebung in die Produktions-Registry verschoben wird. Regelmäßige Laufzeitprüfungen können zudem bestätigen, dass bereits laufende Images weiterhin den aktuellen Richtlinien entsprechen.
Diese Zulassungscontroller arbeiten in der Regel in einem von zwei Modi, und der Unterschied ist wichtiger als es zunächst scheint. Im Audit-Modus führt eine fehlgeschlagene Überprüfung zu einer Warnung, das Image wird aber trotzdem bereitgestellt. Im Enforce-Modus hingegen wird die Bereitstellung bei einer fehlgeschlagenen Überprüfung sofort blockiert. Der Audit-Modus ist ein guter Ausgangspunkt, um zu sehen, was abgelehnt würde, ohne etwas zu beschädigen. Er bietet jedoch keinen Schutz.
Der Sinn des Signierens besteht darin, den Erzwingungsmodus mit Zuversicht zu erreichen, und dies sicher zu erreichen bedeutet, die Richtlinie schrittweise, Namespace für Namespace, einzuführen, wobei Ihre Signierungspipeline zuverlässig genug sein muss, damit legitime Images niemals fehlschlagen.
Hier zeigt sich, dass die Wahl des Tools nur dann von der Realität abhängt. Unabhängig davon, welches Tool man wählt, entfalten die Signaturen erst dann ihren Wert, wenn die Durchsetzungsebene aktiv, optimiert und ausreichend vertrauenswürdig ist, um tatsächlich Blockierungen durchzuführen. Ein Signaturprogramm, das den Prüfmodus nie verlässt, ist reine Show.
Wie Verschlüsselungsberatung helfen kann
Die Implementierung einer Containersignatur, die den Anforderungen von CRA und SLSA genügt, hängt zum Teil von der Wahl der Tools und zum Teil davon ab, worauf Ihr Vertrauen tatsächlich beruht. Für die meisten Unternehmen liegt die Antwort in einer Signatur, die auf einer von Ihnen kontrollierten PKI basiert und deren Schlüssel in Hardware geschützt sind – und genau das tun wir.
CodeSign Secure , unsere Lösung für Codesignierung, bietet Ihnen einen kontrollierten Signierungsprozess für Ihre Softwareartefakte, einschließlich Container-Images, mit den Richtlinienkontrollen, der Zugriffsverwaltung und dem Schlüsselschutz, die ein PKI-basierter Ansatz im Notation-Stil voraussetzt. Anstatt Signaturschlüssel auf CI-Runnern und Entwicklerrechnern zu verteilen, läuft die Signierung über ein kontrolliertes System mit einem lückenlosen Prüfprotokoll – genau das, was Auditoren und Lieferketten-Frameworks erwarten.
Was Codesign Secure für die Containersignatur bietet
Dieser Beitrag hat sich hauptsächlich mit Notation und Cosign beschäftigt, daher ist es wichtig, konkret zu erläutern, was unsere eigene Plattform bietet, denn ein Vertrauensmodell ist nur so gut wie der dazugehörige Signaturprozess. CodeSign Secure ist eine zentrale Signaturplattform, die speziell für moderne DevOps-Umgebungen entwickelt wurde.
Es integriert sich in die CI/CD-Systeme, die die meisten Teams bereits verwenden, darunter Azure DevOps, Jenkins und GitLab, und stellt jeden Signiervorgang hinter Zugriffskontrollen und Genehmigungsworkflows, sodass die Signierung kontrolliert bleibt und nicht über Build-Agenten verstreut ist.
Die Signaturschlüssel werden in einem FIPS 140-2 Level 3-konformen Hardware-Sicherheitsmodul gespeichert. Die Plattform ist mit den bereits in Unternehmen eingesetzten HSMs kompatibel, darunter Entrust nCipher, Thales Luna, Utimaco und Securosys – sowohl lokal als auch in der Cloud. Der Zugriff wird durch die Integration mit Microsoft Active Directory und Keycloak mit rollenbasierter Zugriffskontrolle und anpassbaren Workflows gesteuert.
Richtlinien werden auf Plattformebene durchgesetzt. Daher wird nichts signiert, solange es nicht die von Ihnen definierten Kriterien erfüllt – vom Zertifikatstyp bis hin zu den in jeder Phase erforderlichen Genehmigungen. Die Funktionstrennung ist integriert: Ein Entwickler kann zwar eine Signatur anfordern, diese muss jedoch von einem Release-Manager oder Sicherheitsbeauftragten genehmigt werden, bevor sie angewendet wird. Dadurch wird das Risiko ausgeschlossen, dass ein einzelnes kompromittiertes Konto eigenständig Software signiert und ausliefert.
Da es eine breite Palette von Formaten signiert, darunter Docker-Container und OCI-Images sowie Firmware-Binärdateien, ausführbare Dateien und Pakete, eignet es sich sowohl für den Anwendungsfall der Containersignierung , um den es in diesem Beitrag geht, als auch für die übrigen Signaturanforderungen einer Organisation und lässt sich in gängige Tools wie Signtool, Jarsigner und JSign integrieren.
Es nutzt clientseitiges Hashing und sichere Zeitstempelung, sodass Signaturen auch nach Ablauf eines Zertifikats gültig bleiben. Jedes Signierungsereignis wird zusammen mit den zugehörigen Genehmigungen und Ablehnungen in Audit-Logs protokolliert, die über OpenTelemetry an SIEM-Tools wie Grafana, Loki und Splunk übertragen werden. Dadurch erhalten Sicherheitsteams die von Lieferketten-Frameworks erwarteten Nachweise.
Es kann als vollständig verwalteter Cloud-Dienst mit integrierter HSM-Sicherheit oder lokal mit in der Cloud oder lokal gespeicherten Schlüsseln betrieben werden, sodass das Bereitstellungsmodell Ihren Anforderungen entspricht. Es signiert außerdem direkt auf dem HSM mit Post-Quanten-Algorithmen, darunter ML-DSA (Module-Lattice-Based Digital Signature Algorithm) und LMS (Leighton-Micali Signatures), und unterstützt Dual-Signaturen, die eine klassische RSA- oder ECDSA -Signatur mit einer Post-Quanten-Signatur für einen schrittweisen Übergang kombinieren.
Da die Signierung von Unternehmensabbildern nur so vertrauenswürdig ist wie die dahinterstehende Zertifizierungsstelle (CA), bietet Ihnen PKI-as-a-Service eine moderne, gut geführte CA zur Ausstellung und Verwaltung der Signaturzertifikate, die Ihre Vertrauensrichtlinie untermauern – ohne dass Sie diese Infrastruktur selbst aufbauen und warten müssen. Dies ist die Vertrauensgrundlage, anhand derer eine Notation-Bereitstellung verifiziert wird. Nur so kann die gesamte Kette glaubwürdig sein.
Um die Signaturschlüssel selbst zu schützen, isoliert HSM-as-a-Service diese in einem Hardware-Sicherheitsmodul. Dadurch wird verhindert, dass ein Signaturschlüssel von einem Build-Server kopiert oder aus einer Pipeline extrahiert wird. Für Organisationen, die den FIPS- oder FedRAMP-Vorgaben hinsichtlich der Schlüsselverwaltung unterliegen, sind hardwarebasierte Schlüssel in der Regel unerlässlich. Die Integration dieser Schlüssel in Ihren Signatur-Workflow ermöglicht es Ihnen, diese Anforderungen zu erfüllen, anstatt sie zu umgehen.
Wenn Sie sich fragen, wie Sie Ihre Container-Images signieren und wo Sie die Vertrauensbasis schaffen möchten, oder wenn Sie Unterstützung bei der Implementierung eines Signaturprogramms bis hin zur erzwungenen Verifizierung benötigen, kontaktieren Sie uns . Wir helfen Ihnen gerne bei der Konzeption und dem Aufbau der zugrunde liegenden PKI und des Schlüsselschutzes.
Fazit
Die Frage Notation versus Cosign dreht sich weniger um den Funktionsumfang des jeweiligen Tools, sondern vielmehr darum, welches Vertrauensmodell am besten zu Ihrem Unternehmen passt. Cosigns schlüsselloses Signieren ist schnell implementiert und eignet sich hervorragend für moderne, attestierungsintensive Prozesse, insbesondere für Teams, die auf eine PKI verzichten möchten. Notations Enterprise-PKI-Ansatz hingegen ist ideal für Organisationen, die bereits Zertifikate verwalten, Schlüssel benötigen, die sie selbst kontrollieren und in Hardware speichern können, und die Compliance-Anforderungen im Bereich der Schlüsselverwaltung erfüllen müssen. Viele Unternehmen nutzen letztendlich beide Lösungen für verschiedene Phasen desselben Prozesses.
Ganz gleich, wofür Sie sich entscheiden, zwei Dinge bleiben bestehen: Die Signatur muss auf einem tragfähigen Vertrauensmodell basieren und bei der Zulassung durchgesetzt werden – sie darf nicht einfach nur erstellt und dann vergessen werden. Ein signiertes Bild, dessen Echtheit nicht überprüft wird, ist genauso wenig sicher wie ein unsigniertes.
Die Lieferkettenregulierung wird nicht gelockert, und der Druck, die Herkunft der Software nachzuweisen, wird weiter zunehmen. Organisationen, die in diesem Jahr bewusst auf die Implementierung von Signatur- und Durchsetzungssystemen gesetzt haben und dabei auf eine von ihnen kontrollierte Infrastruktur vertrauen, werden die nächste Compliance-Anforderung als erledigte Aufgabe und nicht als dringendes Problem betrachten.
