Cosign vs. Notation vs. GPG: 796 Pakete gehackt

Ein Bug in einer signierten Docker-Registry wirkt banal, bis ein Angreifer eine gefälschte Image-Version einschleust, die niemand bemerkt. Genau das ist 2025 und 2026 im großen Stil passiert: Der npm-Wurm Shai-Hulud infizierte laut Wiz ab dem 15. September 2025 hunderte Pakete, eine zweite Welle im November 2025 traf laut Berichten von Invicti und The Hacker News über 25.000 GitHub-Repositories. Wer Container-Images, Binaries oder Pakete nicht kryptografisch signiert und die Signatur beim Deployment prüft, hat gegen solche Angriffe praktisch keine Verteidigungslinie. Genau deshalb ist die Wahl zwischen Cosign, Notation und dem alten GPG-Ansatz 2026 keine akademische Frage mehr, sondern eine, die Sicherheitsteams in DACH-Unternehmen aktiv beantworten müssen. Dieser Vergleich zeigt, wie die drei Werkzeuge technisch funktionieren, was sie kosten, wer sie bereits produktiv einsetzt und welches Tool für welches Szenario passt.

Warum Container- und Code-Signaturen 2026 zur Pflicht werden

Software-Lieferketten bestehen heute aus hunderten Abhängigkeiten, die aus öffentlichen Registries wie npm, PyPI oder Docker Hub gezogen werden. Jede davon ist ein potenzieller Angriffspunkt. Das US-amerikanische National Institute of Standards and Technology (NIST) bringt es in seinem Bulletin zu Code-Signaturen auf den Punkt: “Software that hasn’t been securely developed isn’t part of a secure supply chain” (NIST ITL Bulletin). Eine Signatur allein macht Code nicht sicher, aber sie macht Manipulationen sichtbar.

NIST beschreibt den eigentlichen Nutzen so: “When securely implemented, digitally signing code provides both data integrity to prove that the code was not modified, and source authentication to identify who was in control of the code at the time it was signed” (NIST). Genau diese zwei Eigenschaften, Integrität und Herkunftsnachweis, fehlen in vielen Build-Pipelines noch komplett. Wer ein Container-Image aus einer Registry zieht, vertraut meist blind auf den Tag-Namen statt auf eine kryptografisch geprüfte Kette.

Die Cloud Security Alliance bezeichnet Shai-Hulud als den ersten dokumentierten, sich selbst replizierenden Supply-Chain-Angriff in dieser Größenordnung im npm-Ökosystem. Über mindestens drei Kampagnen zwischen September 2025 und April 2026 wurden nach dieser Einschätzung mehr als 796 Pakete kompromittiert, mit zusammengerechnet über 20 Millionen wöchentlichen Downloads. Das ist kein Nischenproblem einzelner Open-Source-Projekte, sondern ein systemisches Risiko für jede Firma, die npm, PyPI oder Container-Registries in ihrer Build-Pipeline nutzt. Genau hier setzen Cosign, Notation und klassisches GPG an, mit sehr unterschiedlichen Ansätzen.

Ein typisches Cloud-native-Projekt zieht heute leicht mehrere hundert transitive Abhängigkeiten in ein einziges Container-Image. Jede davon stammt von einem anderen Maintainer, wird über einen anderen CI-Job gebaut und landet über eine andere Registry im eigenen Cluster. Ohne kryptografische Signatur bleibt für ein Sicherheitsteam am Ende nur eine einzige belastbare Prüfung übrig: Vertraue ich dem Tag-Namen? Genau dieses Vertrauen auf Zuruf ist der Hebel, den Angreifer bei Typosquatting, Dependency Confusion und kompromittierten Maintainer-Konten ausnutzen. Eine Signaturkette macht aus diesem impliziten Vertrauen eine überprüfbare, technische Tatsache.

Cosign im Überblick: Sigstore, Fulcio und Rekor

Cosign ist das Signier-Werkzeug des Sigstore-Projekts und hat sich laut mehreren technischen Vergleichen als De-facto-Standard für SLSA-Provenance und In-toto-Attestierungen in der Cloud-Native-Welt etabliert. Der zentrale Unterschied zu klassischen Signaturverfahren: Cosign verlangt keinen langlebigen privaten Schlüssel, den ein Entwickler jahrelang schützen muss. Stattdessen nutzt es “keyless signing” über die Zertifizierungsstelle Fulcio, die auf Basis einer OIDC-Identität (etwa ein GitHub-Actions-Workflow oder ein GitLab-CI-Job) ein kurzlebiges X.509-Zertifikat ausstellt, das laut Sigstore-Dokumentation nur rund zehn Minuten gültig ist.

Jede Signatur landet zusätzlich im öffentlichen Transparenzprotokoll Rekor, einem Merkle-Baum-basierten Log, das nachträgliche Manipulationen an der Signaturhistorie unmöglich macht. Das Cosign-Repository auf GitHub beschreibt das Projekt entsprechend als “Code signing and transparency for containers and binaries”. Am 8. Oktober 2025 kündigte das Sigstore-Team auf seinem Blog Cosign v3 an. Die neue Version bündelt Zertifikat und Signatur in einer einzigen .sigstore.json-Datei über das neue Bundle-Format und vereinfacht damit Signier- und Verifizierungs-Workflows spürbar.

Cosign unterstützt neben Keyless-Signing auch klassisches Signieren mit selbst verwalteten Schlüsseln, die in einer Datei, einem Cloud-KMS wie AWS KMS oder Google Cloud KMS, oder einem Hardware-Sicherheitsmodul über PKCS#11 liegen können. Diese Flexibilität macht Cosign sowohl für Open-Source-Projekte mit öffentlicher Sigstore-Infrastruktur als auch für Firmen mit eigener, privater Sigstore-Instanz nutzbar. Signaturen speichert Cosign direkt in der OCI-Registry als separates Artefakt über die OCI-1.1-Referrers-API, verknüpft mit dem Image-Digest statt mit einem veränderbaren Tag.

