Eine Software-Stückliste ist noch kein Kryptoinventar

Ausgabe 09 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für IT-Revision, Enterprise-Architektur und alle, die von Lieferanten Software-Stücklisten anfordern.

Die Software-Stückliste des Lieferanten ist vorbildlich: 412 Komponenten, maschinenlesbar, mit Versionen und Lizenzen. Darin steht auch: OpenSSL 3.5. Die Revision hakt ab: „Post-Quanten-fähige Bibliothek vorhanden.“ Ob die Anwendung damit jemals einen Post-Quanten-Schlüsselaustausch aushandelt, steht nirgends. Die Stückliste kann es auch nicht wissen.

Worum es geht: warum eine Software-Stückliste (SBOM) nicht sagt, welche Algorithmen und Protokolle tatsächlich verwendet werden, und was ein Kryptoinventar (CBOM) zusätzlich enthalten muss. Was dieser Beitrag nicht behandelt: die Auswahl konkreter Werkzeuge und den Aufbau einer PKI (Ausgabe 10).

In diesem Beitrag: Was eine SBOM sagt und was nicht · Vorhanden ist nicht verwendet · Was eine CBOM beschreibt · Wer was liefern kann · Beispiel · Was sich ändert · Fünf Prüffragen · Vier Wege zum Kryptoinventar · Die Frage an Ihren Lieferanten · Anhang: CBOM-Datenmodell

Eine Software-Stückliste listet, woraus eine Software besteht: Bibliotheken, Module, Versionen, Herkunft, Lizenzen. Sie ist das wichtigste Werkzeug, um nach einer neuen Schwachstelle in Stunden statt Wochen zu wissen, wo man betroffen ist. Mit dem Cyber Resilience Act wird sie für Hersteller von Produkten mit digitalen Elementen ab Dezember 2027 zur Pflicht: Sie müssen die enthaltenen Komponenten dokumentieren, unter anderem in Form einer Software-Stückliste.

Was eine SBOM nicht sagt:

• welche Algorithmen eine Bibliothek in dieser Anwendung tatsächlich verwendet;
• welche Parameter gelten: Schlüssellängen, Kurven, Parametersätze;
• welche Protokolle mit welchen Einstellungen laufen: TLS-Gruppen, IKEv2-Transformationen, SSH-Verfahren;
• welche Zertifikate und Schlüssel existieren, wer sie ausgestellt hat und wann sie ablaufen;
• wo Kryptografie selbst geschrieben ist, statt aus einer Bibliothek zu kommen.

Für das Schwachstellenmanagement reicht die Stückliste. Für die Post-Quanten-Umstellung fehlt genau das, worauf es ankommt.

Der häufigste Fehlschluss aus einer SBOM lautet: Die Bibliothek kann Post-Quanten-Verfahren, also nutzt die Software sie. Drei Beispiele, warum das nicht stimmt:

• OpenSSL 3.5, veröffentlicht im April 2025, unterstützt ML-KEM, ML-DSA und SLH-DSA und bietet in der Standardkonfiguration für TLS den hybriden Schlüsselaustausch X25519MLKEM768 an. Eine Anwendung, die eigene, fest eingestellte Gruppen setzt, oder ein Gegenüber, das nur klassische Gruppen anbietet, handelt trotzdem klassisch aus.
• Java enthält seit Version 24 (März 2025) Schnittstellen für ML-KEM und ML-DSA. Eine Anwendung, die weiter RSA aufruft, verwendet RSA.
• Eine Bibliothek kann im Paket stecken und gar nicht aufgerufen werden. Eine SBOM listet, was ausgeliefert wird, nicht, was zur Laufzeit läuft.

Eine SBOM beschreibt also Fähigkeiten. Für die Umstellung brauchen Sie Tatsachen: was eingestellt ist, was aufgerufen wird, was ausgehandelt wird.

Eine Cryptography Bill of Materials (CBOM) erweitert die Stückliste um kryptografische Bestandteile. Der Standard CycloneDX unterstützt sie seit Version 1.6 (2024, standardisiert als ECMA-424); Version 1.7 vom Oktober 2025 hat die Beschreibung erweitert. Die EU-Roadmap vom Juni 2025 empfiehlt für Kryptoinventare ausdrücklich ein standardisiertes Format wie CBOM.

