Zusammenfassung

  • RFC 9943 ermöglicht den begrenzten Nachweis, dass ein Transparenzdienst eine signierte Erklärung nach einer bestimmten Policy registriert und einen überprüfbaren Receipt ausgegeben hat. Das ist kein Freigabebeschluss für das Artefakt.
  • Welche Aussteller, Schlüssel und Regeln gelten und wer einen Rollout zulässt, anhält oder korrigiert, bestimmt weiterhin die Organisation, die den Schaden tragen und beheben kann.

Ein sauberer Nachweis ist noch keine Betriebsentscheidung

Die Aussage „für dieses Paket liegt ein Transparenz-Receipt vor“ wirkt beruhigend, weil sie nach Abschluss klingt. RFC 9943 setzt an einer engeren Stelle an. Die im Juni 2026 als IETF-Standards-Track-RFC veröffentlichte Architektur macht signierte Aussagen über digitale Lieferkettenartefakte transparent. Sie bestimmt nicht, wer einen Produktionsrelease genehmigt.

Ein Aussteller kann beispielsweise eine SBOM, eine Sicherheitsmeldung, eine Lebenszyklusinformation, ein Gutachten oder eine andere serialisierbare Aussage über ein Artefakt signieren. Ein Transparency Service, kurz TS, kann diese Aussage registrieren. Registrierung bedeutet nach dem RFC: Einreichung der Signed Statement, Anwendung der Registration Policy des TS, Aufnahme in eine Verifiable Data Structure und Erzeugung eines Receipts. Damit kann ein Prüfer Eigenschaften dieser Struktur verifizieren, etwa die Aufnahme der Erklärung.

Das ist nützlich. Eine nachprüfbare, nur fortschreibbare Historie erschwert stilles Löschen oder Umarbeiten. Sie hilft, Aussagen eines Ausstellers über die Zeit zu prüfen und bei geeigneter Struktur Konsistenz nachzuvollziehen. Ein Einschlussnachweis ist aber weder ein vollständiges Sicherheitsurteil noch ein Kompatibilitätstest, keine Beschaffungsfreigabe und kein Mandat zum Betrieb. Das Protokoll macht eine Aussage sichtbar; es übernimmt nicht die Haftung für ihre Verwendung.

Vier getrennte Tatsachen

Erstens hat ein Aussteller eine Aussage signiert. Eine gültige Signatur bindet Inhalt und Metadaten an einen Schlüssel. Sie beweist nicht automatisch, dass dieser Aussteller der vom Empfänger erwartete ist, dass er für diese Aussage zuständig war oder dass die Aussage zutrifft.

Zweitens hat ein bestimmter TS registriert. Seine Registration Policy ist eine Vorbedingung, die auf nicht opaken Header-Informationen und Metadaten des COSE-Envelopes beruht. Sie kann anspruchsvoll oder bewusst schmal sein. Das Registrierungsergebnis sagt deshalb nur, welche Prüfung dieser Dienst nach dieser Policy vorgenommen hat. Es ersetzt keine weiteren Prüfungen, die ein Betreiber, Kunde oder Regulierter für seinen Zweck benötigt.

Drittens hat eine Relying Party einen für sie akzeptablen Receipt geprüft. RFC 9943 verlangt, dass sie mindestens dem Verifikationsschlüssel oder Zertifikat und der zugehörigen Identität eines Receipt-Ausstellers vertraut. Sie darf einen Receipt genügen lassen und nach der Prüfung beliebige eigene Validierungsregeln anwenden. Ein Receipt enthält also keine weltweit gültige Annahmeregel. Die Relying Party bestimmt, welchem Dienst, welchem Schlüssel, welchem Aussteller, welchem Beweisprofil und welcher Aktualität sie vertraut.

Viertens trifft eine zuständige Stelle eine Betriebsentscheidung. Release-Verantwortliche können zulassen, Security kann zurückhalten, Beschaffung kann für einen eng definierten Vertrag akzeptieren, Betrieb kann die laufende Version behalten und die nächste ablehnen. Diese Handlungen haben unterschiedliche Zuständigkeiten, Schäden und Korrekturwege. Ein gültig kodierter Receipt handelt nicht an ihrer Stelle.

Die Unterscheidung ist nicht akademisch. Eine registrierte Aussage kann von einem lokal nicht akzeptierten Aussteller stammen. Ein Receipt kann korrekt verifizieren und eine lokale Regel kann die Auslieferung wegen einer neuen Exposition, Lizenzlage, Inkompatibilität oder auslaufenden Ausnahme dennoch verhindern. Eine Notfalländerung kann eine enge, zeitlich befristete Ausnahme brauchen. Gerade dann müssen Autorität, Frist und nachträgliche Prüfung gesondert festgehalten werden.

Policy, Schlüssel und Zeit gehören zusammen

Der RFC lässt zu, dass der Betreiber eines TS Registration Policy oder Vertrauensanker aktualisiert. Zugleich muss der Dienst genügend Material bereitstellen, damit Auditoren die nach der Policy zum Registrierungszeitpunkt verlangten Prüfungen nachvollziehen können. Die richtige Frage lautet daher nicht nur: „Ist die Receipt-Signatur gültig?“ Sie lautet auch: Welcher Dienst, welche Policy-Version, welcher Schlüssel, welche Erklärung und welcher Zeitpunkt erzeugten dieses Ergebnis?