Neben der reinen Signatur bietet Cosign mit dem Unterbefehl cosign attest eine zweite Ebene: strukturierte Metadaten über den Build-Prozess selbst, verpackt als In-toto-Statement und über das DSSE-Envelope-Format signiert. Ein Build-Server kann so nicht nur bestätigen, dass ein Image von ihm stammt, sondern auch, welcher Git-Commit, welcher Build-Schritt und welche Testergebnisse dazu gehören. Auf der Verifizierungsseite liest cosign verify-attestation genau diese Informationen aus und kann sie gegen eine Policy prüfen, etwa “nur Images akzeptieren, die aus dem main-Branch mit erfolgreichem Testlauf gebaut wurden”. Genau diese Kombination aus Signatur und Attestierung macht Cosign zum technischen Rückgrat vieler SLSA-Level-3-Implementierungen.

Notation im Überblick: Das Notary-Project-Modell

Notation ist die Referenzimplementierung des CNCF-Projekts Notary Project und der Nachfolger des älteren Notary v1, zu dem es laut technischer Dokumentation nicht rückwärtskompatibel ist. Während Notary v1 auf dem Trust-Update-Framework (TUF) basierte, setzt Notation konsequent auf die OCI Signature Specification und unterstützt die Signaturformate JWS und COSE. Genau wie Cosign speichert Notation Signaturen als eigenständige OCI-Manifeste direkt in der Registry, verknüpft mit dem Image-Digest.

Der entscheidende konzeptionelle Unterschied zu Cosign liegt im Vertrauensmodell. Notation setzt auf klassische Public-Key-Infrastruktur mit X.509-Trust-Stores und Trust-Policies statt auf kurzlebige, identitätsbasierte Zertifikate. Für Unternehmen mit einer bestehenden internen Zertifizierungsstelle (CA) fügt sich das nahtlos in etablierte Prozesse ein, ohne dass Teams neue Konzepte wie OIDC-Identitäten oder öffentliche Transparenzprotokolle einführen müssen. Signing- und Verification-Plug-ins erlauben die Anbindung an KMS-Dienste oder Hardware-Sicherheitsmodule.

Sowohl Microsoft als auch Amazon empfehlen Notation für das Signieren von Container-Images, die in ihren jeweiligen verwalteten Kubernetes-Angeboten laufen, also Azure Kubernetes Service (AKS) und Amazon Elastic Kubernetes Service (EKS). Das ist ein starkes Signal: Wer bereits in einem der beiden Cloud-Ökosysteme mit einer etablierten PKI arbeitet, bekommt mit Notation ein Werkzeug, das sich ohne Bruch in bestehende Governance-Strukturen einfügt.

In der Praxis beginnt ein Notation-Setup mit der Trust-Policy, einer JSON-Datei, die festlegt, welchen Signaturen ein Verifizierer überhaupt vertraut. Darin stehen der Name der vertrauenswürdigen Identität, der referenzierte Trust-Store und die Regel, ob eine gültige Signatur zwingend vorhanden sein muss oder nur optional geprüft wird. Für Testzwecke lässt sich mit notation cert generate-test in Minuten ein selbstsigniertes Zertifikat erzeugen, für den Produktivbetrieb bindet ein Plug-in stattdessen die firmeneigene Zertifizierungsstelle oder einen Cloud-Schlüsseldienst ein. Dieser Aufbau macht Audits einfacher, weil sich jede Vertrauensentscheidung auf eine benannte, überprüfbare Policy-Datei zurückführen lässt statt auf implizites Vertrauen in eine Build-Pipeline.

GPG: Der Alteingesessene mit Schwächen

GPG (GNU Privacy Guard) ist der älteste der drei Ansätze und stammt aus einer Zeit, in der es weder Container-Registries noch OCI-Standards gab. Für das Signieren von Git-Commits und -Tags bleibt GPG weit verbreitet und funktioniert zuverlässig. Für Container-Images zeigt sich jedoch eine strukturelle Schwäche: Es gibt keine standardisierte Möglichkeit, eine GPG-Signatur direkt an ein OCI-Artefakt in der Registry zu hängen. Signaturen müssen separat verteilt werden, etwa als eigene Datei neben dem Image oder über einen zusätzlichen Kanal, den jedes Team individuell aufbauen muss.

GPG selbst stammt aus dem Jahr 1999 und wurde für E-Mail-Verschlüsselung und das Signieren einzelner Dateien entworfen, lange bevor jemand an Container oder OCI-Registries dachte. Für Git-Commits funktioniert das Modell bis heute gut: Ein Entwickler signiert einen Commit mit git commit -S, GitHub oder GitLab zeigen daraufhin ein verifiziertes Häkchen an, sofern der öffentliche Schlüssel hinterlegt ist. Für Container-Artefakte erzeugt genau dieses Alter in der Praxis operative Reibung: Ein CI/CD-System muss die .sig-Datei zusätzlich zum Image transportieren, ein Verifizierungsschritt muss beide Artefakte korrekt zuordnen, und es gibt kein eingebautes Transparenzprotokoll, das eine nachträgliche Manipulation sichtbar machen würde. Die Linux Foundation fasst diesen Aspekt der Signaturkette in ihrer CNCF-Sicherheitsleitlinie so zusammen: “Signing source code (commits and tags) ensures integrity and non-repudiation of source code by enabling out-of-band verification of the code” (CNCF Software Supply Chain Best Practices). Für Commits bleibt das ein solides Argument für GPG, für Container-Artefakte im großen Maßstab wird es zum Nachteil.

Cosign vs. Notation vs. GPG: Die technische Vergleichstabelle

Die folgende Tabelle fasst die zentralen technischen Unterschiede zusammen, basierend auf den offiziellen Projekt-Dokumentationen von Sigstore, dem Notary Project und GnuPG sowie unabhängigen technischen Vergleichen von secure-pipelines.com und oneuptime.com.