Eine CBOM kennt im Kern vier Arten von Einträgen:

• Algorithmen mit Funktion (Signatur, Schlüsselvereinbarung, Verschlüsselung, Hash), Parametersatz und Einschätzung des Sicherheitsniveaus, auch gegenüber Quantenangriffen;
• Zertifikate mit Aussteller, Inhaber, Laufzeit und dem Signaturalgorithmus;
• Protokolle mit Version und den konfigurierten Verfahren, etwa TLS-Cipher-Suites oder Gruppen;
• zugehöriges Schlüsselmaterial mit Art, Größe, Zustand, Ablageort und Lebensdauer.

Entscheidend sind die Beziehungen: Welche Komponente implementiert welchen Algorithmus, welches Protokoll nutzt welche Verfahren, welches Zertifikat gehört zu welchem Dienst. Erst dadurch wird aus einer Liste ein Inventar, mit dem sich planen lässt.

Daraus folgt eine unbequeme Tatsache: Kein einzelner Beteiligter kann eine vollständige CBOM liefern. Ein Hersteller kennt den Code, aber nicht Ihre Konfiguration. Ihr Betrieb kennt die Konfiguration, aber nicht den Code. Ein Kryptoinventar entsteht immer aus mehreren Quellen, und der Auftraggeber muss sie zusammenführen.

Für Lieferantenanforderungen heißt das: Verlangen Sie vom Hersteller die Angaben, die nur er hat (Komponenten, aufgerufene Algorithmen, Konfigurierbarkeit). Verlangen Sie nicht, dass er Ihre Umgebung beschreibt.

Angenommen, die interne Revision eines Armaturenherstellers in Baden-Württemberg prüft drei Anwendungen, die Daten mit Lieferanten austauschen. Für alle drei liegen Software-Stücklisten vor.

Die erste Zeile zeigt, dass eine moderne Bibliothek nichts nützt, wenn der Lastverteiler davor klassisch arbeitet. Die zweite zeigt, dass Post-Quanten-Fähigkeit vom Gegenüber abhängt: Mit zwei Lieferanten läuft hybrid, mit vierzig klassisch. Die dritte zeigt, wofür eine SBOM gar nicht taugt: für Dienste, die Sie nur nutzen. Hier hilft nur Messung und Nachfrage.

• Revision prüft Tatsachen, nicht Fähigkeiten. Eine Bibliothek mit Post-Quanten-Unterstützung ist eine gute Voraussetzung, kein Prüfergebnis.
• Beschaffung fragt nach CBOM-Bestandteilen, nicht nach CBOM-Vollständigkeit. Vom Hersteller: aufgerufene Algorithmen, Konfigurierbarkeit, geplante Versionen. Vom Betrieb: Konfiguration und Messung.
• SBOM und CBOM gehören zusammen. Wer ohnehin SBOMs aufbaut, sollte das Format so wählen, dass kryptografische Angaben später ergänzt werden können. CycloneDX erlaubt beides in einer Datei.
• Messung wird Routine. Was ausgehandelt wird, ändert sich mit jeder Gegenstelle. Eine einmalige Messung ist eine Momentaufnahme.

Für eine Revision, die ein Kryptoinventar prüft statt einer Stückliste, eignen sich fünf Fragen:

1. Woher stammt jede Angabe? Gemessen, konfiguriert, dokumentiert oder vom Hersteller zugesagt? Ein Inventar ohne Quellenangabe lässt sich nicht bewerten.
2. Wie alt ist sie? Eine Messung vom Vorjahr beschreibt die Gegenstellen des Vorjahres.
3. Sind die Beziehungen erfasst? Ein Algorithmus ohne zugehörigen Dienst und ohne Zuständigen ist eine Zeile, aber keine Planungsgrundlage.
4. Sind Lücken als Lücken markiert? „Unbekannt“ ist ein ehrlicher Befund. Eine geschätzte Angabe, die wie eine gemessene aussieht, ist eine Revisionsfeststellung wert.
5. Gibt es einen Prozess, der das Inventar aktuell hält? Ein Inventar, das nur für die Prüfung entstanden ist, ist bei der nächsten Prüfung veraltet.

