Ihr Lieferant hat Ihnen eine SBOM geschickt. Können Sie ihr wirklich vertrauen?
| Interlynk
Eine Lieferanten-SBOM ist eine Behauptung, keine verifizierte Tatsache. Hier erfahren Sie, ob die erhaltene SBOM gut genug ist, um darauf zu reagieren, eingeordnet durch das ENISA-Advisory und bewertet mit sbomqs.
Überblick
Immer mehr Teams fordern von ihren Lieferanten eine SBOM an, und immer mehr Lieferanten liefern eine zurück. Das ist ein Fortschritt. Aber der Erhalt einer Datei sagt sehr wenig darüber aus, ob sie die Software, die Sie geliefert bekommen haben, korrekt beschreibt.
Die SBOM könnte aus einem Quellcodebaum erzeugt worden sein, der sich vom ausgelieferten Binary unterscheidet. Sie könnte transitive Abhängigkeiten oder gebündelte Komponenten auslassen. Oder ihre Komponenten-Identifikatoren könnten zu schwach sein, um ein zuverlässiges Abgleichen mit Schwachstellendaten zu stützen.
In jedem dieser Fälle kann die Organisation sagen, sie habe eine SBOM. Die schwierigere Frage ist, ob sie sich auf sie verlassen kann.
Im Oktober 2026 veröffentlichte ENISA ein Technical Advisory for Software Bill of Materials, das dies als Lebenszyklusproblem behandelt: Erzeugung, Validierung, Verteilung und die Bedrohungen für die SBOM-Integrität auf diesem Weg. Das ist ein nützlicher Rahmen, und es ist ein zeitgemäßer Anlass, etwas klarzustellen, das oft unausgesprochen bleibt. SBOMs zu sammeln ist nicht das Ziel. Auf sie reagieren zu können, ist es.
Die Linie, die es zu halten gilt, lautet: Messen Sie Ihr SBOM-Programm nicht daran, wie viele Dateien Sie sammeln. Messen Sie es daran, wie zuverlässig Sie sie nutzen können, um eine Sicherheitsentscheidung zu treffen. Dieser Beitrag legt die drei Vertrauensebenen dar, die eine SBOM verdienen muss, fünf konkrete Prüfungen für eine Lieferanten-SBOM und wie Sie die Qualität in der Praxis mit sbomqs bewerten, ohne zu überhöhen, was ein Score beweist.
Die wichtigsten Fakten
Eine SBOM zu erhalten ist nicht dasselbe wie vertrauenswürdige Transparenz. Eine SBOM ist eine Behauptung über die Software-Zusammensetzung. Sie muss bewertet werden, bevor Sie sich auf sie verlassen.
Es gibt drei Vertrauensebenen: syntaktische Gültigkeit (lässt sie sich parsen und konform), Inventarqualität (sind die Komponenten vollständig und nutzbar) und Artefakt-Vertrauen (beschreibt sie das, was Ihnen tatsächlich geliefert wurde). Eine Ebene zu bestehen verschafft Ihnen die anderen nicht.
Ein Quality Score legt Schwächen offen; er zertifiziert keine Wahrheit. Ein Werkzeug wie sbomqs markiert fehlende Felder, schwache Identifikatoren und fehlende Integritätsdaten. Es kann nicht beweisen, dass ein Lieferant jede Komponente offengelegt hat oder dass ein Binary dem Inventar entspricht.
Die Abdeckung bestimmt die Nützlichkeit. Die SBOM sollte die für das Produkt und seinen vorgesehenen Sicherheitszweck relevanten Komponenten abdecken. Je nach Software kann das transitive Abhängigkeiten, gebündelte Laufzeitumgebungen, statische Bibliotheken, Hersteller-SDKs, Betriebssystempakete oder durch Binäranalyse identifizierte Komponenten erfordern. Ein Manifest allein reicht möglicherweise nicht aus.
Gültigkeit ist nicht Integrität. Eine vollkommen gültige SBOM kann trotzdem das gelieferte Artefakt nicht beschreiben. Die Rückverfolgbarkeit zum Release braucht gesonderte Nachweise: Hashes, Signaturen und Build-Provenance können helfen, eine SBOM mit einem Release zu verknüpfen und Artefakt-Identität oder -Herkunft zu belegen, aber sie beweisen einzeln nicht, dass das Inventar vollständig ist.
Eine SBOM ist eine Behauptung, keine verifizierte Tatsache
Seien Sie unverblümt, was eine Lieferanten-SBOM ist. Sie ist eine Aussage des Lieferanten, die sagt: „Hier ist, was wir für den Inhalt dieses Produkts halten." Sie ist ein Nachweis, und ein nützlicher Nachweis, aber sie beweist sich nicht selbst. Der Lieferant könnte sie aus der falschen Eingabe erzeugt haben, könnte Werkzeuge einsetzen, die ganze Komponentenklassen übersehen, oder weiß schlicht nicht alles, was ein komplexes Produkt enthält.
Die Datei als feststehende Tatsache zu behandeln, ist der Weg, auf dem Teams mit einer Sammlung von SBOMs enden, die sie nicht nutzen können, wenn eine Schwachstelle auftaucht. Die nützlichere Haltung ist die, die ein Sicherheitsprüfer gegenüber jeder Lieferantenbehauptung einnimmt: akzeptieren, dann bewerten. Der Rest dieses Beitrags zeigt, wie man diese Bewertung effizient durchführt.
Drei Vertrauensebenen
Für praktische Lieferantenprüfungen hilft es, das SBOM-Vertrauen in drei Fragen zu zerlegen. Diese Ebenen sind ein Arbeitsrahmen zur Bewertung einer SBOM, keine offizielle Klassifikation von ENISA oder CISA, und sie sind nicht austauschbar. Sie zu verwechseln ist der häufigste Fehler in SBOM-Programmen.
Syntaktische Gültigkeit. Lässt sich die Datei parsen, und entspricht sie CycloneDX oder SPDX. Das ist die Grundlage. Ein Validator oder eine Schemaprüfung beantwortet das. Es ist notwendig und die schwächste der drei Ebenen, denn eine Datei kann einwandfreies JSON sein und trotzdem die falsche Software beschreiben.
Inventarqualität. Sind die Komponenten eindeutig identifiziert, mit Versionen und Beziehungen, und ist das Inventar vollständig genug, um nützlich zu sein. Hier liegt der größte Teil des alltäglichen Werts und des Scheiterns. Eine gültige SBOM mit vagen Identifikatoren oder einer oberflächlichen Komponentenliste stützt das Abgleichen mit Schwachstellendaten nicht, und genau darum geht es.
Artefakt-Vertrauen. Gibt es Belege, dass diese SBOM dem genauen Software-Artefakt entspricht, das der Lieferant geliefert hat. Das ist die schwierigste Ebene und die am häufigsten übersprungene. Eine aus einem Quellcodebaum erzeugte SBOM kann gültig und von hoher Qualität sein und trotzdem nicht das ausgelieferte Binary beschreiben, weil sich zwischen Quelle und Release etwas geändert hat.
Eine Lieferanten-SBOM kann die erste Ebene erfüllen, die zweite recht gut meistern und bei der dritten nichts bieten. Zu wissen, welche Ebene Sie vor sich haben, sagt Ihnen, wie viel Gewicht die Datei tragen kann.
Fünf Prüfungen für eine Lieferanten-SBOM
Führen Sie diesen Durchgang bei jeder SBOM durch, die Ihnen ein Lieferant übergibt. Für jede Prüfung dieselben vier Punkte: was zu prüfen ist, warum es zählt, wie ein Scheitern aussieht und was als Nächstes zu tun ist.
1. Identität
Prüfen Sie, wie Komponenten identifiziert werden. Achten Sie auf eindeutige Identifikatoren wie Package URLs (purl) und CPEs, mit konkreten Versionen, nicht nur Namen.
Warum es zählt: Das Abgleichen mit Schwachstellendaten ist nur so gut wie die Identifikatoren. Wird eine Komponente in dieser SBOM anders benannt als in einer Datenquelle, scheitert der Abgleich stillschweigend.
Wie ein Scheitern aussieht: Komponenten mit Namen, aber ohne Versionen, fehlende oder inkonsistente purls oder dieselbe Komponente, die in den eigenen SBOMs des Lieferanten unterschiedlich identifiziert wird.
Was zu tun ist: Bitten Sie den Lieferanten, mit korrekten Identifikatoren neu zu erzeugen, oder behandeln Sie die schwach identifizierten Komponenten als bekannte Lücke, die Sie manuell auflösen müssen.
2. Abdeckung
Prüfen Sie, wie tief das Inventar reicht. Ein echtes Produkt ist mehr als seine direkten Abhängigkeiten.
Warum es zählt: Eine verwundbare oder bösartige Komponente kann transitiv sein, in ein größeres SDK gebündelt, statisch in Firmware gelinkt oder in ein Container-Image eingebacken. Eine SBOM, die auf der obersten Ebene stehen bleibt, kann Komponenten übersehen, die für Ihre Sicherheitsbewertung wichtig sind.
Wie ein Scheitern aussieht: eine kurze, aufgeräumte Liste direkter Abhängigkeiten ohne transitiven Graphen, keine Betriebssystempakete für einen Container oder keine vendored und statischen Bibliotheken für Firmware.
Was zu tun ist: Fragen Sie, welche Erzeugungsmethode die SBOM hervorgebracht hat und ob sie aus dem finalen Artefakt oder aus einem Manifest gebaut wurde. Eine reine Manifest-SBOM für ein eingebettetes oder containerisiertes Produkt sollte weitere Fragen auslösen, welche Komponenten sie erfasst und welche außerhalb ihres Umfangs bleiben.
3. Artefakt-Abgleich und Integrität
Das ist die Prüfung, die Teams überspringen, und es lohnt sich, sie in drei getrennte Fragen zu zerlegen statt in eine.
Erstens: Kann der Lieferant die SBOM einer bestimmten Produktversion oder einem Release-Artefakt zuordnen. Zweitens: Können Sie verifizieren, dass das Artefakt, das Sie erhalten haben, dasjenige ist, das der Lieferant ausliefern wollte. Drittens: Gibt es Belege, dass die SBOM aus diesem Artefakt erzeugt wurde oder es anderweitig korrekt repräsentiert.
Warum es zählt: Eine gültige, vollständige SBOM für den falschen Build ist irreführend auf eine Weise, wie es eine fehlende SBOM nicht ist. Die Kompromittierung der OVHcloud-CLI im Oktober 2026, bei der Angreifer die veröffentlichten Binaries austauschten, während der Quellcode sauber blieb, ist die Erinnerung daran, dass Artefakt und Quelle verschiedene Geschichten erzählen können.
Was die Integritätswerkzeuge tatsächlich beweisen, und was nicht: Ein Komponenten-Hash identifiziert ein bestimmtes Komponenten-Artefakt. Ein Hash liefert einen Fingerabdruck des Release-Artefakts. Der Vergleich mit einem vertrauenswürdigen Referenz-Hash kann helfen zu verifizieren, dass das gelieferte Artefakt das erwartete ist. Eine Signatur kann verifizieren, dass ein Dokument oder Artefakt mit einem bestimmten Schlüssel signiert wurde, aber die Vertrauenswürdigkeit dieser Signatur hängt auch davon ab, wie der Schlüssel und seine Identität verifiziert werden. Provenance beschreibt, wie ein Artefakt gebaut wurde. Keines davon beweist für sich, dass die Software harmlos ist oder dass die SBOM jede Komponente auflistet. Sie belegen Abgleich und Herkunft, nicht Sicherheit oder Vollständigkeit.
Wie ein Scheitern aussieht: eine SBOM ohne Versionsbindung, ohne Hashes, ohne Signatur und ohne Möglichkeit zu erkennen, zu welchem Release sie gehört.
Was zu tun ist: Bitten Sie den Lieferanten, die SBOM einem bestimmten Produkt-Release zuzuordnen und, wo machbar, verifizierbare Belege bereitzustellen, die das Inventar mit dem gelieferten Artefakt verknüpfen. Das kann Artefakt-Hashes, eine signierte SBOM oder Build-Provenance umfassen. Prüfen Sie, was jeder Beleg belegt, statt einen einzelnen davon als Beweis für Vollständigkeit oder Sicherheit zu behandeln. Bei Firmware, eingebetteter Software und allem mit statisch gelinkten oder herstellergelieferten Komponenten hier am stärksten nachhaken, denn dort weichen Quelle und Artefakt am meisten voneinander ab.
4. Aktualität und Erzeugungskontext
Prüfen Sie, wann und wie die SBOM erzeugt wurde. Achten Sie auf einen Zeitstempel, das erzeugende Werkzeug und den Autor oder Lieferanten.
Warum es zählt: Eine vor Monaten erzeugte SBOM, oder eine vor einem späteren Build-Schritt, der das Artefakt verändert hat, beschreibt möglicherweise nicht mehr, was Sie betreiben. Die 2026 SBOM Minimum Elements erweitern die Metadaten, die zur Bewertung eines Inventars verfügbar sind, darunter Erzeugungskontext, Werkzeugname und -version, Komponenten-Hashes und eine SBOM-Autorensignatur. Diese Felder liefern nützliche Belege dafür, wie die SBOM erzeugt wurde und was sie identifiziert, auch wenn sie nicht unabhängig beweisen, dass sie das gelieferte Artefakt korrekt repräsentiert.
Wie ein Scheitern aussieht: kein Zeitstempel, keine Werkzeugkennung, kein Autor oder ein Erzeugungsdatum, das vor dem Release liegt, das Sie erhalten haben.
Was zu tun ist: Fordern Sie eine SBOM an, die als Teil des Builds erzeugt wurde, der Ihr Artefakt hervorgebracht hat, nicht ein nachträglich von Hand erstelltes Einzelstück.
5. Handlungsfähigkeit
Prüfen Sie, ob Sie die SBOM tatsächlich nutzen können, um eine Sicherheitsfrage zu beantworten. Der praktische Test: Wenn ein CVE oder ein Advisory zu einem bösartigen Paket eine Komponente benennt, können Sie es gegen diese SBOM abgleichen und eine zuverlässige Antwort erhalten.
Warum es zählt: Das ist der Grund, warum Sie die SBOM überhaupt angefordert haben. Alles Vorige fließt hier zusammen. Unser Begleitbeitrag dazu, was eine SBOM während eines Supply-Chain-Angriffs leistet, behandelt die Reaktionsseite im Detail.
Wie ein Scheitern aussieht: Identifikatoren, die nicht mit Datenquellen übereinstimmen, eine zu oberflächliche Abdeckung, um einem sauberen Ergebnis zu vertrauen, oder keine Möglichkeit, die SBOM auf das Produkt und die Version in Ihrer Umgebung zurückzuführen.
Was zu tun ist: Führen Sie die obigen Prüfungen durch, schließen Sie die Lücken, die für Ihr Risikoprofil wichtig sind, und bewahren Sie die SBOM dort auf, wo sie laufend gegen Schwachstellendaten abgeglichen werden kann, nicht bloß abgelegt.
Die Prüfungen in der Praxis mit sbomqs umsetzen
Diese Prüfungen von Hand über einen Stapel von Lieferanten-SBOMs durchzuführen, skaliert nicht. Hier kommt ein Quality Scorer ins Spiel. sbomqs ist ein Open-Source-Werkzeug zur Bewertung der SBOM-Qualität, und das ENISA-Advisory führt es, neben eBays sbomscorecard, unter den Quality-Scoring-Werkzeugen in seinem indikativen Open-Source-Werkzeugstapel auf. ENISA nennt diese Werkzeuge als Teil der Landschaft; es zertifiziert oder empfiehlt sie nicht, und das Advisory stellt ausdrücklich klar, dass die Liste indikativ und nicht erschöpfend ist. Interlynk pflegt sbomqs als Open-Source-Projekt.
sbomqs erzeugt einen Qualitäts-Score von 0 bis 10 für eine CycloneDX- oder SPDX-SBOM, aufgeschlüsselt nach Kategorien, die eng mit den obigen Prüfungen übereinstimmen: Identifikation, Vollständigkeit, strukturelle Konformität, Integrität, Provenance, Lizenzierung, Schwachstellen und Komponenteninformation. Es kann gegen NTIA- und BSI-TR-03183-2-Profile bewerten, was nützlich ist, wenn eine bestimmte Baseline gilt. Es kann rasch Probleme wie fehlende Versionen, schwache Komponentenidentifikation, unvollständige Metadaten und fehlende Integritätsfelder aufzeigen und hilft Prüfern, ihre manuelle Untersuchung auf die Lücken zu konzentrieren, die zählen.
Nun die ehrliche Grenze, und sie zählt. Ein Quality Score misst definierte Aspekte der Struktur und des Inhalts einer SBOM, etwa ob erwartete Felder befüllt sind, Komponenten-Identifikatoren vorhanden sind, Abhängigkeitsbeziehungen dokumentiert sind und Integritäts- oder Provenance-Informationen enthalten sind. Er kann nicht feststellen, dass das Inventar jede Komponente enthält, die tatsächlich in der gelieferten Software vorhanden ist. Wenn sbomqs die „Integrität" hoch bewertet, bedeutet das, dass die SBOM Integritätsdaten wie Komponenten-Hashes enthält, nicht, dass jemand das gelieferte Binary dagegen verifiziert hat. Eine hohe Bewertung der „Vollständigkeit" bedeutet, dass die erwarteten Felder befüllt sind, nicht, dass der Lieferant tatsächlich jede Komponente offengelegt hat. Der Score ist ein schneller, wiederholbarer Weg, Schwächen zu finden und SBOMs auf einer gemeinsamen Skala zu vergleichen. Er ist kein Wahrheitszertifikat, und kein Qualitätswerkzeug kann eines sein. Mit diesem Verständnis genutzt, macht er die fünf Prüfungen zu etwas, das Sie im großen Maßstab durchführen und über die Zeit verfolgen können.
Bekannte Unbekannte
Ein ausgereiftes SBOM-Programm behandelt nicht jedes fehlende Feld als automatisches Versagen, denn manche Lücken sind real und unvermeidbar. Ein Lieferant kennt möglicherweise nicht wirklich jede Komponente in einem komplexen Produkt. Ein herstellergeliefertes Binary kann ohne detaillierte Metadaten ankommen. Eine statisch gelinkte Abhängigkeit kann schwer präzise zu identifizieren sein. So zu tun, als gäbe es diese nicht, führt zu einem schlechteren Ergebnis, als sie zu benennen.
Das ENISA-Advisory macht denselben Punkt in seiner eigenen Sprache und empfiehlt eine dokumentierte Behandlung bekannter Unbekannter und fehlender Metadaten. Das Ziel ist, die Lücken sichtbar statt unsichtbar zu machen: festzuhalten, was unbekannt ist, zu verstehen warum, und zu entscheiden, ob diese Ungewissheit für das Risikoprofil des Produkts akzeptabel ist. Ein Medizinprodukt oder eine Industriesteuerung rechtfertigt eine geringere Toleranz für Unbekannte als ein internes Werkzeug. Eine SBOM, die ehrlich kennzeichnet, was sie nicht ermitteln konnte, ist vertrauenswürdiger als eine, die vollständig aussieht, weil der Generator stillschweigend weggelassen hat, was er nicht auflösen konnte.
Wo Interlynk hineinpasst
Diese drei Aufgaben sind verschieden, und sie getrennt zu halten, ist der entscheidende Punkt.
sbomqs ist der Einstiegspunkt: ein Open-Source-Weg, die Qualität einer SBOM zu bewerten und ihre Schwächen aufzudecken, Ihre eigene oder die eines Lieferanten. Es ist kostenlos ausführbar und der Ausgangspunkt für diese Art von Prüfung.
lynkctl dient der Erzeugung: Es erzeugt build-bewusste SBOMs für unterstützte Builds und Softwareumgebungen und hilft Teams, transitive Abhängigkeiten, statische Bibliotheken, Hersteller-SDKs, gebündelte Laufzeitumgebungen und Komponenten in Firmware und Container-Images zu erfassen, die ein reiner Manifest-Ansatz übersehen kann. So erzeugt ein Lieferant überhaupt erst eine SBOM, die die obigen Prüfungen besteht.
Die Interlynk-Plattform ist die operative Ebene: Sie nimmt SBOMs und CBOMs auf, bewertet deren Qualität, bewertet Komponenten anhand von Schwachstellendaten im Hinblick auf das Risiko, verwaltet die VEX-Aussagen, die Ihre Position pro Produkt festhalten, und benachrichtigt Stakeholder, wenn eine neue Offenlegung die Exposition von etwas bereits Ausgeliefertem verändert. Unser Leitfaden zum Operationalisieren von VEX behandelt diesen Arbeitsablauf, und unsere Notiz zu den CISA 2026 Minimum Elements legt die Baseline fest, auf der die Qualitätsprüfungen aufbauen.
Keines davon ersetzt die anderen, und ein Quality Score ersetzt weder die Erzeugung noch den operativen Arbeitsablauf. Ein Lieferant oder Hersteller braucht zunächst ein tatsächlich nützliches Inventar und muss dieses Inventar dann mit Produkten, Releases, Schwachstellen und Reaktionsentscheidungen verknüpfen. Qualitätsbewertung hilft Ihnen, das Inventar zu beurteilen, das Sie haben. Erzeugung hilft Ihnen, bessere Inventare zu produzieren. Die Plattform verbindet diese Inventare mit Produkten, Schwachstellen, VEX-Bewertungen und Reaktionsabläufen.
Fazit
Eine Lieferanten-SBOM ist eine Behauptung über die Software-Zusammensetzung. Bevor Sie sich auf sie verlassen, bewerten Sie drei Dinge: ob die Datei gültig ist, ob ihr Inhalt nützlich ist und ob sie das Artefakt, das Sie erhalten haben, korrekt repräsentiert.
Fünf Prüfungen helfen, diese Begutachtung zu strukturieren: Identität, Abdeckung, Artefakt-Abgleich, Aktualität und Handlungsfähigkeit. Ein Quality Scorer wie sbomqs kann Teile der Prüfung wiederholbar machen, aber er kann nicht zertifizieren, dass das Inventar wahr ist.
SBOMs zu sammeln war nie das Ziel. Das Ziel ist, den Punkt zu erreichen, an dem eine neue Schwachstelle oder ein kompromittiertes Paket eine schnelle, zuverlässige Antwort darauf liefert, welche Ihrer Produkte betroffen sind. Das geschieht nur, wenn die Inventare, die Sie halten, gut genug sind, um auf sie zu reagieren. Messen Sie das Programm daran, nicht an der Größe des Ordners.
Häufig gestellte Fragen
Woran erkenne ich, ob eine SBOM von guter Qualität ist? Bewerten Sie sie auf drei Ebenen: Lässt sie sich parsen und entspricht CycloneDX oder SPDX, sind ihre Komponenten gut genug identifiziert und dokumentiert, um nützlich zu sein, und gibt es Belege, dass sie das genaue Artefakt beschreibt, das Ihnen geliefert wurde. Ein Quality Scorer wie sbomqs kann viele Aspekte von Struktur und Inhalt schnell bewerten. Die tatsächliche Inventarabdeckung zu beurteilen und den Abgleich mit dem gelieferten Artefakt zu bestätigen, erfordert zusätzliche Belege und Untersuchung.
Kann ich einer SBOM vertrauen, die mir ein Lieferant gegeben hat? Nicht bei Erhalt. Eine SBOM ist eine Behauptung über die Software-Zusammensetzung, keine verifizierte Tatsache. Führen Sie eine Qualitäts- und Abdeckungsprüfung durch, bestätigen Sie, dass sie an das bestimmte Release gebunden ist, und entscheiden Sie, ob etwaige Lücken für das Risikoprofil dieses Produkts akzeptabel sind, bevor Sie sich auf sie verlassen.
Was ist sbomqs und was prüft es? sbomqs ist ein von Interlynk gepflegtes Open-Source-Werkzeug, das die Qualität einer CycloneDX- oder SPDX-SBOM auf einer Skala von 0 bis 10 bewertet, über Kategorien wie Identifikation, Vollständigkeit, strukturelle Konformität, Integrität, Provenance, Lizenzierung und Schwachstellen, mit verfügbaren NTIA- und BSI-Profilen. Das ENISA-SBOM-Advisory führt es unter den Quality-Scoring-Werkzeugen in seinem indikativen Werkzeugstapel auf.
Bedeutet ein hoher SBOM-Quality-Score, dass die SBOM korrekt ist? Nein. Ein hoher Score weist auf starke Ergebnisse über die in der Scoring-Konfiguration enthaltenen Qualitätsprüfungen hin. Er beweist nicht, dass der Lieferant jede Komponente offengelegt hat oder dass das gelieferte Binary dem Inventar entspricht. Selbst ein hoher Score für integritätsbezogene Prüfungen belegt nicht, dass jemand das gelieferte Artefakt gegen die SBOM verifiziert hat. Ein Score legt Schwächen offen; er zertifiziert keine Wahrheit.
Was sollte eine gute SBOM enthalten? Eine nützliche SBOM sollte Komponenten so präzise wie möglich identifizieren, Versionen und Abhängigkeitsbeziehungen enthalten, wo verfügbar, und Metadaten über ihre Erzeugung bereitstellen, etwa Werkzeug und Zeitstempel. Die Abdeckung sollte das Produkt und den vorgesehenen Zweck der SBOM widerspiegeln. Wo Sicherheit auf Artefaktebene wichtig ist, können Hashes, Signaturen oder Build-Provenance zusätzliche Belege liefern, die die SBOM mit einem bestimmten Release verknüpfen. Die jeweils geltenden Anforderungen und die 2026 SBOM Minimum Elements bieten weitere Orientierung.
Wie verifiziere ich, dass eine SBOM der Software entspricht, die ich geliefert bekommen habe? Fragen Sie, ob die SBOM einem bestimmten Release-Artefakt zugeordnet ist. Verifizieren Sie, wo möglich, das gelieferte Artefakt gegen einen unabhängig authentifizierten Hash oder eine Signatur und suchen Sie nach Build-Provenance oder einer Attestierung, die die SBOM mit diesem Artefakt verknüpft. Eine signierte SBOM allein beweist nicht, dass ihr Inventar vollständig ist oder dass sie die gelieferte Software korrekt repräsentiert.
Quellen
ENISA, Technical Advisory for Software Bill of Materials (v1.10, Oktober 2026)
2026 Minimum Elements for a Software Bill of Materials (CISA und internationale Partner, via ACSC)
AWS, „sbomqs and open source tools to quality-check your SBOMs"
Über Interlynk. Interlynk hilft Teams, SBOMs über die gesamte Software-Lieferkette zu generieren, zu verwalten und zu operationalisieren. sbomqs, der Open-Source-Quality-Scorer, bewertet SBOMs anhand von NTIA, BSI und anderen Baselines. lynkctl erzeugt build-bewusste SBOMs für Embedded- und Firmware-Software und erfasst gebündelte Laufzeitumgebungen sowie transitive, statische und SDK-Komponenten mit präzisen Identifikatoren. Die Interlynk-Plattform nimmt SBOMs und CBOMs auf, bewertet sie auf Vollständigkeit und Qualität, bewertet Komponenten anhand von Schwachstellendaten im Hinblick auf das Risiko, verwaltet VEX-Aussagen und benachrichtigt Teams, wenn sich die Exposition ändert.
Demo buchen · Kostenlos starten
Dieser Artikel dient der Information und stellt keine Sicherheits- oder Rechtsberatung dar. Bestätigen Sie aktuelle Standards, Advisories und Werkzeugfähigkeiten anhand der Primärquellen, bevor Sie handeln.