Kriterium	Cosign (Sigstore)	Notation (Notary Project)	GPG
Trägerorganisation	Sigstore / Open Source Security Foundation	CNCF Notary Project	GnuPG e.V., unabhängig
Vertrauensmodell	Keyless (OIDC + Fulcio) oder klassische PKI	X.509-Trust-Stores, Trust-Policies	Web of Trust, manuelle Schlüsselverwaltung
Typischer Schlüssel	Kurzlebiges X.509-Zertifikat, laut Sigstore ca. 10 Min. gültig	Langlebiges Enterprise-PKI-Zertifikat	RSA- oder ECC-Schlüsselpaar, oft jahrelang gültig
Transparenzprotokoll	Rekor, öffentliches Merkle-Baum-Log	Kein natives Log	Kein Log
Signaturformat	DSSE / In-toto JSON-Envelope, Sigstore-Bundle	JWS und COSE	OpenPGP-Signaturformat
Speicherort der Signatur	OCI-Registry, OCI-1.1-Referrers-API	OCI-Registry, eigenes Manifest	Externe Datei, kein Registry-Standard
Bindung an Image	Digest-basiert	Digest-basiert	Meist Tag- oder Datei-basiert
SLSA-/In-toto-Support	Nativ, Referenzimplementierung	Über Plug-ins möglich	Keine native Unterstützung
CI/CD-Integration	GitHub Actions, GitLab CI, Tekton, laut secure-pipelines.com “exzellent”	Azure DevOps, AWS-Dienste, gut dokumentiert	Manuell, Skript-basiert
Cloud-Empfehlung	Bevorzugt für Open-Source und cloud-native Projekte	Von Microsoft (AKS) und Amazon (EKS) empfohlen	Keine offizielle Cloud-Empfehlung für Container
Lizenz	Apache 2.0	Apache 2.0	GNU GPL
Aktuelle Hauptversion (Stand September 2026)	Cosign v3 (seit 8. Oktober 2025)	Notation, aktive Notary-Project-Releases	GnuPG, etabliertes Release-Modell

Bemerkenswert: Cosign und Notation schließen sich nicht gegenseitig aus. Beide Werkzeuge signieren OCI-Artefakte, nicht nur Container-Images, und beide können auf demselben Image koexistieren. Ein Team kann also mit Cosign keyless signieren und parallel eine Notation-Signatur für Compliance-Anforderungen einer internen PKI hinzufügen.

Schlüsselverwaltung: Keyless, KMS oder klassische PKI

Der größte Denkfehler beim Vergleich der drei Werkzeuge ist, sie nur als “Signier-Tools” zu behandeln. Tatsächlich unterscheiden sie sich vor allem in der Frage, wer für den privaten Schlüssel verantwortlich ist und wie lange dieser gültig bleibt. Bei GPG liegt die volle Verantwortung beim Entwickler oder Team: Der Schlüssel muss generiert, gesichert und im Ernstfall widerrufen werden. Ein gestohlener GPG-Schlüssel bleibt so lange gefährlich, bis jemand den Widerruf aktiv veröffentlicht.

Cosign löst dieses Problem mit Keyless-Signing radikal anders: Es gibt schlicht keinen langlebigen Schlüssel, der gestohlen werden kann. Fulcio stellt pro Signiervorgang ein neues Zertifikat aus, gebunden an eine verifizierte OIDC-Identität. Wird ein CI/CD-Token kompromittiert, ist der Schaden zeitlich eng begrenzt, weil das ausgestellte Zertifikat ohnehin nach wenigen Minuten abläuft. Wer dennoch klassische Schlüssel bevorzugt, kann Cosign genauso mit einem Cloud-KMS oder einem HSM über PKCS#11 betreiben.

Notation geht den entgegengesetzten Weg und baut konsequent auf Enterprise-PKI. Trust-Policies definieren, welchen Zertifizierungsstellen ein Verifizierer vertraut, und Plug-ins binden externe Schlüsseldienste wie AWS KMS, Azure Key Vault oder HashiCorp Vault an. Für Sicherheitsteams, die bereits eine funktionierende interne CA betreiben und diese nicht durch ein neues Vertrauensmodell ersetzen wollen, ist das der pragmatischere Weg. Der Nachteil: Die Verantwortung für Schlüssel-Rotation, Widerruf und Zertifikatslebenszyklus bleibt vollständig beim eigenen Team.

Diese Verantwortung zeigt sich besonders im Ernstfall eines Schlüsseldiebstahls. Bei Notation muss ein Team eine Widerrufsliste pflegen oder OCSP-Abfragen einrichten, damit Verifizierer einen kompromittierten Schlüssel rechtzeitig als ungültig erkennen, ein Prozess, der in der klassischen PKI-Welt seit Jahrzehnten bekannt, aber auch fehleranfällig ist. Bei Cosign entfällt dieser Schritt im Keyless-Modus vollständig, weil ein gestohlenes Zertifikat ohnehin binnen Minuten abläuft. Wer Cosign dagegen mit einem klassischen, langlebigen Schlüssel betreibt, steht vor demselben Widerrufsproblem wie ein Notation-Team, nur ohne die dort übliche Trust-Policy-Infrastruktur, die den Widerruf strukturiert abbildet.

SLSA-Framework: Wie Provenance-Level die Wahl beeinflussen

SLSA (Supply-chain Levels for Software Artifacts) wurde 2021 von Google gestartet und ist inzwischen ein Projekt der Open Source Security Foundation unter dem Dach der Linux Foundation. Mit Version 1.0 im April 2023 stellte das Framework sein Level-Modell um: Statt der ursprünglichen Skala SLSA 1 bis 4 aus der Vorabversion definiert die aktuelle Spezifikation einen Build-Track mit den Stufen L0 bis L3, wie die offizielle SLSA-Spezifikation beschreibt.

