Die CISA 2026 SBOM Minimum Elements sind da. Compliance ist einer von vier Tests.
| Interlynk
Die CISA 2026 Minimum Elements heben die Basislinie an, doch Compliance allein macht eine SBOM nicht nutzbar. Die vier Tests, die SBOM-Qualität bestimmen.
SBOM-Compliance, Qualität und Mindestanforderungen
Im Juli 2026 haben CISA und ihre Partnerbehörden die 2026 Minimum Elements for a Software Bill of Materials veröffentlicht und damit die NTIA-Basislinie ersetzt, die die Kategorie seit 2021 geprägt hatte. Die neue Fassung ergänzt mehrere Felder, die die frühere Basislinie nicht enthielt, darunter Komponenten-Hashes, Lizenzinformationen, den Namen des Tools, das die SBOM erzeugt hat, und den Kontext, in dem sie erstellt wurde. Außerdem aktualisiert sie mehrere Felder, damit die Daten maschinell leichter zu verarbeiten sind. [1]
Das ist ein bedeutender Fortschritt. Und es wird leicht missverstanden.
Immer wenn eine neue Reihe von Minimum Elements erscheint, neigt die Branche dazu, sie als Definition dafür zu behandeln, wie eine „gute" SBOM aussieht. Teams prüfen, ob die erforderlichen Felder vorhanden sind, bestätigen, dass das Dokument die Validierung besteht, und machen weiter.
Genau hier beginnt das Problem.
Eine Liste von Minimum Elements beantwortet eine Frage: Erfüllt diese SBOM ein bestimmtes Rahmenwerk? Compliance ist wichtig. Sie ist etwas anderes als Qualität, und sie ist kein universelles Ziel. Verschiedene Teams, Branchen und Regulierungsbehörden erwarten unterschiedliche Informationen aus derselben SBOM.
Eine SBOM muss vier Filter bestehen
Statt zu fragen, ob eine SBOM einfach „gut" ist, hilft die Frage, was sie leisten soll. In der Praxis muss eine verlässliche SBOM vier unabhängige Tests bestehen, und jeder kann auf andere Weise scheitern.
Filter | Die Frage, die er beantwortet |
|---|---|
Genauigkeit | Bilden die Daten die Software korrekt ab, die Sie tatsächlich ausgeliefert haben? |
Vollständigkeit | Enthält die SBOM genug der richtigen Informationen für ihren Verwendungszweck? |
Struktur | Entspricht sie der SPDX- oder CycloneDX-Spezifikation, die sie angibt zu verwenden? |
Compliance | Erfüllt sie die Anforderungen des konkreten regulatorischen oder organisatorischen Rahmenwerks, das für Sie gilt? |
Diese Filter sind voneinander unabhängig. Eine SBOM kann strukturell einwandfrei sein und trotzdem die falsche Software beschreiben. Sie kann die CISA-2026-Basislinie erfüllen und trotzdem die Informationen vermissen lassen, die Ihr Team für die Schwachstellenreaktion braucht. Sie kann intern genau und nützlich sein und dennoch hinter dem zurückbleiben, was eine Regulierungsbehörde verlangt.
Deshalb sind „wir erzeugen SBOMs" und „wir erzeugen SBOMs, auf die wir uns verlassen können" sehr unterschiedliche Aussagen.
1: Genauigkeit
Genauigkeit ist der Filter, den die meisten Teams als gegeben annehmen, und einer der am seltensten geprüften.
Eine SBOM ist eine Sammlung von Aussagen: Diese Komponenten sind vorhanden, dies sind ihre Versionen, dies sind ihre Identifikatoren. Sind diese Aussagen falsch, ist jeder darauf aufbauende Prozess kompromittiert. Bessere Formatierung kann fehlerhafte Daten nicht korrigieren.
Die Probleme sind oft subtil. Ein Scan auf Quellcode-Ebene meldet vielleicht eine Bibliothek, die der finale Build nie einbindet. Eine Version wird abgeschnitten oder geschätzt. Ein Komponentenname wird dem falschen Paket zugeordnet, weil derselbe Name in mehreren Ökosystemen vorkommt. Das entstehende Dokument kann verbindlich wirken, die Schemavalidierung bestehen und trotzdem eine openssl-Version auflisten, die im Produkt gar nicht enthalten ist.
Wenn die nächste OpenSSL-Schwachstelle bekannt wird, kann diese eine falsche Zeile Ihr Team dazu bringen, ein Release zu untersuchen, das nie betroffen war. Schlimmer noch, sie kann dazu führen, ein Release abzutun, das betroffen war.
Genauigkeit lässt sich nicht beurteilen, indem man die fertige SBOM isoliert betrachtet. Sie muss daran geprüft werden, wie die Software tatsächlich gebaut wurde, was die Erzeugungsmethode ebenso wichtig macht wie das Dateiformat.
Eine SBOM aus dem falschen Build-Kontext ist keine etwas schwächere Fassung der richtigen SBOM. Sie ist eine selbstbewusste Beschreibung von Software, die Sie nicht ausgeliefert haben.
2: Vollständigkeit
Das Wort „vollständig" klingt absolut, doch SBOM-Vollständigkeit ist immer an einen Zweck gebunden. Dasselbe Dokument kann für einen Workflow vollständig und für einen anderen erheblich unzureichend sein.
Nehmen Sie zwei Teams, die mit derselben SBOM arbeiten. Ein Software-Compliance-Team braucht möglicherweise Lizenzausdrücke, Copyright-Angaben und Quellorte für jede Komponente, um die rechtliche Prüfung abzuschließen und Attributionspflichten zu erfüllen. Ein Produktsicherheits-Team legt mehr Wert auf präzise Versionen und maschinell auflösbare Identifikatoren wie purl und CPE, damit seine Tools Komponenten mit bekannten Schwachstellen abgleichen können.
Eine SBOM kann umfangreiche Lizenzinformationen und kaum brauchbare purls enthalten. Das macht sie für das Compliance-Team wertvoll und für einen Incident Responder nahezu nutzlos. Der umgekehrte Fall ist genauso häufig.
Die nützliche Frage lautet nicht „Ist diese SBOM vollständig?". Sie lautet „Ist diese SBOM vollständig für die Aufgabe, die wir mit ihr erledigen müssen?".
Reife SBOM-Programme definieren Vollständigkeit pro Anwendungsfall und Build-Pfad. Ein Container-Release braucht vielleicht Anwendungsabhängigkeiten, Base-Image-Pakete und die Beziehungen dazwischen. Ein Lizenz-Workflow verlangt möglicherweise einen gültigen SPDX-Ausdruck für jede Komponente, bevor das Release ausgeliefert werden darf. Vollständigkeit ist eine bewusste Entscheidung pro Anwendungsfall, kein einzelnes Häkchen, das eine SBOM entweder setzt oder verfehlt.
3: Gültigkeit
Strukturelle Gültigkeit ist der engste der vier Filter und meist der am einfachsten zu automatisierende. Die Frage ist eindeutig: Entspricht das Dokument der SPDX- oder CycloneDX-Spezifikation, die es angibt zu verwenden? Dazu gehören die richtigen Felder, die korrekten Datentypen und die Validierung gegen das relevante Schema.
Das SPDX-Projekt stellt Online-Validierungstools, Bibliotheken und Build-Integrationen bereit, um programmatisch mit SBOM-Dokumenten zu arbeiten. [2]
Dieser Filter ist unverzichtbar. Eine fehlerhafte SBOM lässt sich nicht zuverlässig einlesen, vergleichen, signieren, speichern oder scannen. Strukturelle Gültigkeit ist ein Fundament, und sie ist kein Qualitätswert.
Ein Schemavalidator kann bestätigen, dass ein Dokument korrekt aufgebaut ist. Er kann nicht sagen, ob die Komponentenliste genau ist, ob das Dokument genug Informationen für Ihren Workflow enthält oder ob es die Anforderungen der für Sie zuständigen Regulierungsbehörde erfüllt.
Ein Validator, der nur die Struktur prüft, gibt ein grünes Licht, das weit weniger bedeutet, als es scheint. Struktur ist der Filter, den ein Tool sofort beantworten kann, und genau deshalb wird er so oft für das Ganze gehalten. Wenn Sie zwischen den beiden dominierenden Formaten wählen, zeigt unser Leitfaden CycloneDX vs SPDX, wo jedes seinen Platz hat.
4: Compliance
Hier ordnet sich die CISA-2026-Veröffentlichung ein, und hier entsteht das größte Missverständnis.
Compliance ist keine Eigenschaft, die eine SBOM abstrakt besitzt. Eine SBOM ist konform mit einem bestimmten Rahmenwerk, und diese Rahmenwerke verlangen nicht alle dieselben Informationen.
Die CISA 2026 Minimum Elements sind jetzt die allgemeine bundesweite Basislinie in den USA. Sektorspezifische Regulierungsbehörden und andere Jurisdiktionen ergänzen eigene Anforderungen, und einige gehen bewusst deutlich weiter. Eine SBOM kann ein Rahmenwerk erfüllen und ein anderes verfehlen, und viele Organisationen müssen mehrere gleichzeitig erfüllen.
Rahmenwerk | Baut auf | Wesentliche zusätzliche Anforderungen | Für wen es gilt |
|---|---|---|---|
NTIA Minimum Elements (2021) | Der ursprünglichen Basislinie | Lieferant, Komponentenname und -version, eindeutige Identifikatoren, Abhängigkeiten, SBOM-Autor und Zeitstempel | Die Referenz-Basislinie, die spätere Rahmenwerke erweitern |
CISA Minimum Elements (2026) | Ersetzt die NTIA-Basislinie von 2021 | Komponenten-Hashes, Komponentenlizenzen, Name des Erzeugungstools, Erzeugungskontext und für Automatisierung umbenannte Felder | Die aktuelle allgemeine bundesweite Basislinie (USA) |
FDA Section 524B | NTIA Minimum Elements und maschinenlesbaren SBOM-Erwartungen | Support-Status je Komponente, End-of-Support-Datum, bekannte Schwachstellen und zunehmend eine VEX-Datei | Premarket-Einreichungen für Medizinprodukte |
BSI TR-03183 | Geht weit über NTIA hinaus | Maschinell verwertbare Ersteller-Kontakte, SHA-256-Hashes für Executable und Quellcode, rekursiv aufgelöste Abhängigkeiten, SPDX-Lizenz-Identifikatoren, Quell- und Executable-URIs sowie purls oder CPEs | Produkte, die unter Deutschlands CRA-nahe Vorgaben fallen |
Die Tabelle ist eine nützliche Warnung davor, „konform" so zu verwenden, als wäre es eine einzige Kategorie.
FDA-Anforderungen bauen weiterhin auf den NTIA-Elementen von 2021 auf und ergänzen Informationen, die die CISA-2026-Basislinie nicht ausdrücklich behandelt. Bei einem Medizinprodukt kann es wichtig sein, ob eine Komponente aktiv gepflegt, nicht mehr gepflegt oder aufgegeben ist und ob sie eine bekannte ausgenutzte Schwachstelle aufweist. Diese Erwartungen behandeln wir in FDA-SBOM-Anforderungen für Medizinprodukte. [3]
BSI TR-03183 geht an anderer Stelle weiter und verlangt kryptografische Hashes und auflösbare Artefakt-URIs, die eine automatisierte Lieferketten-Verifikation unter Europas sich entwickelnden Vorgaben unterstützen. Unser Leitfaden zu SBOM-Anforderungen für die CRA schlüsselt die TR-03183-Felder im Detail auf. [4]
Eine SBOM, die die CISA-2026-Basislinie erfüllen soll, kann trotzdem von einem FDA-Prüfer abgelehnt werden oder hinter TR-03183 zurückbleiben.
Warum „CISA-2026-konform" Sie trotzdem exponiert lassen kann
Zusammen betrachtet zeigen die vier Filter die Grenze jeder Minimum-Elements-Liste.
Die CISA-2026-Anforderungen zu erfüllen bedeutet, dass die SBOM den Compliance-Test für ein Rahmenwerk bestanden hat. Es sagt nichts darüber aus, ob die Komponenten korrekt identifiziert sind, ob das Dokument die Daten enthält, die Ihr Schwachstellen-Workflow braucht, oder ob es FDA- oder BSI-Anforderungen erfüllt, die ebenfalls für Ihr Produkt gelten können.
Nichts davon ist eine Kritik an den 2026 Minimum Elements. Eine Basislinie soll einen Boden setzen und den Standard in der Branche anheben, und diese tut das, besonders durch die Ergänzung von Lizenz- und Hash-Daten und durch Felder, die sich besser automatisiert verarbeiten lassen.
Der Fehler ist, den Boden für die Decke zu halten. Compliance ist notwendig. Für sich genommen ist sie weder ausreichend noch universell.
Wie Sie alle vier Filter kontinuierlich messen
Diese Filter erfordern keine vier getrennten Programme. Sie erfordern einen Workflow, der jede Dimension misst und bei jedem Build läuft, so nah wie möglich an der Stelle, an der die SBOM erzeugt wird.
Das Open-Source-Tool sbomqs von Interlynk bewertet eine SBOM über gewichtete Dimensionen, die eng mit diesen vier Filtern zusammenhängen. Struktur- und Schemaprüfungen adressieren die Struktur. Prüfungen zu Identifikation, Vollständigkeit, Provenance, Integrität und Lizenzierung helfen, Genauigkeit und anwendungsfallbezogene Vollständigkeit zu bewerten. Prüfungen zur Schwachstellen-Bereitschaft bestätigen, dass die purls und CPEs, auf die Ihre Scanner angewiesen sind, vorhanden sind, bevor Sie sich auf die Ergebnisse verlassen. Ein eigener Compliance-Modus validiert gegen ein benanntes Rahmenwerk statt gegen eine allgemeine Vorstellung davon, was eine „gute" SBOM enthalten sollte. [5]
Ein einfaches CI-Qualitätsgate kann so klein sein:
Der richtige Schwellenwert hängt vom Risiko und Zweck des Releases ab. Setzen Sie ihn höher, je näher das Release an die Produktion und an eine Regulierungsbehörde rückt, und bestätigen Sie die genauen Punktebänder anhand der aktuellen sbomqs-Dokumentation, bevor Sie darauf gaten. [5]
Qualitätsbewertung funktioniert am besten zusammen mit rahmenwerkspezifischer Validierung. Ein Medizinprodukte-Build sollte gegen FDA-Erwartungen geprüft werden. Ein Produkt unter deutscher CRA-Vorgabe sollte gegen TR-03183 geprüft werden. Keines sollte an einer Einheitsliste gemessen werden.
Filter | Frage, die er beantwortet | Beispielkontrolle |
|---|---|---|
Genauigkeit | Sind die Daten wahr zu dem, was wir ausgeliefert haben? | Erzeugen Sie die SBOM aus dem echten Build-Kontext und bewerten Sie Identifikation und Integrität. |
Vollständigkeit für den Anwendungsfall | Enthält sie, was dieser Workflow braucht? | Verlangen Sie purls und CPEs für Schwachstellenarbeit und Lizenzausdrücke für Compliance-Arbeit. |
Struktur | Können Maschinen sie lesen und verarbeiten? | Validieren Sie das angegebene CycloneDX- oder SPDX-Dokument gegen sein Schema. |
Compliance | Enthält sie die Felder, die unser Rahmenwerk verlangt? | Führen Sie das benannte Profil für NTIA, CISA 2026, FDA, BSI TR-03183 oder einen anderen geltenden Standard aus. |
Der Ansatz, der langfristig trägt, ist es, auf allen vier Filtern zu gaten und die Ergebnisse für jeden Build aufzubewahren. So lässt sich ein Qualitätsabfall erkennen, bevor ein Prüfer oder ein Sicherheitsvorfall ihn zuerst findet.
Fazit
Die CISA 2026 Minimum Elements sind eine willkommene Verbesserung der SBOM-Basislinie, und Organisationen sollten sie ernst nehmen. Die Basislinie ist ein Ausgangspunkt und kein Ziel.
Eine Minimum-Elements-Liste ist eine Compliance-Prüfung gegen ein Rahmenwerk. Compliance ist einer von vier Filtern, die entscheiden, ob eine SBOM wirklich nützlich ist.
Die SBOMs, auf die Teams sich verlassen können, bestehen alle vier Tests. Sie bilden die ausgelieferte Software korrekt ab. Sie enthalten die Informationen für die jeweilige Aufgabe. Sie sind strukturell gültig, sodass Maschinen sie verarbeiten können. Und sie erfüllen die Anforderungen des Rahmenwerks, das für das Release gilt, ob das CISA 2026, FDA Section 524B, BSI TR-03183 oder mehrere gleichzeitig sind.
Wer nur Compliance misst, kann weiter SBOMs produzieren, die eine Checkliste bestehen und in dem Moment scheitern, in dem jemand sie tatsächlich nutzen muss.
Möchten Sie sehen, wie Ihre SBOMs über alle vier Filter abschneiden? Prüfen Sie eine mit sbomqs, dem Open-Source-Toolkit von Interlynk, und validieren Sie sie gegen das Rahmenwerk, das für Ihr Produkt gilt, bevor die SBOM in die Produktion oder zu einer Regulierungsbehörde gelangt.
Interlynk gibt Sicherheits- und Compliance-Teams SBOMs, auf die sie sich verlassen können: aus dem echten Build erzeugt, bei jedem Build auf Qualität bewertet, gegen das geltende Rahmenwerk validiert und kontinuierlich über den Lebenszyklus überwacht. Erzeugen Sie in CycloneDX oder SPDX und beantworten Sie die Expositionsfrage in Minuten. Demo buchen · Kostenlos starten. Vertraut von Sicherheits- und Compliance-Teams in über 100 regulierten Unternehmen.
Referenzen
CISA und Partnerbehörden, 2026 Minimum Elements for a Software Bill of Materials: https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
SPDX-Projekt, Tools und Bibliotheken: https://spdx.dev/use/tools/
Interlynk, FDA-SBOM-Anforderungen für Medizinprodukte: https://www.interlynk.io/de/ressourcen/fda-sbom-anforderungen-medizinprodukte
Interlynk, SBOM-Anforderungen für die CRA (BSI TR-03183): https://www.interlynk.io/de/ressourcen/sbom-anforderungen-cra
Interlynk, sbomqs: https://github.com/interlynk-io/sbomqs