Eine SBOM ist eine Zutatenliste, keine Lebensmittelkontrolle

Wichtigste Erkenntnisse

• Die Mindestanforderungen der CISA für 2026 ersetzten am 29. Juli 2026 die Basisvorgaben der National Telecommunications and Information Administration (NTIA) aus dem Jahr 2021 und legten 17 Datenfelder fest.
• Das Office of Management and Budget (OMB) hob im Januar 2026 die Richtlinien zur Sicherheitsbescheinigung für Software auf Bundesebene auf, sodass die Entscheidung über SBOM-Anfragen nun im Ermessen der einzelnen Behörden liegt.
• Die CRA-SBOM-Anforderungen treten am 11. Dezember 2027 in Kraft und legen Abhängigkeiten auf oberster Ebene als Mindestumfang fest.
• Eine Komponente kann in einer SBOM korrekt aufgeführt sein und dennoch schädlich sein, manipuliert worden sein oder ohne Fehlerbehebung aufgegeben worden sein.

Die Anforderungen an SBOMs ändern sich. Das Office of Management and Budget (OMB) hat im Januar 2026 seine Bescheinigungsmemos auf Bundesebene aufgehoben; die FDA hat im Februar ihre Leitlinien zur Cybersicherheit von Medizinprodukten neu herausgegeben; die CISA hat im Juli die Basisvorgaben für SBOM-Daten aus dem Jahr 2021 ersetzt, und der Cyber Resilience Act (CRA) der EU schreibt ab Dezember 2027 SBOMs von Herstellern vor. Wo immer eine SBOM verlangt wird, übergeben Sie eine Liste der in Ihrer Software enthaltenen Komponenten.

Diese Liste ist nützlich. Die Zutatenliste auf einer Lebensmittelverpackung gibt an, dass das Produkt Erdnüsse enthält, was wichtig ist, wenn man allergisch ist. Um zu überprüfen, ob die Fabrik sauber war oder ob der Lieferant tatsächlich der ist, für den er sich ausgibt, ist eine Inspektion erforderlich, was eine separate Aufgabe darstellt.

Eine SBOM funktioniert genauso. Das Erstellen einer solchen Liste ändert nichts an Ihrem Sicherheitsrisiko, da alle anfälligen, manipulierten oder nicht mehr unterstützten Komponenten auch nach der Erstellung der Liste in Ihrer Software verbleiben. Und keine dieser vier Vorschriften beschränkt sich auf die Liste allein. Die bundesstaatliche Vorschrift ordnet die SBOM in einen breiteren Rahmen sicherer Entwicklungspraktiken ein. In einem Dokument der CISA heißt es, dass die SBOM Daten enthält, die noch analysiert werden müssen, und die FDA sowie die CRA gehen sogar noch weiter, indem sie die SBOM mit der Verpflichtung verbinden, die darin aufgeführten Komponenten zu bewerten und zu patchen.

Was die SBOM-Anforderungen ab Oktober 2026 vorsehen

Vier Regelwerke sind derzeit von größter Bedeutung. Die Tabelle enthält eine Kurzfassung, und in den folgenden Abschnitten werden die Einzelheiten erläutert.

Was von der bundesweiten SBOM-Vorschrift übrig geblieben ist

Die im Mai 2021 unterzeichnete Durchführungsverordnung 14028 markierte den Beginn der bundesweiten SBOM-Pflicht. Abschnitt 4(e)(vii) forderte Leitlinien des NIST dazu, Käufern für jedes Produkt eine SBOM zur Verfügung zu stellen, entweder direkt oder auf einer öffentlichen Website. Die Verordnung wurde zwar nicht aufgehoben, doch der Großteil der damit verbundenen Maßnahmen wurde zurückgenommen. Eine im Juni 2025 erlassene Exekutivverordnung (EO 14306) hob die Bescheinigungsbestimmungen auf, die durch die im Januar 2025 unterzeichnete EO 14144 hinzugefügt worden waren, einschließlich der zentralen Validierung von Lieferantenbescheinigungen durch die CISA. Am 23. Januar 2026 wurden dann durch das OMB-Memo M-26-05 die Memos M-22-18 und M-23-16 aufgehoben, die die Grundlage für das „Secure Software Development Attestation Form“ bildeten.