L0: Keine Garantien, keine dokumentierte Build-Herkunft
L1: Provenance wird erzeugt und dokumentiert, aber nicht zwingend geprüft
L2: Signierte Provenance von einer gehosteten Build-Plattform, Schutz vor nachträglicher Manipulation
L3: Gehärtete Build-Plattform mit Schutz vor Manipulation während des Build-Vorgangs selbst

Hier zeigt sich ein handfester praktischer Unterschied zwischen den drei Werkzeugen: Cosign ist die faktische Referenzimplementierung, wenn ein Projekt In-toto-Attestierungen erzeugen und gegen SLSA-Level verifizieren will. Notation unterstützt vergleichbare Attestierungen nur über zusätzliche Plug-ins, und GPG bietet dafür überhaupt keinen nativen Mechanismus. Wer SLSA-Level 2 oder 3 anstrebt, kommt an Cosign oder einer gleichwertigen Sigstore-kompatiblen Lösung faktisch nicht vorbei, selbst wenn die eigentlichen Artefaktsignaturen am Ende zusätzlich mit Notation für PKI-Compliance ergänzt werden.

Wichtig ist dabei, SLSA nicht mit einem einzelnen Zertifikat zu verwechseln. Ein Level ist immer eine Eigenschaft der gesamten Build-Kette, nicht eines einzelnen Signiervorgangs: Ein Projekt erreicht L2 erst, wenn die Provenance auf einer gehosteten, gemeinsam genutzten Build-Plattform entsteht, etwa GitHub Actions oder GitLab CI, statt auf dem Laptop eines einzelnen Entwicklers. L3 verlangt zusätzlich, dass selbst ein Administrator der Build-Plattform die Provenance nicht nachträglich fälschen kann. Diese Abstufung erklärt, warum viele Teams heute zwar signieren, aber trotzdem nur L1 erreichen, weil die zugrunde liegende Build-Infrastruktur die höheren Stufen technisch noch nicht abdeckt.

npm hat dieses Prinzip bereits produktiv umgesetzt: Laut npm-Dokumentation führte das Registry-Team die Provenance-Funktion über das Flag –provenance im Mai 2023 ein, seit Oktober 2023 ist sie generell verfügbar (GA). Im Juli 2025 erreichte zusätzlich “Trusted Publishing” den GA-Status, wodurch Provenance-Attestierungen bei unterstützten CI/CD-Systemen wie GitHub Actions oder GitLab CI standardmäßig und ohne Zusatzaufwand erzeugt werden. Technisch nutzt npm dafür exakt die Sigstore-Infrastruktur aus Fulcio und Rekor, die auch Cosign verwendet.

Signaturen technisch erzwingen: Admission Controller in Kubernetes

Eine Signatur nützt wenig, wenn sie niemand prüft, bevor ein Image tatsächlich läuft. Genau hier setzen Admission Controller in Kubernetes an: Sie fangen jede Deployment-Anfrage ab und lehnen sie ab, wenn das referenzierte Image keine gültige Signatur oder Attestierung besitzt. Für Cosign übernimmt das häufig der Sigstore Policy Controller, ein eigenständiges Kubernetes-Admission-Webhook-Projekt, das ClusterImagePolicy-Ressourcen auswertet und dabei sowohl Keyless- als auch Key-basierte Cosign-Signaturen unterstützt. Alternativ nutzen viele Teams die generische Policy-Engine Kyverno, die sowohl Cosign- als auch Notation-Signaturen über verifyImages-Regeln prüfen kann, ohne dass ein zusätzliches Sigstore-spezifisches Projekt nötig wird.

Für Notation-Umgebungen bietet insbesondere Azure mit dem Ratify-Projekt einen vergleichbaren Mechanismus: Ratify läuft als Admission-Webhook, ruft bei jedem Deployment die Signaturprüfung gegen die konfigurierte Trust-Policy auf und blockiert unsignierte oder falsch signierte Images, bevor ein Pod überhaupt startet. Der Effekt ist in allen drei Fällen identisch: Aus einer freiwilligen Best Practice wird eine technische Kontrolle, die sich nicht mehr versehentlich umgehen lässt. Für Teams, die noch keinen Admission Controller betreiben, ist das oft der wichtigste Schritt zwischen “wir signieren Images” und “wir stellen sicher, dass wirklich nur signierte Images laufen”. Ohne diese Durchsetzungsebene bleibt jede Signaturstrategie theoretisch, weil ein Entwickler im Zweifel immer noch manuell ein unsigniertes Image deployen kann.

Benchmark-Check: Was unabhängige Vergleiche zeigen

Anders als bei Virenscannern oder Datenbanken gibt es für Cosign, Notation und GPG keine öffentlich belastbaren Millisekunden-Benchmarks zur Signier- oder Verifizierungsgeschwindigkeit. Weder Sigstore noch das Notary Project noch unabhängige Labore wie CNCF haben 2025 oder 2026 vergleichbare Zeitmessungen veröffentlicht, und dieser Artikel erfindet an dieser Stelle keine Zahlen. Was jedoch existiert, sind drei unabhängige, aktuelle Funktions- und Eignungsvergleiche, die zu einem konsistenten Bild kommen.

Quelle	Datum	Kernaussage zu Cosign	Kernaussage zu Notation
secure-pipelines.com, “Container Signing Tools Compared”	13. März 2026	Keyless Signing, exzellente CI/CD-Integration in GitHub Actions, GitLab CI, Tekton	Kein Keyless Signing, dafür reife KMS-/HSM-Plug-in-Architektur
oneuptime.com, “Cosign vs Notation for Container Image Signing”	11. August 2026	Empfohlen bei identitätsbasierten Signaturen und öffentlichem Transparenzprotokoll	Empfohlen bei Enterprise-PKI und internen Zertifizierungsstellen
Snyk-Blog, “Signing container images: Comparing Sigstore, Notary, and Docker Content Trust”	2025/2026	Sigstore als moderner, community-getriebener Ansatz mit wachsender Registry-Unterstützung	Notary als reifer, PKI-basierter Standard mit Cloud-Anbieter-Rückhalt

