Signieren von Abhängigkeiten und Artefakten

Ein SBOM zeigt Ihnen, was in einem Artefakt enthalten ist. Die Provenienz zeigt Ihnen, woher es stammt und wie es erstellt wurde. Durch die Signatur wird ein Artefakt an eine überprüfbare Herkunft gebunden, sodass Verbraucher alles ablehnen können, was nicht von Ihrer vertrauenswürdigen Pipeline erzeugt wurde.

Ohne Provenienz ist ein Angreifer, der einen Tarball in Ihrer Registry austauscht, nicht von einer legitimen Veröffentlichung zu unterscheiden.

Die Grundlage der Integrität ist die inhaltsbasierte Adressierung. Ein kryptografischer Hash (Digest) eines Artefakts identifiziert diese exakte Bytefolge eindeutig. Veränderliche Tags wie latest können auf einen anderen Inhalt verweisen; ein Digest kann das nicht.

Eine digitale Signatur verwendet einen privaten Schlüssel, um den Hash des Artefakts zu signieren; jeder, der über den zugehörigen öffentlichen Schlüssel verfügt, kann die Signatur verifizieren. Das bietet zwei Garantien:

• Integrität — Das Artefakt wurde nach der Signierung nicht verändert
• Authentizität — Es wurde vom Inhaber des privaten Schlüssels signiert

Die Schwierigkeit liegt nicht in der Mathematik, sondern in der Schlüsselverwaltung und Vertrauensverteilung: Wie weiß ein Prüfer, welchem öffentlichen Schlüssel er vertrauen kann?

Traditionelle Signaturen zwingen Teams dazu, langlebige private Schlüssel zu schützen, die leicht in falsche Hände geraten. Sigstore bietet schlüsselloses Signieren: Es stellt ein kurzlebiges Zertifikat aus, das an eine OIDC-Identität gebunden ist (etwa eine CI-Workload oder eine Entwickler-E-Mail-Adresse), signiert und das Ereignis in einem öffentlichen Transparenzprotokoll namens Rekor festhält.

Es gibt keinen langlebigen Schlüssel, den man stehlen könnte, und jede Signatur kann öffentlich geprüft werden.

Cosign ist das Sigstore-Tool zum Signieren von Container-Images und anderen Artefakten. Im schlüssellosen Modus verwendet es das OIDC-Token der Pipeline, sodass keine Schlüsseldatei auf dem Datenträger liegt.

Sigstore hält jedes Signierungsereignis in Rekor fest, einem manipulationsnachweisbaren, nur erweiterbaren öffentlichen Protokoll. Dies ist eine wirkungsvolle Maßnahme zur Aufdeckung:

• Sie können nachweisen, wann etwas signiert wurde
• Ein Angreifer, der eine Identität stiehlt, kann nicht heimlich signieren — das Ereignis wird öffentlich protokolliert
• Anomale Signaturen (unerwartete Identität, außerhalb der Arbeitszeit) werden erkennbar

Transparenz macht aus einer unbemerkten Kompromittierung einen beobachtbaren Beleg.

SLSA (Supply-chain Levels for Software Artifacts) ist ein Framework, das bewertet, wie vertrauenswürdig Ihr Build-Prozess ist. Höhere Stufen verlangen stärkere Garantien gegen Manipulation.

• L1 — Provenienz ist vorhanden und dokumentiert
• L2 — signierte Provenienz von einem gehosteten Build-Dienst
• L3 — gehärtete, isolierte Builds; die Provenienz ist selbst für einen Insider der Pipeline nicht fälschbar

SLSA ist ein Fahrplan: Wählen Sie eine Zielstufe und schließen Sie die Lücken.

Eine Provenienzattestierung ist eine signierte Erklärung, die beschreibt, wie ein Artefakt erstellt wurde: den Quell-Commit, die Identität des Builders, die Build-Parameter und die Eingaben. Das Format in-toto standardisiert diese Angaben.

Signieren ist nur dann nützlich, wenn etwas unsignierte Artefakte ablehnt. In Kubernetes kann ein Admission Controller jedes Image blockieren, dem eine gültige Signatur und Provenienz Ihrer vertrauenswürdigen Identität fehlen.

• Policy-Controller verifizieren Cosign-Signaturen, bevor ein Pod gestartet wird
• Images ablehnen, die von unerwarteten Identitäten signiert wurden
• Eine Provenienz verlangen, die auf Ihr freigegebenes Quell-Repository verweist

Damit schließt sich der Kreis: Nicht vertrauenswürdige Artefakte werden nie ausgeführt.

Provenienz ist am wertvollsten, wenn sie sich auch auf das erstreckt, was Sie beziehen, und nicht nur auf das, was Sie ausliefern. Ökosysteme ergänzen zunehmend native Signierung und Provenienz:

• npm provenance verknüpft ein veröffentlichtes Paket mit seinem Quell-Commit und CI-Lauf
• Container-Basis-Images werden zunehmend mit Cosign-Signaturen ausgeliefert
• Sprach-Registries erproben die von Sigstore unterstützte Verifizierung

Bevorzugen Sie Abhängigkeiten, die eine überprüfbare Provenienz veröffentlichen, und verifizieren Sie diese bei der Installation, sofern dies unterstützt wird.

Eine praktische Signaturstrategie ist mehrschichtig und wird durchgängig verifiziert:

• Eingaben anhand ihres Digests festschreiben
• Artefakte schlüssellos signieren und SBOM sowie Provenienzattestierungen anhängen
• Alles in einem Transparenzprotokoll festhalten
• Die Verifizierung bei der Bereitstellung mit einer Admission-Richtlinie erzwingen

Die Kette ist nur so stark wie ihr schwächstes nicht verifiziertes Glied. Verifizieren Sie daher an jeder Stelle der Nutzung.

Analysieren Sie, warum schlüsselloses Signieren die Sicherheit der Software-Lieferkette verbessert.

Sie haben gelernt, Provenienz nachzuweisen und durchzusetzen.

• Nach Digest festschreiben, nicht nach veränderlichen Tags
• Digitale Signaturen bieten Integrität und Authentizität; die Herausforderung ist die Schlüsselverwaltung
• Sigstore + cosign ermöglichen schlüsselloses Signieren mit dem öffentlichen Rekor-Transparenzprotokoll
• SLSA bewertet die Build-Integrität; Provenienzattestierungen halten fest, wie Artefakte erstellt wurden
• Admission-Richtlinien lehnen bei der Bereitstellung alles Uns signierte oder nicht Vertrauenswürdige ab

Als Nächstes: die Härtung der CI/CD-Pipeline, die diese Artefakte erzeugt.