Behörden können das Formular weiterhin verwenden und die Bereitstellung einer SBOM in die Vertragsbedingungen aufnehmen, doch die behördenübergreifende Richtlinie schreibt beides nicht mehr vor. Wenn Sie Software an einen Käufer auf Bundesebene verkaufen, hängt es von den Richtlinien der jeweiligen Behörde und dem vorliegenden Vertrag ab, ob Sie nun eine SBOM vorlegen müssen.

Die CISA-Grundlage für SBOM-Daten für das Jahr 2026

Am 29. Juli 2026 veröffentlichten die CISA, die NSA, das FBI und 15 internationale Partnerorganisationen die „2026 Minimum Elements for a Software Bill of Materials“. Diese ersetzen das Dokument der National Telecommunications and Information Administration (NTIA) aus dem Jahr 2021, das auf der Grundlage der EO 14028 erstellt wurde, und erhöhen die Mindestanzahl der Datenfelder von 7 auf 17. Zu den neuen Feldern gehören die Unterschrift des SBOM-Erstellers, ein Hash-Wert und ein Hash-Algorithmus für jede Komponente, Komponentenlizenzen, der Name und die Version des Erstellungswerkzeugs sowie ein Erstellungskontext, der angibt, in welcher Lebenszyklusphase die SBOM erstellt wurde, beispielsweise vor oder nach dem Build.

Zwei weitere Änderungen sind in der Praxis von Bedeutung. Die Abdeckung sollte nun transitive Abhängigkeiten ohne Mindesttiefe umfassen, während in der Version von 2021 nur Abhängigkeiten auf oberster Ebene erforderlich waren. Außerdem benötigt jede Komponente mindestens einen maschinenlesbaren Identifikator, wie beispielsweise eine Package-URL.

In dem Dokument heißt es, dass seine Elemente keine neuen Anforderungen schaffen, sondern lediglich die Art und Weise präzisieren, wie Organisationen SBOMs erstellen und anfordern. Außerdem wird die Bestätigung der Richtigkeit, des Erfassungsumfangs und der Vollständigkeit einer SBOM nicht zu den Mindestelementen gezählt, da hierfür andere Qualitätsmaßstäbe erforderlich sind als diejenigen, die eine Signatur bietet.

Anmerkung: Die CISA kommt zu dem Schluss, dass eine SBOM an sich lediglich Daten über Softwarekomponenten darstellt und dass erst durch die Analyse aus diesen Daten Erkenntnisse gewonnen werden.

FDA-Anforderungen an die SBOM gemäß Abschnitt 524B

Der Kongress hat im Dezember 2022 durch den „Food and Drug Omnibus Reform Act“ Abschnitt 524B in den FD&C Act aufgenommen. Dieser gilt für Anträge vor dem Inverkehrbringen, die am oder nach dem 29. März 2023 für ein „Cyber-Medizinprodukt“ gestellt werden, d. h. ein Medizinprodukt, das Software enthält, eine Verbindung zum Internet herstellen kann und Merkmale aufweist, die es anfällig für Cyberbedrohungen machen könnten. Die FDA legt diesen Begriff weit aus, behandelt Firmware als Software und zählt Anschlüsse wie USB- und serielle Schnittstellen als Verbindungsmöglichkeiten. Die betroffenen Antragsarten sind 510(k), PMA, PDP, De Novo und HDE. Gemäß 524B(b)(3) muss der Hersteller eine SBOM vorlegen, die kommerzielle, Open-Source- und handelsübliche Komponenten umfasst.