Alle drei Quellen kommen unabhängig voneinander zum selben Schluss: Notary (Notation) eignet sich für Enterprises mit gewachsener PKI, Cosign für Open-Source-Projekte und Teams, die auf Identität statt auf Zertifikatsverwaltung setzen wollen. Keine der drei Quellen bewertet GPG als konkurrenzfähig für Container-Signaturen im großen Maßstab, alle drei nennen es höchstens als Ausgangspunkt oder Vergleichsgröße.

Der Grund für das Fehlen harter Zeitmessungen liegt im Testaufbau selbst: Signier- und Verifizierungszeit hängen stark von Netzwerklatenz zur Zertifizierungsstelle, von der Größe des Images und davon ab, ob ein Cache für Zertifikate oder Trust-Material greift. Ein Labortest mit einem kleinen Testimage über eine schnelle Verbindung liefert andere Werte als ein Produktionslauf mit einem mehrere Gigabyte großen Image über eine ausgelastete Unternehmensleitung. Seriöse Anbieter verzichten deshalb bislang eher auf plakative Zahlen, als eine Methodik zu veröffentlichen, die im Alltag kaum reproduzierbar wäre. Für die eigene Entscheidung heißt das: Ein kurzer interner Testlauf mit den eigenen typischen Image-Größen und der eigenen Netzwerktopologie liefert belastbarere Zahlen als jeder generische Blogpost.

Kosten im Vergleich: Was Signieren wirklich kostet

Cosign, Notation und GPG sind alle drei quelloffen und kosten als Software nichts. Die eigentlichen Kosten entstehen bei der Infrastruktur drumherum, also bei Schlüsselverwaltung, Zertifizierungsstelle und gegebenenfalls einem privaten Sigstore-Betrieb. Die folgende Tabelle zeigt reale, öffentlich dokumentierte Preise verwandter Dienste, die in Kombination mit Notation oder Cosign genutzt werden.

Lösung	Modell	Kosten	Inkludierte Signaturen
Cosign + öffentliche Sigstore-Instanz	“Public Good”-Dienst	0 $	Unbegrenzt, ohne SLA
Cosign + private Sigstore-Instanz	Selbst gehostet (Fulcio/Rekor)	Nur Infrastrukturkosten, keine Lizenzgebühr	Abhängig von eigener Kapazität
Notation (Open Source)	Software allein	0 $	Unbegrenzt
Notation / Cosign + AWS KMS	Schlüsselverwaltung	Ab 12 $/Jahr Schlüssel-Speicherung	20.000 Signaturen/Monat inklusive, danach 0,15 $ je 10.000
Notation / Cosign + Azure Trusted Signing Basic	Managed Signing	9,99 $/Monat	5.000 Signaturen, danach 0,005 $ je Signatur
Notation / Cosign + Azure Trusted Signing Premium	Managed Signing	99,99 $/Monat	100.000 Signaturen, danach 0,005 $ je Signatur
AWS Signer	Für Lambda, ECR, EKS, IoT	Keine Zusatzkosten laut AWS-Dokumentation	Kosten entstehen nur bei zugrunde liegenden AWS-Diensten
SSL.com eSigner (klassisches Code-Signing, Referenzwert)	Zertifikat plus Kontingent	900 $ bis 6.300 $/Jahr	120 bis 12.000 Signaturen je nach Tarif

Eine Beispielrechnung für 1.000 Signaturen pro Monat verdeutlicht die Spannweite: Azure Trusted Signing kostet dafür im Basic-Tarif 9,99 Dollar, eine Kombination aus EV-Zertifikat und AWS KMS liegt bei rund 34,30 Dollar, und SSL.com eSigner mit klassischem Zertifikatsmodell kommt auf etwa 554 Dollar. Für Teams, die bereits Cosign mit der öffentlichen Sigstore-Infrastruktur nutzen, entfallen diese Kosten komplett, allerdings ohne vertraglich zugesicherte Verfügbarkeit. Wer eine private Sigstore-Instanz betreibt, zahlt effektiv nur die eigenen Server- und Betriebskosten, muss dafür aber Fulcio und Rekor selbst warten.

Der eigentliche Kostentreiber ist deshalb selten die Software selbst, sondern die Frage, wie viel Betriebsverantwortung ein Team übernehmen will. Ein kleines Team ohne dedizierte Plattform-Mannschaft fährt mit der kostenlosen öffentlichen Sigstore-Instanz meist günstiger, weil der Wartungsaufwand für Fulcio und Rekor entfällt. Ein regulierter Konzern mit eigenem Security-Team rechnet dagegen oft anders: Eine private Instanz oder ein verwalteter Dienst wie Azure Trusted Signing kostet zwar direkt Geld, spart aber Audit-Aufwand, weil Verfügbarkeit und Zugriffskontrolle vertraglich geregelt sind statt von einer geteilten, öffentlichen Infrastruktur abzuhängen.

NIS2, Cyber Resilience Act und die Signaturpflicht in der DACH-Region

Für Unternehmen in Deutschland, Österreich und der Schweiz kommt zum reinen Sicherheitsargument ein regulatorischer Zeitdruck hinzu. Der EU Cyber Resilience Act verpflichtet Hersteller vernetzter Produkte mit digitalen Elementen dazu, Nachweise über die Integrität ihrer Software-Lieferkette bereitzustellen, wie unser separater Beitrag zum Cyber Resilience Act im Detail beschreibt. Wer heute schon Cosign- oder Notation-Signaturen produktiv einsetzt, hat für diese Nachweispflicht bereits eine technische Grundlage, statt sie unter Zeitdruck nachträglich einzuführen.

