Am 29. Juli 2026 veröffentlichte die CISA die „Mindestanforderungen für ein Cybersicherheitskonzept 2026“ Software Bill of Materials (SBOM)und ersetzte damit die seit 2021 geltenden NTIA-Richtlinien. Diese wurden gemeinsam mit der NSA, dem FBI und 15 internationalen Cybersicherheitsbehörden erarbeitet.
Die „2026 Minimum Elements for a Software Bill of Materials (SBOM) “ sind die aktualisierte Spezifikation der CISA hinsichtlich der Daten, die eine SBOM enthalten muss. Die folgenreichste Änderung ist dabei struktureller Natur und nicht numerischer Art: Die Elemente von 2026 verbieten zwar nicht die Erstellung von SBOMs auf Basis von Quellcode-Manifesten, verlangen jedoch von den Erstellern, anzugeben, wie die SBOM generiert wurde, einen Hash des ausführbaren Artefakts zu berechnen und jedes Feld zu kennzeichnen, das nicht ausgefüllt werden konnte. Eine ausschließlich auf Manifesten basierende SBOM legt nun ihre eigenen Lücken in maschinenlesbarer Form offen.
MetaDefender Software Supply Chain ist die Software-Supply-Chain-Sicherheitsplattform von OPSWAT, die zur Analyse von Artefakten, Binärdateien und Container-Image-Layern entwickelt wurde – genau die Datenkategorie, die nun gemäß den neuen Anforderungen an Hash-Werte, Generierungskontext und Abdeckung erforderlich ist.
Auf einen Blick
- 17 Datenfelder – 9 SBOM-Metadaten, 8 Komponentendaten
- 6 Vorgehensweisen und Prozesse
- 10 neue Felder, 8 größere Aktualisierungen, 1 Streichung („Zugriffskontrolle“, in „Vertrieb und Auslieferung“ integriert)
- Gilt für alle Software, „einschließlich Open-Source-Software, KI-Software und SaaS“
- Keine neuen Anforderungen – eine Weiterentwicklung der Art und Weise, wie Unternehmen SBOMs erstellen und anfordern
Änderungen an der SBOM für 2026, deren Umsetzung für reine Quellcode-SBOMs am schwierigsten ist
1. Der Hash-Wert der Komponente erfordert das ausführbare Artefakt
Die Begriffe „Komponenten-Hashwert“ und „Komponenten-Hash-Algorithmus“ legen genau fest, was gehasht wird: „die Ausgabe, die durch die Anwendung eines kryptografischen Hash-Algorithmus auf ein ausführbares Komponenten-Artefakt erzeugt wird.“ Nicht der Manifest-Eintrag und nicht die deklarierte Versionszeichenfolge.
- Ein Parser, der die Dateien „package-lock.json“, „pom.xml“ oder „requirements.txt“ ausliest, greift nicht auf ausführbare Artefakte zu, sodass beide Hash-Felder den Wert „unknown“ zurückgeben.
- Wenn ein Hash vorhanden ist, muss der Algorithmus textuelle Namen der IANA-Hash-Funktionen verwenden und von einer Behörde wie dem NIST genehmigt sein
- Anhand von Hashes kann der Empfänger überprüfen, ob es sich bei der beschriebenen Komponente tatsächlich um die gelieferte Komponente handelt.
2. Der Kontext der SBOM-Erstellung macht die Methode zu einem Bestandteil der Aufzeichnung
Der „SBOM-Generierungskontext“ ist die unauffälligste Ergänzung, aber strukturell die bedeutendste: „die jeweilige Phase des Software-Lebenszyklus und die Daten, die zum Zeitpunkt der Erstellung der SBOM durch den SBOM-Ersteller verfügbar waren.“ Die CISA definiert drei Werte – „vor der Erstellung“, „während der Erstellung“ und „nach der Erstellung“ – und ordnet jeden davon der Art und Weise zu, wie die SBOM erstellt wurde: Eine aus dem Quellcode abgeleitete SBOM wird der frühesten Phase zugeordnet, während Binäranalyse-Tools sie der spätesten Phase zuordnen.
- Beschaffungsteams können festlegen, welche Lebenszyklusphase sie akzeptieren, wobei sie SBOMs aus dem kompilierten Artefakt gegenüber solchen auf Quellcodeebene den Vorzug geben.
- Plattformen zum Schwachstellenmanagement können Befunde entsprechend dem angegebenen Kontext gewichten
- Eine aus Quellcode abgeleitete SBOM ist weiterhin zulässig, kann jedoch nicht mehr als gleichwertig mit einer SBOM dargestellt werden, die aus der fertigen Binärdatei erstellt wurde.
3. Umfang ersetzt Tiefe, ohne Mindestanforderungen
Das Kriterium „Tiefe“ für das Jahr 2021 sah lediglich Abhängigkeiten auf oberster Ebene vor – eine Definition, die laut CISA nun „eher die damaligen Fähigkeiten der SBOM-Tools widerspiegelte als die Tiefe der Informationen, die für fundierte Sicherheitsentscheidungen erforderlich sind“. Die Anforderungen an die Abdeckung sind strenger: „Alle Komponenten, aus denen sich die Zielsoftware zusammensetzt, einschließlich transitiver Abhängigkeiten. Es gibt keine Mindesttiefe.“
Der Test ist funktional. Ein Empfänger „sollte zu dem Schluss kommen können, dass eine neu gemeldete Sicherheitslücke ihn nicht betrifft, wenn die mit der Sicherheitslücke in Verbindung stehende Komponente nicht in der SBOM aufgeführt ist.“ Das Fehlen einer Komponente gilt als Beweis, was jedoch nur dann zutrifft, wenn die Abdeckung ausreichend vollständig ist. Allein durch das Parsen des Manifests lässt sich dieser Standard wahrscheinlich nicht erreichen, und zwar in folgenden Fällen:
- Statisch verknüpfter und als Vendor-Code integrierter Code – hinterlässt keinen Manifest-Eintrag
- C- und C++-Projekte – es gibt keinen universellen Paketmanager, der die beim Kompilieren eingebundenen DLLs und Shared Objects nachverfolgt
- Kopierter Quellcode – den die CISA als „im Grunde eine Abhängigkeit, die besser als Fork und als Abhängigkeitsbeziehung erfasst wird“ beschreibt
- Container Bild-Ebenen – Pakete, die über Layer-Befehle installiert und nicht in einem Manifest deklariert wurden
Unbekannte Informationen müssen nun angegeben werden
- Autoren sollten zwischen ihnen unbekannten Informationen und bewusst vorenthaltenen Informationen unterscheiden.
- Den Autoren wird empfohlen, ein Verfahren einzurichten, über das Empfänger Anfragen zu geschwärzten sicherheitsrelevanten Inhalten stellen können.
- „Unternehmen können eine SBOM als unvollständig betrachten, wenn der Verfasser der SBOM wesentliche Komponentendaten zurückhält.“
- Die Berücksichtigung von Fehlern wurde mit der Begründung abgeschafft, dass Empfänger „davon ausgehen können, dass die SBOM-Daten korrekt sind“ – Fehler, die auf die „Auswahl ungeeigneter Tools“ zurückzuführen sind, fließen nun als legitime Faktoren in die Risikobewertung des Empfängers ein.
Weitere Änderungen, die die CISA an den SBOM-Elementen für 2026 vorgenommen hat
Ändern | Was es ist | Warum das wichtig ist |
Unterschrift des SBOM-Autors (neu) | Eine digitale Signatur, die mit dem Verfasser der SBOM verknüpft ist | Ermöglicht es einem Empfänger, zu überprüfen, ob die SBOM authentisch ist und nach der Signierung nicht verändert wurde |
Komponentenlizenz (neu) | Die Lizenz, unter der die jeweilige Komponente bereitgestellt wird | Risiken im Zusammenhang mit Urheberrechten und Compliance; CISA verweist auf SPDX-Lizenz-IDs |
Maschinell verarbeitbare Daten (früher: Automatisierungsunterstützung) | Nur SPDX und CycloneDX | SWID wurde gestrichen, da es kaum verwendet wird; dadurch wird die Auswahl an akzeptierten Formaten auf zwei eingeschränkt |
Komponentenhersteller (früher: Name des Lieferanten) | Pro Komponente eine benannte Organisation | Fügt einen expliziten Fallback für „unbekannte Herkunft“ hinzu, wenn die Quelle unklar ist |
Häufigkeit (aktualisiert) | Eine neue SBOM für jede Version, jedes Update und jeden Build, in der die geänderten Komponenten berücksichtigt werden | Dieses Tempo lässt sich manuell nur schwer aufrechterhalten, was die Teams dazu veranlasst, auf eine automatisierte Erstellung umzusteigen |
Die Lücke nach der Fertigstellung schließen
Die Aktualisierung von 2026 spiegelt die Einschätzung der CISA wider, dass die SBOM-Tools mittlerweile so ausgereift sind, dass höhere Anforderungen an sie gestellt werden können, und dass die Informationen, die sie nun erwartet, jenseits des Build-Prozesses liegen.
MetaDefender™ Software Supply Chain erzeugt SBOM-Daten direkt aus dem kompilierten Artefakt:
- Es werden Artefakte, Binärdateien und Container-Image-Layer gescannt und nicht nur Abhängigkeitsdateien
- Erkennt C-, C++- und C#-Binärdateien anhand von Metadaten im Portable Executable-Format sowie signaturbasierte Identifizierung
- Erstellt SBOMs in CycloneDX und SPDXund erweitert bestehende Berichte, um Komponenten und CVEs aufzudecken, die bei früheren Scans übersehen wurden
- Verweist auf GHSA, CVE und EUVD und kennzeichnet nicht konforme Lizenzen
- Lässt sich in CI/CD-Pipelines und Artefakt-Register wie JFrog Artifactory integrieren, sodass bei jedem Build eine SBOM erstellt werden kann
Erfahren Sie, wie MetaDefender Software Supply Chain die SBOM-Anforderungen über den gesamten Entwicklungslebenszyklus hinweg unterstützen können:
FAQ
Was hat sich bei den Mindestanforderungen für SBOMs gemäß CISA 2026 geändert?
Das Update fügt zehn neue Datenfelder hinzu, nimmt acht wesentliche Änderungen vor und entfernt ein Element. Die bedeutendste strukturelle Änderung ist die Ersetzung von „Depth“ durch „Coverage“, und neue Felder wie „Component Hash Value“, „SBOM Generation Context“ und „SBOM Author Signature“ setzen neue Maßstäbe hinsichtlich der Erstellung und Überprüfung von SBOM-Daten.
Sind die Mindestanforderungen der CISA 2026 SBOM verbindlich?
Nein. Die CISA legt weder eine Frist für die Einhaltung noch Durchsetzungsmechanismen fest und erklärt, dass das Dokument „keine Empfehlung für Compliance-, regulatorische oder rechtliche Zwecke darstellt“. Die praktische Durchsetzung erfolgt über Beschaffungsvorschriften und über Vorschriften, die auf SBOM-Baselines verweisen, wie beispielsweise das EU-Gesetz zur Cyber-Resilienz.
Erfordern die Mindestanforderungen der CISA 2026 SBOM eine Binär- oder eine Analyse nach der Kompilierung?
Nicht ausdrücklich. Allerdings erfordert der „Component Hash Value“ Zugriff auf das ausführbare Artefakt, beim „SBOM Generation Context“ müssen die Autoren die Lebenszyklusphase angeben, und nicht ausgefüllte Felder müssen als „unbekannt“ gekennzeichnet werden. Eine reine Quellcode-SBOM erfüllt somit das Format und dokumentiert gleichzeitig ihre eigenen Lücken.
Gelten die Mindestanforderungen der CISA 2026 auch für KI-Software und SaaS?
Ja. Der Geltungsbereich umfasst die gesamte Software, einschließlich Open-Source-Software, KI und SaaS. Die CISA weist darauf hin, dass diese Kategorien möglicherweise zusätzliche Elemente erfordern, definiert diese hier jedoch nicht, sondern verweist stattdessen auf die im Mai 2026 veröffentlichten gemeinsamen Leitlinien der G7 zu SBOM für KI.
Welche SBOM-Formate werden in den Mindestanforderungen der CISA 2026 akzeptiert?
SPDX und CycloneDX werden als die beiden Formate beschrieben, die zur Erstellung und Nutzung von SBOMs weit verbreitet sind. SWID-Tags wurden entfernt, da es sich dabei „nicht um ein weit verbreitetes SBOM-Datenformat handelt, für das mehrere Tools zur Verfügung stehen“. Veraltete Versionen eines Formats sollten für neue Software nicht verwendet werden.