Die am 3. Februar 2026 neu herausgegebene Leitlinie der FDA geht über die Basisfelder hinaus. Sie empfiehlt, dass jeder Eintrag zu einer Komponente deren Supportstatus (z. B. „aktiv gepflegt“, „nicht mehr gepflegt“ oder „eingestellt“) sowie das Datum des Supportendes enthält und dass Hersteller planen, wie sie Komponenten von Drittanbietern aktualisieren oder ersetzen, wenn der Support endet. Diese Leitlinie ist nicht verbindlich, stammt aus der Zeit vor der Aktualisierung der CISA im Jahr 2026 und bezieht sich weiterhin auf die Arbeit der NTIA aus dem Jahr 2021 zu den Basismerkmalen. Das Gesetz selbst fügt eine Pflicht zur Bereitstellung von Patches hinzu. Abschnitt 524B(b)(2) verpflichtet Hersteller von Cybergeräten, Updates und Patches in regelmäßigen Abständen für bekannte, inakzeptable Schwachstellen sowie außerplanmäßig für kritische Schwachstellen bereitzustellen, die unkontrollierte Risiken verursachen könnten.

Die CRA-SBOM-Anforderungen und was sie offen lassen

Anhang I, Teil II, Nummer 1 des Gesetzes über Cyber-Resilienz verpflichtet Hersteller dazu, Schwachstellen und Komponenten zu identifizieren und zu dokumentieren, unter anderem durch die Erstellung einer SBOM in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten auf oberster Ebene abdeckt. Die Verordnung trat am 10. Dezember 2024 in Kraft, und die wichtigsten Verpflichtungen, einschließlich der SBOM-Pflicht, gelten ab dem 11. Dezember 2027. Die SBOM ist Bestandteil der technischen Dokumentation, und eine Marktüberwachungsbehörde kann sie unter Angabe von Gründen anfordern, wenn sie diese zur Überprüfung der Konformität benötigt. Die Weitergabe an Nutzer ist freiwillig.

Teil II desselben Anhangs verpflichtet Hersteller zudem, Sicherheitslücken unverzüglich zu beheben, unter anderem durch die Bereitstellung von Sicherheitsupdates. Artikel 13 schreibt eine Sorgfaltspflicht bei der Integration von Komponenten von Drittanbietern, einschließlich Open-Source-Komponenten, vor und verpflichtet Hersteller, die eine Sicherheitslücke in einer Komponente entdecken, diese dem Betreuer zu melden und anschließend in ihrem eigenen Produkt zu beheben. Die SBOM-Pflicht geht daher mit Verpflichtungen einher, die die SBOM selbst nicht erfüllt. Die Liste zeigt zwar, was im Produkt enthalten ist, doch die Überprüfung dieser Komponenten und deren Behebung ist eine Aufgabe, die der Hersteller weiterhin selbst übernehmen muss. Die Beschränkung auf die oberste Ebene wirkt sich in der Praxis zudem nachteilig auf diese Pflichten aus: Wenn eine Sicherheitswarnung veröffentlicht wird, handelt es sich bei der betroffenen Komponente oft um eine transitive Abhängigkeit, und eine SBOM, die sich auf Abhängigkeiten der obersten Ebene beschränkt, gibt keinen Aufschluss darüber, ob das Produkt diese Komponente enthält. Die Erfüllung der Behebungspflicht ist mit einer SBOM, die über das Mindestmaß hinausgeht, einfacher.

Die Rolle des NIST

Wenn Sie nach den NIST-Anforderungen für SBOMs suchen, sollten Sie zunächst wissen, dass das NIST keine eigenen SBOM-Datenelemente veröffentlicht. Die NTIA hat 2021 die Grundvoraussetzungen festgelegt, und die CISA hat die aktuellen Anforderungen definiert. Die Rolle des NIST besteht in der Prozessberatung. Das „Secure Software Development Framework“ (SSDF, SP 800-218, Version 1.1) führt eine SBOM als Beispiel für die Herkunftsdaten auf, die Hersteller für jede Komponente einer Version aufbewahren sollten. Das SSDF war für Lieferanten der Bundesbehörden von Bedeutung, da das vom OMB im Januar aufgehobene Bescheinigungsformular von ihnen verlangte, die Einhaltung des SSDF zu bestätigen. Seit dieser Aufhebung kann eine Behörde zwar weiterhin die Bescheinigung anfordern, doch ist sie gemäß der behördenübergreifenden Richtlinie nicht mehr vorgeschrieben.