Auch die NIS2-Richtlinie wirkt in dieselbe Richtung, auch wenn sie Signaturen nicht wortwörtlich vorschreibt: Betreiber kritischer und wichtiger Einrichtungen müssen Risikomanagementmaßnahmen für ihre Lieferkette nachweisen, und eine verifizierbare Build-Provenance ist dafür ein naheliegendes, prüfbares Artefakt. Für IT-Sicherheitsverantwortliche in DACH-Unternehmen lohnt sich deshalb eine pragmatische Reihenfolge: zuerst die eigene Build-Pipeline auf Cosign oder Notation umstellen, dann die Verifizierung über einen Admission Controller technisch erzwingen, und erst danach die Dokumentation für Auditoren aus den bereits vorhandenen Attestierungen ableiten. Diese Reihenfolge vermeidet doppelte Arbeit, weil dieselbe technische Infrastruktur sowohl die Sicherheits- als auch die Compliance-Anforderung bedient.

Fünf Praxisbeispiele aus 2025 und 2026

Abstrakte Architekturvergleiche überzeugen selten allein, deshalb lohnt der Blick auf konkrete Fälle, in denen Signaturen bereits produktiv im Einsatz sind oder ihr Fehlen sichtbar zum Problem wurde. Wer die eigene Lieferkette absichern will, findet dazu auch in unserem Vergleich Syft, Trivy und cdxgen für SBOM-Erstellung ergänzende Werkzeuge.

Homebrew (Mai 2024): Der populäre Paketmanager für macOS und Linux stellte laut Sigstore-Blog auf Sigstore-signierte In-toto-Attestierungen um, einer der ersten großen Paketmanager mit dieser Umstellung. Nutzer profitieren davon indirekt, weil jede über Homebrew installierte Formel künftig einen nachvollziehbaren Build-Ursprung besitzt.
PyPI (November 2024): Der offizielle Python Package Index folgte wenige Monate später mit derselben Sigstore-basierten Attestierungs-Infrastruktur und schloss sich damit einer wachsenden Gruppe großer Registries an, die Provenance nicht mehr optional behandeln.
Maven Central (Januar 2025): Auch das zentrale Java-Repository integrierte laut Sigstore-Blog Sigstore-signierte Attestierungen für veröffentlichte Artefakte, was für die Java- und JVM-Welt mit ihrer traditionell sehr tiefen Abhängigkeitsbäumen besonders relevant ist.
NVIDIA NGC (Juli 2025): NVIDIA nutzt die gleiche Infrastruktur inzwischen für das Signieren von KI-Modellen im NGC-Katalog, ein Hinweis darauf, dass sich Sigstore-Signaturen über klassische Software hinaus auf ML-Artefakte und Modellgewichte ausweiten, wo Manipulation besonders schwer zu erkennen wäre.
npm Trusted Publishing (Juli 2025): Mit dem GA-Status von Trusted Publishing erzeugt npm Provenance-Attestierungen für unterstützte CI/CD-Pipelines automatisch und ohne Zusatzaufwand für Maintainer, wie die offizielle npm-Dokumentation beschreibt. Das Modell ist bewusst opt-out statt opt-in gestaltet, damit Provenance zum Normalfall wird statt zur Ausnahme.

Ein sechstes, negatives Beispiel zeigt, was ohne konsequente Signaturprüfung passiert: Beim zweiten Shai-Hulud-Angriff im November 2025 kompromittierten Angreifer laut Invicti und The Hacker News zwischen 600 und 800 npm-Pakete und infizierten mehr als 25.000 GitHub-Repositories. Betroffen waren nach Angaben von Invicti unter anderem Zapier, PostHog und Postman. Der Angriffsmechanismus lief über die Preinstall-Phase von npm-Paketen und registrierte infizierte Maschinen selbstständig als neue GitHub-Actions-Runner, wodurch sich der Wurm ohne menschliches Zutun weiterverbreitete. Hätten mehr Projekte konsequent auf verifizierte Provenance-Attestierungen bestanden, wäre die Ausbreitung deutlich schwerer gewesen.

Migrationsleitfaden: In acht Schritten zu signierten Artefakten

Der Umstieg von unsignierten oder GPG-signierten Artefakten auf Cosign oder Notation lässt sich in überschaubaren Schritten planen. Der folgende Ablauf eignet sich für Teams, die bereits eine CI/CD-Pipeline mit GitHub Actions, GitLab CI oder einem vergleichbaren System betreiben. Wer die Build-Umgebung dabei gleich absichert, findet passende Schritte in unserer Anleitung Docker Container absichern.

Bestandsaufnahme: Welche Images, Binaries und Pakete werden aktuell unsigniert oder nur mit GPG veröffentlicht?
Zielmodell festlegen: Keyless mit Cosign für offene, cloud-native Projekte oder PKI-basiert mit Notation für Enterprise-Umgebungen mit bestehender CA.
Testumgebung aufsetzen und Cosign beziehungsweise Notation lokal installieren, um die Werkzeuge kennenzulernen.
Für Cosign: OIDC-Anbindung an die CI/CD-Plattform einrichten, damit Fulcio Identitäten korrekt verifizieren kann.
Für Notation: Trust-Store und Trust-Policy definieren, passende Zertifizierungsstelle und Signing-Plug-in (etwa für AWS KMS oder Azure Key Vault) konfigurieren.
Signierschritt in die Build-Pipeline integrieren, direkt nach dem Image-Build und vor dem Push in die Registry.
Verifizierung als Pflichtschritt im Deployment einbauen, etwa über eine Admission-Policy in Kubernetes, die unsignierte Images blockiert.
Schrittweise Migration bestehender Images: parallel weiterhin GPG-Signaturen ausliefern, bis alle Konsumenten auf Cosign- oder Notation-Verifizierung umgestellt sind, danach GPG-Pfad abschalten.

Ein Beispiel für den Signierbefehl mit Cosign im Keyless-Modus:

cosign sign registry.example.com/team/app:1.4.0
cosign verify registry.example.com/team/app:1.4.0 \
  --certificate-identity-regexp "https://github.com/team/app/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Der äquivalente Ablauf mit Notation nutzt stattdessen ein lokal oder über KMS verwaltetes Zertifikat:

notation sign registry.example.com/team/app:1.4.0 \
  --key mycert
notation verify registry.example.com/team/app:1.4.0

Beide Befehle lassen sich unmittelbar in bestehende GitHub-Actions- oder GitLab-CI-Jobs einbetten. Der eigentliche Aufwand liegt weniger im Aufruf selbst als in der sauberen Verifizierungs-Policy auf der Empfängerseite. Wer zusätzlich die Abhängigkeiten selbst im Blick behalten will, kann das mit unserem Vergleich Dependency-Track, FOSSA und Mend ergänzen.

Ein häufiger Stolperstein bei der Migration ist die Reihenfolge der letzten beiden Schritte: Teams aktivieren oft die Signaturprüfung im Deployment, bevor wirklich alle produktiven Images tatsächlich signiert sind, was zu überraschenden Ausfällen führt. Sinnvoller ist ein Rollout im Audit-Modus, bei dem der Admission Controller unsignierte Images zunächst nur protokolliert statt blockiert. Erst wenn die Protokolle über einen definierten Zeitraum keine unsignierten Deployments mehr zeigen, wird die Policy auf “erzwingen” umgestellt. Dieser zweistufige Ansatz verhindert, dass ein übersehenes Legacy-System an einem Freitagnachmittag den gesamten Cluster lahmlegt.

Use Cases: Welches Tool für welches Szenario passt

Die Wahl zwischen Cosign, Notation und GPG hängt stark vom konkreten Einsatzszenario ab, von der vorhandenen Infrastruktur und davon, wie viel Kontrolle ein Team über seine Build-Pipeline hat. Sechs typische Fälle aus der Praxis zeigen, wie die Entscheidung in der Regel ausfällt und warum.

Open-Source-Projekt mit öffentlicher Registry: Cosign mit der öffentlichen Sigstore-Instanz, da keine eigene PKI nötig ist und Nutzer die Herkunft über Rekor nachvollziehen können.
Enterprise mit interner Zertifizierungsstelle: Notation, weil sich Trust-Policies direkt an bestehende PKI-Prozesse und Compliance-Vorgaben anschließen lassen.
Team auf Azure Kubernetes Service oder Amazon EKS: Notation, entsprechend der offiziellen Empfehlung von Microsoft und Amazon für die jeweilige Plattform.
Team mit SLSA-Level-2- oder -3-Anspruch: Cosign, wegen der nativen In-toto- und Provenance-Unterstützung, die für höhere SLSA-Level praktisch vorausgesetzt wird.
Reines Signieren von Git-Commits und -Tags ohne Container-Bezug: GPG bleibt hier eine solide, etablierte Wahl, da es dafür entwickelt wurde und breite Tool-Unterstützung bietet.
Regulierte Branche mit Auditpflicht (Finanzsektor, KRITIS): Eine Kombination aus Notation für PKI-Compliance und Cosign für zusätzliche Transparenzprotokollierung deckt beide Anforderungen gleichzeitig ab. Regulatorischen Druck in diese Richtung erzeugt unter anderem der Cyber Resilience Act der EU.

Vor- und Nachteile im direkten Vergleich

Kein Werkzeug gewinnt in jeder Kategorie, und genau das macht die Entscheidung schwerer als ein reiner Feature-Vergleich. Wer die folgende Gegenüberstellung liest, sollte sie deshalb weniger als Ranking verstehen und mehr als Checkliste gegen das eigene Einsatzszenario.

Cosign, Vorteile: Keyless Signing ohne langlebige Schlüssel, öffentliches Transparenzprotokoll Rekor, native SLSA-/In-toto-Unterstützung, breite CI/CD-Integration.
Cosign, Nachteile: Keyless-Modell erfordert Umdenken bei Teams, die an klassische PKI gewöhnt sind, öffentliche Sigstore-Instanz ohne vertragliche SLA.
Notation, Vorteile: Fügt sich in bestehende Enterprise-PKI ein, von Microsoft und Amazon offiziell empfohlen, reife Plug-in-Architektur für KMS und HSM.
Notation, Nachteile: Kein Keyless Signing, SLSA-/In-toto-Unterstützung nur über zusätzliche Plug-ins, Verantwortung für Zertifikatslebenszyklus bleibt beim eigenen Team.
GPG, Vorteile: Etabliert, breite Werkzeugunterstützung für Commit-Signaturen, keine Abhängigkeit von externer Infrastruktur.
GPG, Nachteile: Keine native OCI-Registry-Integration, kein Transparenzprotokoll, manuelle Schlüsselverwaltung, ungeeignet für moderne Container-Pipelines im großen Maßstab.

Das Urteil: Cosign, Notation oder beides einsetzen

Für die meisten Teams, die neu in Container- und Artefaktsignaturen einsteigen, ist Cosign der pragmatischere Startpunkt. Keyless Signing eliminiert das klassische Schlüsselverwaltungsproblem komplett, die Integration in GitHub Actions und GitLab CI ist laut mehreren unabhängigen Vergleichen ausgereift, und die native SLSA-Unterstützung zahlt direkt auf höhere Provenance-Level ein. Die Adoption durch Homebrew, PyPI, Maven Central und npm selbst zeigt, dass sich dieser Ansatz im Open-Source-Ökosystem durchgesetzt hat.

Wer dagegen in einer Enterprise-Umgebung mit gewachsener interner Zertifizierungsstelle arbeitet, insbesondere auf AKS oder EKS, sollte Notation nicht vorschnell verwerfen. Die Empfehlung der beiden großen Cloud-Anbieter für ihre jeweiligen Kubernetes-Dienste ist kein Zufall, sondern spiegelt wider, dass sich Notation ohne Bruch in bestehende Governance- und Audit-Prozesse einfügt. GPG bleibt für Commit-Signaturen relevant, sollte für Container-Images 2026 aber nicht mehr die erste Wahl sein. Ein aktueller Scanner-Vergleich wie Trivy vs. Snyk zeigt zusätzlich, wie sich Signaturprüfung und Schwachstellenscans sinnvoll ergänzen.