Die fünfte Frage ist die wichtigste. Sie entscheidet, ob das Inventar ein Werkzeug der Umstellung wird oder ein Dokument für die Ablage. Von denen gibt es bekanntlich genug.

1. Code- und Binäranalyse zeigt, welche Algorithmen aufgerufen werden. Werkzeuge dafür gibt es als freie und kommerzielle Software; sie liefern Kandidaten, die geprüft werden müssen.
2. Konfigurationsauswertung zeigt, was eingestellt ist: TLS-Gruppen, VPN-Profile, SSH-Verfahren.
3. Netzbeobachtung zeigt, was tatsächlich ausgehandelt wird, und mit wem.
4. Zertifikats- und Schlüsselverwaltung zeigt, was existiert, wo es liegt und wann es abläuft.

Beginnen Sie dort, wo die Schutzdauer hoch ist (Ausgabe 02) und Lieferanten beteiligt sind (Ausgabe 03). Das Register aus Ausgabe 04 ist der Startpunkt; eine CBOM ist seine maschinenlesbare, verknüpfte Form.

„Können Sie uns zusätzlich zur SBOM angeben, welche kryptografischen Algorithmen Ihr Produkt tatsächlich aufruft, welche davon konfigurierbar sind und in welcher Version sich das ändert, nach Möglichkeit im CycloneDX-Format?“

Die Frage ist präzise genug, um eine prüfbare Antwort zu bekommen, und offen genug, um nichts zu verlangen, was der Lieferant nicht wissen kann.

Die slowenische Ausgabe beschreibt die praktische Erhebung aus Sicht der Entwicklungsteams beim Lieferanten: »Imate SBOM? Še vedno morda ne veste, katero kriptografijo uporabljate.« (auf Slowenisch). Vorherige Ausgabe: Quantensichere Lieferketten beginnen nicht mit Vertragsstrafen.

Ein vereinfachtes Datenmodell, angelehnt an CycloneDX 1.6/1.7. Es zeigt, welche Angaben ein Kryptoinventar braucht; die genauen Feldnamen regelt die Spezifikation. In der slowenischen Ausgabe inhaltlich gleich.

Beispiel eines Eintrags (vereinfacht, zur Illustration):

{
  "type": "cryptographic-asset",
  "name": "TLS Lieferantenportal",
  "cryptoProperties": {
    "assetType": "protocol",
    "protocolProperties": {
      "type": "tls",
      "version": "1.3"
    }
  },
  "properties": [
    { "name": "gemessen.gruppe", "value": "x25519" },
    { "name": "konfiguriert.gruppen", "value": "x25519, secp256r1" },
    { "name": "änderbar.durch", "value": "IT-Dienstleister (Lastverteiler)" },
    { "name": "stand", "value": "2026-02-20" }
  ]
}

Lesehilfe: Die Felder unter properties sind eigene Ergänzungen für Planung und Zuständigkeit. CycloneDX erlaubt solche Eigenschaften; für den Austausch mit Lieferanten sollten beide Seiten die Namen vorher abstimmen.

Alle erschienenen Ausgaben der Reihe: Übersicht „Post-Quanten-Sicherheit in der Lieferkette“

Nächste Ausgabe (6. 4. 2026): „Ihre Zertifikate laufen ab. Ihre Vertrauensarchitektur bleibt.“

Quellen (Stand 2. 3. 2026): CycloneDX Specification 1.6 (ECMA-424, 1. Ausgabe Juni 2024) und 1.7 (Oktober 2025); OpenSSL 3.5 Release Notes (April 2025); JEP 496 und 497 (JDK 24, März 2025); Verordnung (EU) 2024/2847, Anhang I Teil II; NIS Cooperation Group, „A Coordinated Implementation Roadmap …“, Version 1.1, Abschnitt 6.2.

Wenn Ihre Stücklisten vollständig sind und Sie trotzdem nicht wissen, was ausgehandelt wird: Schreiben Sie uns.