Wenn in einem Vertrag festgelegt ist, dass die NIST-Richtlinien einzuhalten sind, passen Sie Ihre Entwicklungspraktiken an das SSDF an, erstellen Sie eine SBOM, die die CISA-2026-Elemente erfüllt, und generieren Sie diese bei jeder neuen Version neu. Bislang schreibt noch keine Aufsichtsbehörde die 2026-Elemente vor, doch sie stellen die strengsten veröffentlichten Mindestanforderungen dar, und eine nach diesen Elementen erstellte SBOM erfüllt auch die Mindestanforderungen der FDA und der CRA. Lesen Sie zunächst den Vertragstext, da dieser ausschlaggebend dafür ist, welche dieser Anforderungen für den Käufer von Bedeutung sind.

Diese Vorschriften regeln, wer eine SBOM erstellt und was darin enthalten sein muss. Die FDA und die CRA nennen zwar auch die sich daraus ergebenden Pflichten, wie das Einspielen von Patches und die Sorgfaltspflicht, gehen jedoch kaum darauf ein, wie diese zu erfüllen sind. An dieser Stelle reicht die SBOM nicht mehr aus.

Was eine konforme SBOM allein nicht leisten kann

Erfüllen Sie alle oben genannten SBOM-Anforderungen, und Sie erhalten ein Dokument, das den Inhalt Ihrer Software erfasst. Es kann mehr als nur Namen und Versionen enthalten, beispielsweise einen Hashwert und eine Autorensignatur für jede Komponente. Auch andere Dokumente können damit verknüpft werden. Eine VEX-Erklärung (Vulnerability Exploitability eXchange) gibt an, ob eine aufgeführte Sicherheitslücke das Produkt betrifft, und eine Herkunftsbescheinigung verknüpft ein Artefakt mit dem Build, aus dem es stammt. Selbst wenn all dies vorliegt, finden noch drei weitere Prüfungen außerhalb dieser Dokumente statt.

Stimmt das Artefakt mit seiner Quelle überein?

Die Baseline für 2026 verlangt einen Hash-Wert für das ausführbare Artefakt jeder Komponente sowie eine Signatur des SBOM-Autors. Der Hash identifiziert das beschriebene Artefakt, und die Signatur gewährleistet, dass der angegebene Autor die SBOM signiert hat und dass diese anschließend nicht verändert wurde. Keines der beiden vergleicht das Artefakt mit dem Quell-Repository, auf das das Projekt verweist. Wenn ein gekapertes Betreuerkonto eine manipulierte Version veröffentlicht oder ein Registry-Paket Code enthält, der nicht im Repository des Projekts vorhanden ist, wird dies in der SBOM wie jeder andere Eintrag erfasst – mit einem Hash, der mit der von Ihnen heruntergeladenen Datei übereinstimmt.

Der Abgleich eines Artefakts mit seinem Quellcode kann auf verschiedene Weise erfolgen. Eine Provenienzbescheinigung verknüpft das Artefakt beispielsweise mit dem Build, aus dem es stammt. Bei einem Neubaum aus dem Quellcode wird das Artefakt aus dem Repository durch ein selbst erstelltes ersetzt, sodass die ausgelieferte Version ausschließlich den Inhalt des Repositorys enthält. Beide Verfahren haben dieselbe Einschränkung: Sie stellen lediglich fest, ob das Artefakt mit dem Quellcode übereinstimmt, nicht jedoch, ob der Quellcode fehlerfrei ist. Ein gehacktes Konto oder ein böswilliger Commit würde beide Prüfungen bestehen.

Hätte die Komponente überhaupt zugelassen werden dürfen?

Typosquats, die Vortäuschung von Namespaces und Pakete mit schädlichem Installationsverhalten werden alle wie jedes andere Paket aufgeführt. Die Aufgabe der SBOM besteht darin, zu erfassen, was aufgelöst wurde, und genau das hat sie getan. Die Entscheidung, ob das Paket aufgelöst werden sollte, wurde bereits zuvor getroffen, und die CRA betrachtet diese Entscheidung als Teil der Sorgfaltspflicht bei der Integration von Komponenten von Drittanbietern.

