Ein Container-Image lässt sich in Sekunden aus einer Registry ziehen und in Produktion starten. Genau diese Bequemlichkeit ist die Kehrseite: Wenn unklar bleibt, wer ein Image gebaut hat, was genau drinsteckt und ob es unterwegs verändert wurde, entsteht ein Risiko in der Software-Lieferkette. Klassische Sicherheitsmaßnahmen wie Schwachstellenscans helfen, beantworten aber nicht die Herkunftsfrage.
Abhilfe schaffen kryptografische Signaturen und überprüfbare Metadaten direkt am Image. In der Open-Source-Welt hat sich dafür ein Werkzeug-Stack etabliert, der sich an vorhandene OCI-Registries andocken lässt. Ein zentraler Baustein ist Cosign: Es signiert Container-Images, speichert Signaturen neben dem Artefakt in der Registry und ermöglicht saubere Verifikation in CI/CD und Laufzeitumgebungen.
Warum Signaturen für Container-Images im Alltag zählen
Integrität, Herkunft und Verantwortlichkeit trennen
In vielen Teams wird „sicher“ mit „keine bekannten CVEs“ gleichgesetzt. Das greift zu kurz. Ein Image kann frei von bekannten Schwachstellen sein und trotzdem unerwünschte Änderungen enthalten. Signaturen adressieren drei Fragen, die im Betrieb regelmäßig auftauchen:
- Supply-Chain-Security: Lässt sich nachweisen, dass das Image aus dem eigenen Build-Prozess stammt?
- Integrität: Ist das Image exakt das, was signiert wurde (keine nachträgliche Manipulation in der Registry oder beim Transport)?
- Verantwortlichkeit: Welche Identität (Person, Bot, CI-Job) stand hinter dem Build?
Damit entsteht eine belastbare technische Aussage über Herkunft und Unverändertheit – unabhängig davon, ob ein Scan bereits alle Risiken kennt.
Warum Tags nicht reichen
Tags wie :latest oder :1.2 sind bewegliche Zeiger. Ein Tag kann auf ein anderes Manifest zeigen, ohne dass ein Pull-Befehl auffällig wirkt. Verifikation sollte daher auf Digests (Content-Addressing) aufsetzen und zusätzlich kryptografisch abgesichert werden.
Cosign im Kontext: Was es tut – und was nicht
Signieren und verifizieren entlang der OCI-Kette
Cosign arbeitet mit OCI-Images und den dazugehörigen Manifesten. Praktisch bedeutet das: Signaturen werden nicht „irgendwo“ abgelegt, sondern in der Regel in derselben Registry gespeichert (als OCI-Artefakte). Dadurch bleibt der Prozess nah am vorhandenen Tooling (Docker/Podman, Registry, CI).
Cosign kann Images signieren und Signaturen prüfen. Zusätzlich lassen sich Attestierungen anhängen, also strukturierte Aussagen über den Build (z. B. verwendete Quellen, Build-Umgebung, Build-Parameter). Für viele Organisationen ist das der entscheidende Schritt von „wir scannen“ hin zu „wir können unsere Artefakte beweisbar zuordnen“.
Keine automatische Sicherheitsgarantie
Eine Signatur beweist nicht, dass der Inhalt gutartig ist. Sie beweist, dass ein bestimmter Schlüssel oder eine bestimmte Identität das Artefakt signiert hat. Der eigentliche Sicherheitsgewinn entsteht durch Regeln: Welche Identitäten dürfen signieren? Welche Artefakte werden in Produktion zugelassen? Welche Attestierungen sind Pflicht?
Schlüssel, Identitäten und Vertrauensmodelle wählen
Schlüsselverwaltung: lokal, zentral oder „keyless“
Im Kern braucht Signierung einen privaten Schlüssel. In der Praxis gibt es mehrere Wege, die sich in Aufwand und Governance unterscheiden:
- Lokale Schlüssel: schnell startklar, aber riskant bei Teamwechseln und schwer zu auditieren.
- Zentral verwaltete Schlüssel (z. B. in einem Secrets-Manager oder HSM): besser kontrollierbar, dafür mehr Infrastruktur.
- Sigstore-basierte, schlüsselarme Modelle: Signaturen können an kurzlebige Identitäten (z. B. CI-OIDC) gekoppelt werden; entscheidend sind dann Identitäts- und Policy-Regeln.
Für Unternehmen ist weniger die Technik als die Frage relevant, wer im Zweifel den Zugriff auf Signierschlüssel entziehen kann und wie sich Rotation, Offboarding und Incident Response abbilden lassen.
Policies: „Wer darf nach Prod?“ sauber formulieren
Der praktische Nutzen zeigt sich erst, wenn Verifikation erzwungen wird. Typische Policy-Ansätze:
- Nur Images aus der eigenen Registry oder aus freigegebenen Upstream-Projekten zulassen.
- Nur signierte Images zulassen; nicht signierte Artefakte werden im Deployment blockiert.
- Für kritische Workloads zusätzlich Attestierungen verlangen (z. B. „wurde in CI gebaut“, „kommt aus bestimmtem Repository“).
Wichtig ist ein stufenweiser Rollout: zunächst beobachten (Warnungen), dann in nicht-kritischen Umgebungen blockieren, erst später in Produktion hart erzwingen.
Einführung in Teams: typische Stolpersteine und Gegenmaßnahmen
Wenn die Registry „alles annimmt“
Viele Registries speichern zwar Signaturen, erzwingen aber keine Verifikation. Dadurch entsteht leicht ein falsches Sicherheitsgefühl. Die Durchsetzung muss in den Auslieferpfad: CI/CD-Gates, Admission Controller in Kubernetes oder zumindest Deploy-Skripte, die nur verifizierte Digests akzeptieren.
Build-Pipelines reproduzierbar machen
Signaturen sind am stärksten, wenn Builds stabil und nachvollziehbar sind. Häufige Ursachen für „Signiert, aber nicht nachvollziehbar“:
- Builds ziehen bei jedem Lauf neue Abhängigkeiten ohne Locking.
- Base-Images werden über Tags referenziert statt über Digests.
- Build-Schritte passieren auf Entwicklerlaptops statt in CI.
Schon einfache Regeln helfen: Base-Images pinnen, Abhängigkeiten versionieren, Build in CI standardisieren und Artefakte nur über Digests deployen.
Open Source in der Organisation: Zuständigkeiten klären
Signierung ist kein reines Dev-Thema. Für nachhaltigen Betrieb braucht es Rollen:
- Entwicklung: baut Images, definiert Mindestanforderungen für Attestierungen.
- Security/Plattformteam: definiert Policies, betreibt Schlüssel/Identitäten, setzt Verifikation durch.
- Betrieb: überwacht Ausnahmen und sorgt für Incident-taugliche Prozesse (Rotation, Sperrung, Rollback).
Hier schließt sich der Kreis zur generellen Projekt- und Tool-Bewertung im Open-Source-Umfeld: Governance, Wartung und klare Verantwortlichkeiten sind entscheidend. Ergänzend lohnt ein Blick auf SBOM & SLSA in der Software-Lieferkette sowie auf sauberes Abhängigkeitsmanagement.
So lässt sich Cosign pragmatisch einführen
Ein gangbarer Weg ohne Big-Bang
- Ein Pilot-Repository auswählen (ein Service, eine Pipeline) und den Ist-Zustand dokumentieren: Build-Schritte, Registry, Deployment-Weg.
- Images konsequent per Digest deployen und Base-Images ebenfalls per Digest pinnen.
- Signierung in CI ergänzen: nach erfolgreichem Build signieren, Signatur in der Registry ablegen.
- Verifikation zuerst in CI als Gate aktivieren (Build/Release bricht ab, wenn Verifikation fehlschlägt).
- Danach Verifikation im Cluster schrittweise erzwingen (z. B. nur in Staging, später Produktion).
- Ausnahmeprozess definieren: Wer darf temporär unsignierte Images zulassen und wie wird das auditiert?
Im Ergebnis entsteht ein überprüfbarer Pfad vom Quellcode über den Build bis zum Deployment. Das ist weniger „Tool-Einführung“ als ein Governance-Upgrade für Artefakte.
Vergleich: Signaturen, Scans, SBOM – was löst welches Problem?
Komplementäre Bausteine statt Entweder-oder
| Baustein | Stellt sicher | Typische Grenze | Praxis-Tipp |
|---|---|---|---|
| Image-Signatur (Cosign) | Herkunft & Integrität des Artefakts | Keine Aussage über „gut“ oder „frei von Schwachstellen“ | Verifikation erzwingen, nicht nur signieren |
| Vulnerability Scan | Bekannte Schwachstellen in Paketen/Layern | Unbekannte Lücken, False Positives/Negatives | Mit Policy verknüpfen: Schwellwerte & Ausnahmen |
| SBOM | Transparenz über enthaltene Komponenten | Qualität hängt von Build und Erzeugung ab | SBOM pro Build erzeugen und versionieren |
| SLSA-orientierte Build-Härtung | Nachvollziehbarer, kontrollierter Build-Prozess | Einführung braucht Prozessdisziplin | Mit kleinen Stufen starten, dann ausbauen |
Eine robuste Strategie kombiniert diese Bausteine: Signaturen für Herkunft, Scans für bekannte Risiken, SBOM für Transparenz und Prozesskontrollen für reproduzierbare Builds.
Lizenzen und Community: worauf bei Cosign & Umfeld achten
Lizenzkompatibilität ist selten das Problem, Governance schon eher
Bei Infrastruktur-Tools im Container-Ökosystem sind permissive Lizenzen verbreitet; das vereinfacht Nutzung und Integration auch in Unternehmen. In der Praxis entscheidet aber eher die Projektgesundheit: Release-Frequenz, nachvollziehbarer Issue- und PR-Prozess, klare Security-Policy und ein aktives Maintainer-Team. Wer Open-Source-Software im Kern der Lieferkette einsetzt, sollte intern festlegen, wie Updates bewertet und eingespielt werden und wie ein Wechsel (oder Fork) im Notfall abläuft. Dazu passt die Einordnung aus Open Source im Unternehmen nachhaltig bewerten.
Unternehmensrealität: Upstream, Forks und Support
Bei sicherheitskritischen Komponenten lohnt eine nüchterne Entscheidung: Reicht Upstream plus internes Know-how, oder wird kommerzieller Support benötigt? Beides kann funktionieren, solange Verantwortlichkeiten klar sind. Wichtig ist, nicht nur das Tool zu betrachten, sondern auch das angrenzende Ökosystem (Registry, CI, Kubernetes-Policy-Engine) und die Update-Kette.
Typische Fragen aus der Praxis
Wie viel Aufwand erzeugt Signierung im Tagesgeschäft?
Initial ist der Aufwand spürbar: Schlüssel/Identitäten, CI-Anpassungen, Policies. Danach ist der laufende Betrieb meist überschaubar, wenn Rotation und Offboarding standardisiert sind. Der größte Hebel ist Automatisierung in CI/CD statt manueller Signierung.
Was ist mit Third-Party-Images?
Für Upstream-Images braucht es eine Freigabe-Strategie: entweder nur signierte Upstream-Artefakte akzeptieren, oder Third-Party-Images intern spiegeln, prüfen und anschließend mit eigener Policy weiterverwenden. Entscheidend ist Konsistenz: Eine Ausnahme pro Team untergräbt den Nutzen.
Kann Verifikation Deployments blockieren?
Ja, und das ist der Sinn. Damit daraus kein Betriebsrisiko wird, braucht es einen dokumentierten Ausnahmeprozess und vorab getestete Policies. In frühen Phasen helfen „Audit“-Modi, um erst Sichtbarkeit zu gewinnen, bevor hart blockiert wird.
OCI-Registry, Container-Image-Signierung und klare Policies sind damit keine Spezialdisziplin, sondern ein realistischer Schritt, um Container als Lieferformat langfristig beherrschbar zu machen.
