Jede Version ein Paket.

Jede Komponente wird als Container-Image nach der Image Specification der Open Container Initiative (OCI) gebaut: ein Manifest, das auf eine Konfiguration und eine geordnete Liste von Schichten verweist. Jede Schicht ist ein komprimiertes Dateiarchiv, die Konfiguration nennt Einstiegspunkt, Umgebung und Plattform. Für mehrere Prozessorarchitekturen fasst ein Image Index die Manifeste je Plattform zusammen.

Images liegen in einer Registry und werden über deren Schnittstelle nach der OCI Distribution Specification übertragen. Dieselbe Schnittstelle trägt auch Anlagen zu einem Image, etwa Signaturen und Stücklisten, die über einen Verweis auf das Image an ihm hängen.

Jedes Teil eines Images wird über seinen Digest angesprochen: sha256: gefolgt vom Prüfwert seines Inhalts. Das Manifest nennt die Digests von Konfiguration und Schichten, und der Digest des Manifests umfasst damit das ganze Image. Wer ein Image über seinen Digest bezieht, bekommt genau diese Bytes oder einen Fehler.

Bezeichnungen wie latest oder eine Versionsnummer sind veränderliche Namen, die auf einen Digest zeigen; morgen kann derselbe Name auf etwas anderes zeigen. HERMES verteilt darum Digests. In Freigaben, Rollouts und im Verlauf steht immer der Digest, die Bezeichnung nur zum Lesen daneben.

Zu jedem Image gehört eine Software-Stückliste (SBOM): jede enthaltene Komponente mit Name, Version, Lizenz und Paketkennung nach dem Schema Package URL. HERMES erzeugt sie beim Bau, im Format SPDX oder CycloneDX.

Mit der Stückliste lässt sich für eine neu bekannt gewordene Schwachstelle sofort beantworten, in welchen Versionen die betroffene Komponente steckt und an welchen Orten diese Versionen laufen. Die Verordnung (EU) 2024/2847 über Cyberresilienz verlangt von Herstellern für Produkte mit digitalen Elementen ab dem 11. Dezember 2027 eine solche Stückliste, mindestens für die Abhängigkeiten der obersten Ebene.

Die Stückliste liegt nicht lose neben dem Image. Sie wird als signierte Anlage, eine Attestation nach in-toto, über den Digest an das Image gebunden.

HERMES signiert jedes Image und jede Anlage. Mit Sigstore cosign entsteht eine Signatur über den Digest des Manifests, die in der Registry neben dem Image liegt. Signiert werden kann mit einem festen Schlüsselpaar oder schlüssellos: Dann bescheinigt die Zertifizierungsstelle Fulcio für kurze Zeit die Identität des Bauprozesses, und die Signatur wird in das öffentliche Transparenzprotokoll Rekor eingetragen.

Für Umgebungen ohne Verbindung nach außen ist das feste Schlüsselpaar vorgesehen, weil die Prüfung dort ohne Zugang zu Fulcio und Rekor einfacher auskommt. Der Bauprozess erzeugt zusätzlich eine Herkunftsangabe nach SLSA: welche Quelle, welcher Commit, welche Bauumgebung, welche Schritte.

Ein Bau ist reproduzierbar, wenn derselbe Quellstand in derselben Umgebung bitgleich dasselbe Ergebnis liefert. Dafür werden Zeitstempel in den Archiven fest gesetzt (SOURCE_DATE_EPOCH), Abhängigkeiten über Prüfwerte gepinnt, die Reihenfolge von Dateien sortiert und die Bauumgebung selbst als Image mit Digest festgelegt.

Dann kann eine zweite, unabhängige Stelle denselben Stand bauen und den Digest vergleichen. Stimmt er, ist belegt, dass das Paket aus diesem Quellstand und dieser Bauumgebung entsteht; der Bauumgebung muss man trauen oder sie ebenso prüfen.

Bevor ein Ort ein Paket startet, prüft er Signatur, Digest und Herkunftsangabe gegen eine Regel: welche Schlüssel oder Identitäten signieren dürfen, welche Quellen und Bauumgebungen erlaubt sind. In Kubernetes übernimmt das ein Admission Controller, etwa der Policy Controller von Sigstore oder Kyverno, der ein Image ohne gültige Signatur gar nicht erst starten lässt.

Die Regel selbst ist versioniert und kommt auf demselben Weg an den Ort wie das Soll. Eine Ausnahme für ein einzelnes Image steht darum als Änderung im Repository, mit Begründung, und nicht als Schalter, den jemand am Ort umlegt.