Einige Ökosysteme führen während der Installation oder des Builds Code aus. Ein npm-Lifecycle-Skript wird während der Installation ausgeführt, ein Rust -„build.rs“-Skript läuft während des Builds, und ein Python -.pth-Start-Hook kann bei jedem Start des Interpreters Code ausführen. Viele Pipelines generieren die SBOM zum Zeitpunkt des Builds oder später, sodass das Paket erst dokumentiert wird, nachdem es bereits ausgeführt wurde.

Gibt es eine Lösung, und wer wird sie programmieren?

Eine SBOM in Verbindung mit Beratungsdaten weist darauf hin, dass eine Komponente eine bekannte Sicherheitslücke aufweist. Ein VEX-Dokument kann Aufschluss darüber geben, ob eine Sicherheitslücke Ihr Produkt betrifft, und der von den FDA-Leitlinien empfohlene Supportstatus gibt an, ob der vorgelagerte Anbieter noch existiert, um das Problem zu beheben. All dies beschreibt das Problem, liefert jedoch keinen Patch.

Stellen Sie sich eine Komponente in Ihrer Struktur vor, die eine bekannte Sicherheitslücke in einer Versionsreihe aufweist, die vom Upstream-Entwickler nicht mehr gepflegt wird. Manchmal ist das Projekt auf einer neueren Hauptversion noch aktiv; manchmal wurde es gänzlich aufgegeben. In beiden Fällen können Sie die von Ihnen verwendete Version aktualisieren, ersetzen oder mit einem Patch versehen. Ein Upgrade ist nicht möglich, wenn keine stabilen Release-Versionen existieren, und selbst wenn solche vorhanden sind, ist es nicht immer sicher. Ein Austausch bedeutet eine Neuprogrammierung in dem Umfang, in dem die Komponente verwendet wurde – was schwieriger ist, wenn sie als transitive Abhängigkeit vorhanden war, die Sie nie selbst ausgewählt haben. Damit bleibt nur noch das Patchen der von Ihnen verwendeten Version. Jemand muss den Fix schreiben oder ihn aus der neueren Hauptverzweigung zurückportieren, sofern das Projekt dort noch aktiv ist, und anschließend überprüfen, ob das Verhalten der Komponente weiterhin kompatibel ist. Das ist eine sehr spezielle Aufgabe, und es ist eine Arbeit, die der Upstream-Entwickler für eine Komponente, die er nicht mehr pflegt, nicht übernehmen wird.

Nebeneinander sehen die drei Schecks so aus.

Wie der Rest der Arbeit aussieht

Jede der drei Prüfungen ist eine Aufgabe, die jemand erledigen muss. Bei der Vorabprüfung wird entschieden, ob ein Paket zugelassen werden soll, bevor es auf den Rechner eines Entwicklers oder einen Build-Agenten gelangt. Durch das Neukompilieren aus dem Quellcode erhalten Sie ein Artefakt, das mit dem Code im Repository des Projekts übereinstimmt. Durch die fortlaufende Fehlerbehebung bleiben Komponenten auch dann auf dem neuesten Stand, wenn die Entwicklung im Upstream-Projekt verlangsamt wird oder ganz eingestellt wird.

Aus dem SSDF: Das Rahmenwerk des NIST nennt als Beispiele für Komponenten von Drittanbietern, diese vor der Verwendung zu überprüfen, sicherzustellen, dass jede davon weiterhin gepflegt wird, für diejenigen, bei denen dies nicht der Fall ist, entsprechende Maßnahmen zu planen und aus dem Quellcode zu kompilieren, wenn die Herkunft einer Binärdatei nicht bestätigt werden kann.

Man benötigt die SBOM nach wie vor, um die Frage „Sind wir betroffen?“ beantworten zu können, wenn eine Sicherheitswarnung veröffentlicht wird. Sie liefert nur dann eine aussagekräftige Antwort, wenn sie transitive Abhängigkeiten abdeckt und den tatsächlichen Lieferumfang widerspiegelt – was ein Grund dafür ist, sie gemäß der CISA-Baseline für 2026 statt gemäß den CRA-Mindestanforderungen zu erstellen.