Das verbietet keinen Policy-Wechsel. Schlüsselwechsel, strengere Zulassung und neue Profile können sinnvoll sein. Es verhindert nur, dass die heutige Policy unbemerkt die Bedeutung einer früheren Registrierung umschreibt oder ein alter Receipt als gegenwärtige Release-Policy eines Unternehmens ausgegeben wird.

Auch die Reihenfolge im Log trägt keine vollständige Geschichte. Eine VDS kann eine Reihenfolge registrierter Aussagen führen. RFC 9943 sagt jedoch ausdrücklich, dass daraus nicht auf die Ausstellungsreihenfolge geschlossen werden darf, sofern die Registration Policy diese Eigenschaft nicht ankündigt. Eine Log-Position beweist weder, dass ein Fix vor einer Warnung kam, noch dass ein Entscheider die Evidenz vor seiner Freigabe gesehen hat. Dafür sind eigene Zeitangaben und Verantwortliche nötig.

Transparenz entscheidet zudem nicht über Wahrheit. Aussteller können bewusst oder unbeabsichtigt falsche Aussagen machen; eine Aussage kann später ersetzt werden, mehrere Aussteller können widersprechende Aussagen über dasselbe Artefakt abgeben. Die Architektur macht diese Geschichte prüfbar. Sie setzt keinen universellen Schiedsrichter für ihren Inhalt ein.

Häufig fehlt das Protokoll der Freigabe

Oft sind Artefakt-Hash, Attestation, Receipt und ein Policy-Name vorhanden. Die maßgebliche Handlung — warum diese Version durchgelassen wurde — bleibt in einem Chat, hinter einem Konsolenknopf oder in einer nicht zuordenbaren Notfallfreigabe. Nach einem Problem lässt sich dann zeigen, dass etwas registriert war, nicht aber, wer mit welcher Grundlage den Einsatz erlaubte.

Ein vom SCITT getrennter Release-Entscheidungsbeleg kann diese Lücke schließen. Für jede erhebliche Zulassung, Zurückhaltung, Ablehnung oder Ausnahme sollte er die unveränderliche Artefaktversion, Aussage und Aussteller, den TS, Policy-Version und Registrierungszeit, Prüfresultat und erneuten Prüfzeitpunkt, lokale Regel oder Ausnahme, entscheidungsbefugte Stelle, Ergebnis, Ablauf- oder Überprüfungsauslöser sowie Korrektur-, Rollback- oder Einspruchsweg verbinden.

Das ist keine neue Forderung aus RFC 9943. Gerade deshalb wird ein Standard nicht fälschlich zum unternehmensinternen Freigabegremium gemacht. Testdetails, Kundendaten und ausnutzbare Informationen können geschützt bleiben. Ein befugter Prüfer muss dennoch nachvollziehen können, welche Evidenz zu welcher Entscheidung führte und wie sie korrigiert werden kann.

Automatisierung verschiebt diese Grenze nicht. Eine Pipeline kann einen Receipt prüfen und eine zuvor gewählte Regel ausführen. Der Beleg sollte dann die Regelversion, die sie verabschiedende Autorität, die ausgewerteten Eingaben und das Ergebnis nennen. „Das Log hat es erlaubt“ verdeckt, dass eine Person oder Institution die Regel zuvor in eine automatische Entscheidung übersetzt hat.

Evidenzstandard, nicht Risikoregierung

RFC 9943 lässt Verwaltung und Speicherung der Aussagen sowie Auffinden und Benachrichtigung der Beteiligten über Änderungen außerhalb seines Geltungsbereichs. Diese Zurückhaltung ist sinnvoll. Hersteller, Krankenhaus, öffentliche Stelle und ehrenamtliches Projekt können denselben Receipt prüfen, ohne einen identischen Risikoauftrag vorzutäuschen.

Problematisch wird es, wenn eine technische Eigenschaft eine institutionelle Wahl verdeckt. Beschaffung erklärt die Sorgfalt für beendet, weil eine Erklärung registriert ist. Ein Delivery-Team setzt Einschlussnachweis mit Risiko-Freigabe gleich. Betrieb erklärt eine Aussteller-Signatur auch nach neuer Information für ausreichend. Jedes Mal trägt eine wahre, begrenzte Tatsache eine Entscheidung, die niemand zugeordnet hat.

Die robustere Reihenfolge ist schlicht: den Nachweis nur für die Eigenschaft prüfen, die er zeigt; Policy und Zeitpunkt mitbewahren; und festhalten, wer über seine Verwendung entschieden hat. Dann lassen sich kryptographischer Defekt und Governance-Defekt getrennt finden.

Quellen

  1. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains
  2. IETF Datatracker: RFC 9943
  3. RFC 9942: CBOR Object Signing and Encryption (COSE) Receipts
  4. RFC 9162: Certificate Transparency Version 2.0
  5. RFC 9052: CBOR Object Signing and Encryption (COSE): Structures and Process