Bei der Budgetplanung lohnt sich außerdem ein Blick über die reinen Signaturkosten hinaus. Die eigentliche Investition liegt nicht im Werkzeug selbst, sondern im Aufbau der Verifizierungs-Policy, im Admission Controller und in der Schulung des Teams, damit fehlgeschlagene Verifizierungen nicht einfach übergangen werden. Ein Unternehmen, das 9,99 Dollar im Monat für Azure Trusted Signing zahlt, aber keine Policy zur Durchsetzung betreibt, hat am Ende weniger Sicherheit gewonnen als ein Team, das die kostenlose öffentliche Sigstore-Instanz nutzt und diese konsequent über einen Admission Controller erzwingt.

Die realistischste Antwort für viele Organisationen lautet ohnehin: beides. Da Cosign und Notation dieselben OCI-Registry-Mechanismen nutzen und parallel auf einem Image koexistieren können, spricht nichts dagegen, Cosign für Transparenzprotokollierung und SLSA-Nachweise einzusetzen und gleichzeitig eine Notation-Signatur für interne PKI-Compliance zu ergänzen. Angesichts der Shai-Hulud-Zahlen aus 2025 und 2026, mit über 796 kompromittierten Paketen und mehr als 20 Millionen betroffenen wöchentlichen Downloads laut Cloud Security Alliance, ist die Frage ohnehin nicht mehr, ob signiert wird, sondern nur noch, mit welchem Werkzeug.

Häufige Fragen zu Cosign, Notation und Container-Signaturen

Kann ich Cosign und Notation gleichzeitig auf demselben Image verwenden?
Ja. Beide Werkzeuge speichern ihre Signaturen als separate, digest-gebundene OCI-Artefakte in der Registry. Ein Image kann parallel eine Cosign- und eine Notation-Signatur tragen, ohne dass sich beide gegenseitig stören.

Ist Keyless Signing mit Cosign wirklich sicherer als ein klassischer privater Schlüssel?
Es verschiebt das Risiko, statt es vollständig zu eliminieren. Ein gestohlener OIDC-Token einer CI/CD-Pipeline kann für die kurze Gültigkeitsdauer des ausgestellten Zertifikats missbraucht werden, danach verfällt er automatisch. Ein klassischer privater Schlüssel bleibt dagegen gefährlich, bis er aktiv widerrufen wird.

Muss ich für Cosign zwingend die öffentliche Sigstore-Infrastruktur nutzen?
Nein. Unternehmen können eine private Sigstore-Instanz mit eigenem Fulcio und Rekor betreiben und behalten damit die volle Kontrolle über die Zertifizierungsstelle und das Transparenzprotokoll, tragen dafür aber auch den Betriebsaufwand selbst.

Warum empfehlen Microsoft und Amazon Notation statt Cosign?
Beide Cloud-Anbieter betreiben mit AKS und EKS verwaltete Kubernetes-Dienste, die eng an Enterprise-PKI-Strukturen angebunden sind. Notation passt zu diesem Modell besser, weil es auf X.509-Trust-Stores statt auf identitätsbasiertes Keyless Signing setzt. Das schließt Cosign auf denselben Plattformen nicht aus, es ist aber nicht die offizielle Standardempfehlung.

Ersetzt eine Signatur eine Schwachstellenprüfung meiner Container-Images?
Nein. Eine Signatur bestätigt Herkunft und Unverändertheit eines Artefakts, sagt aber nichts über bekannte Sicherheitslücken in den enthaltenen Paketen aus. Signaturen und Schwachstellenscanner ergänzen sich, ersetzen sich aber nicht gegenseitig.

Was hat der Shai-Hulud-Wurm mit Container-Signaturen zu tun?
Shai-Hulud griff primär das npm-Ökosystem an, nicht Container-Registries direkt. Er zeigt aber exemplarisch, wie sich kompromittierter Code ohne verifizierte Herkunftsnachweise ungebremst über Abhängigkeitsketten verbreitet, ein Risiko, das für Container-Images grundsätzlich genauso gilt.

Welches Werkzeug eignet sich für ein kleines Team ohne eigene PKI?
Cosign mit der öffentlichen Sigstore-Instanz ist für kleine Teams der niedrigschwelligste Einstieg, da keine eigene Zertifizierungsstelle aufgebaut werden muss und die Grundfunktionen kostenlos nutzbar sind.

Ist GPG für Container-Signaturen komplett veraltet?
Für Git-Commits und -Tags bleibt GPG eine gängige und funktionierende Wahl. Für Container-Images fehlt jedoch die native Registry-Integration und ein Transparenzprotokoll, weshalb Cosign oder Notation dort inzwischen die technisch passendere Lösung sind.

Wie erzwinge ich, dass in Kubernetes nur signierte Images laufen?
Dafür braucht es einen Admission Controller, der jede Deployment-Anfrage prüft, etwa den Sigstore Policy Controller oder Kyverno für Cosign-Signaturen, oder das Ratify-Projekt für Notation-Signaturen in Azure-Umgebungen. Ohne einen solchen technischen Erzwingungsmechanismus bleibt jede Signaturpflicht eine reine Empfehlung.

Hilft eine Signatur gegen einen Wurm wie Shai-Hulud direkt?
Eine verifizierte Provenance-Attestierung hätte die automatische Weiterverbreitung erschwert, weil ein manipuliertes Paket ohne gültige Signatur einer Build-Pipeline von einem strikt konfigurierten Verifizierungsschritt abgelehnt worden wäre. Vollständigen Schutz bietet das nicht, da auch legitime Zugänge kompromittiert werden können, aber es erhöht die Hürde für automatisierte Ausbreitung erheblich.

Cosign vs. Notation vs. GPG: 796 Pakete gehackt [2026]