Wenn Sie eines der auf dem Markt erhältlichen Tools zur Sicherheit in der Lieferkette bewerten, sollten Sie sich fragen, an welcher Stelle des Ablaufs das jeweilige Tool zum Einsatz kommt: bevor das Paket bei Ihnen eintrifft, während der Installation oder nachdem das Artefakt bereits installiert ist. Viele Tools dieser Kategorie liefern Berichte über bereits vorhandene Zustände, und ein Angriff, der während der Installation, des Build-Vorgangs oder beim Start des Interpreter ausgeführt wird, ist zum Zeitpunkt des Berichts bereits abgeschlossen.

SecureChain von TuxCare greift ein, noch bevor das Paket bei Ihnen ankommt. Es scannt Pakete auf versteckte Malware und verdächtigen Code und blockiert diejenigen, die den Scan nicht bestehen. Anschließend werden die Pakete in isolierten Build-Umgebungen aus dem Quellcode neu erstellt. Bei aktiven Komponenten werden Sicherheitslücken im Rahmen des SLA behoben, sobald CVEs bekannt werden, und wenn der Upstream-Entwickler die Pflege eines Pakets einstellt, sorgt der „Endless Lifecycle Support“ (ELS) dafür, dass weiterhin Korrekturen bereitgestellt werden. Die Abdeckung umfasst JavaScript-, Python-, Java-, Go-, Rust- und PHP-Pakete.

Was ist zu tun, sobald die SBOM vorliegt?

Die SBOM-Anforderungen haben sich seit 2021 mehrfach geändert. Behandeln Sie das Dokument daher so, als müssten Sie es mit jedem Release neu erstellen, und legen Sie den Schwerpunkt auf Kontrollmaßnahmen, die das Risiko reduzieren. Falls Sie noch keine SBOM haben, erstellen Sie diese gemäß den CISA-2026-Elementen, einschließlich transitiver Abhängigkeiten. Falls Sie bereits über eine SBOM verfügen, überprüfen Sie, ob diese über die Abhängigkeiten der obersten Ebene hinausgeht und die tatsächlich ausgelieferten Komponenten widerspiegelt. Ist dies nicht der Fall, erstellen Sie zunächst ein neues BOM auf Basis des aufgelösten Abhängigkeitsbaums oder des erstellten Artefakts – ohne Begrenzung der Tiefe –, bevor Sie weitere Schritte unternehmen. Vergleichen Sie es anschließend mit den Daten aus Sicherheitshinweisen, sortieren Sie die anfälligen Komponenten danach, ob ein Upstream-Fix vorliegt, und entscheiden Sie, wie Sie mit den Komponenten ohne Fix verfahren wollen. Sie können die Komponente ersetzen, die von Ihnen verwendete Version patchen lassen oder eine explizite Risikoakzeptanz dokumentieren.

Falls in Ihrer SBOM immer wieder Pakete auftauchen, die von niemandem mehr gepflegt werden, erfahren Sie hier, wie SecureChain for Open Source riskante Pakete blockiert, bevor sie in Ihre Umgebung gelangen, und sie auch nach Ablauf des Upstream-Supports weiterhin mit Patches versorgt.

FAQ

Was sind die Anforderungen an eine SBOM?

SBOM-Anforderungen sind Vorschriften, die Softwarehersteller dazu verpflichten, eine Software-Stückliste (Software Bill of Materials, SBOM) vorzulegen, also eine Auflistung der in einem Produkt enthaltenen Komponenten. Zu den wichtigsten zählen Abschnitt 524B der FDA für Medizinprodukte, der seit 2023 in Kraft ist, das EU-Gesetz zur Cyber-Resilienz, das am 11. Dezember 2027 in Kraft tritt, sowie die Beschaffungsbedingungen der US-Bundesbehörden, die nun von Vertrag zu Vertrag festgelegt werden. Die „Minimum Elements“ der CISA für 2026 definieren die grundlegenden Datenfelder.

Gibt es nach wie vor eine bundesweite SBOM-Vorschrift?

Die Durchführungsverordnung 14028, die Leitlinien zur Bereitstellung einer SBOM für Käufer enthielt, ist nach wie vor in Kraft. Das Office of Management and Budget (OMB) hat die Memos, die sichere Software-Bescheinigungen vorschrieben (M-22-18 und M-23-16), am 23. Januar 2026 aufgehoben. US-Behörden können in ihren Vertragsbedingungen weiterhin eine SBOM verlangen; ob Sie also eine vorlegen müssen, hängt vom Käufer ab.

Welche Anforderungen stellt die FDA an die SBOM für Medizinprodukte?

Gemäß Abschnitt 524B des FD&C Act muss ein SBOM, das kommerzielle, Open-Source- und Standardsoftware abdeckt, in den vor der Markteinführung eingereichten Unterlagen für Cyber-Geräte enthalten sein. Dabei handelt es sich um Geräte mit Software, die eine Verbindung zum Internet herstellen können und möglicherweise anfällig für Cyberbedrohungen sind. Die Leitlinien der FDA vom Februar 2026 empfehlen zudem, den Supportstatus sowie das Datum des Supportendes für jede Komponente anzugeben.

Was sind die CRA-Anforderungen an die SBOM?

Das EU-Gesetz zur Cyber-Resilienz (CRA) verpflichtet Hersteller von Produkten mit digitalen Komponenten dazu, eine SBOM in einem gängigen, maschinenlesbaren Format zu erstellen, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Diese Verpflichtung gilt ab dem 11. Dezember 2027, und Marktüberwachungsbehörden können die SBOM unter Angabe von Gründen anfordern, um die Einhaltung der Vorschriften zu überprüfen. Das CRA verpflichtet die Hersteller außerdem dazu, Schwachstellen in ihren Produkten und Komponenten unverzüglich zu beheben.

Wie erfüllen Sie die NIST-SBOM-Anforderungen?

Das NIST legt keine SBOM-Datenelemente fest. Diese stammen aus den „2026 Minimum Elements“ der CISA, die die Basisvorgaben von 2021 der National Telecommunications and Information Administration (NTIA), einer Behörde des US-Handelsministeriums, abgelöst haben. Die Aufgabe des NIST besteht in der Prozessberatung im Rahmen des „Secure Software Development Framework“ (SP 800-218). Die Einhaltung der Vorgaben bedeutet daher in der Regel, die eigenen Entwicklungspraktiken daran anzupassen, eine SBOM zu erstellen, die den CISA-Elementen entspricht, und diese mit jeder neuen Version zu aktualisieren.

Macht eine SBOM Software sicherer?

Nicht von sich aus. Eine SBOM erfasst, welche Komponenten in der Software enthalten sind, was Ihnen hilft, zu reagieren, wenn eine Sicherheitslücke bekannt gegeben wird. Sie überprüft jedoch nicht, ob ein Paket mit seiner Quelle übereinstimmt, beurteilt nicht, ob es hätte installiert werden sollen, und stellt auch keinen Patch bereit.

Was kann man tun, wenn eine Komponente eine Sicherheitslücke aufweist, für die es aber noch keinen Fix vom Upstream-Entwickler gibt?

Sie können die Komponente ersetzen oder die von Ihnen verwendete Version patchen. Ein Austausch kann eine Neuprogrammierung bedeuten, und beim Patchen muss jemand die Korrektur schreiben und testen, da es in der Upstream-Version keine solche Korrektur gibt. Ein Anbieter, der erweiterten Support für Open-Source-Pakete nach Ablauf der Lebensdauer anbietet, kann diesen Patch bereitstellen. Durch die Auflistung der Komponente in einer SBOM wird das Risiko dokumentiert, ohne dass die Komponente selbst verändert wird.

Zusammenfassung

Artikel Name

Anforderungen an die SBOM und was eine Stückliste nicht leisten kann

Beschreibung

Die Anforderungen an die SBOM unterscheiden sich zwischen den US-Behörden, der FDA und der EU-CRA. Erfahren Sie, was eine SBOM nicht leisten kann und welche drei Prüfungen außerhalb der SBOM stattfinden.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers