SBOMs im Jahr 2026: Jeder generiert sie, niemand nutzt sie

ENISA hat gerade ihren SBOM Adoption State of Play 2026 veröffentlicht, basierend auf einer Umfrage unter 334 Organisationen (65 % in der EU ansässig, 80 % direkt vom Cyber Resilience Act (CRA) betroffen). Dies ist die bisher klarste Momentaufnahme, wo die Branche in Bezug auf die Transparenz der Software-Lieferkette steht, und das Bild ist nuancierter als „alle sind dabei“.

Das ist uns aufgefallen.

Der CRA leistet die Hauptarbeit

Es überrascht nicht, dass der CRA der Haupttreiber für die SBOM-Einführung ist. 43 % der Organisationen geben an, dass der CRA ihre SBOM-Investitionen erheblich beschleunigt hat, weitere 29 % berichten von einem moderaten Einfluss. 78 % haben ihre SBOM-Reise begonnen, und 79 % erwarten, das erforderliche Reifegradniveau zu erreichen, wenn der CRA im Dezember 2027 vollständig anwendbar wird.

Das bedeutet, dass etwa jede fünfte Organisation erwartet, die Frist zu verpassen, und 12 % können nicht einmal einen Zeitplan abschätzen.

SBOMs zu generieren und sie zu nutzen, sind zwei verschiedene Dinge

Die meisten Organisationen erstellen jetzt SBOMs. 39 % generieren sie zur Build-Zeit, und 74 % haben die Generierung pro Release zumindest teilweise automatisiert. Die Nutzung hinkt jedoch hinterher:

• 44 % berichten von einer moderaten Lücke zwischen der Generierung von SBOMs und deren tatsächlicher Nutzung, und 23 % berichten von einer erheblichen Lücke. Nur 7 % haben diese geschlossen.
• 20 % der Befragten wissen überhaupt nicht, ob oder wie SBOMs in ihrer Organisation genutzt werden.
• Die ENISA kommt selbst zu dem Schluss, dass SBOMs „hauptsächlich für Compliance-Zwecke“ und nicht für aktive Sicherheit verwendet werden.

Eine SBOM ungelesen in einem Artefakt-Register SBOM , ist nichts weiter als Papierkram. SBOMs bieten nur dann einen Mehrwert, wenn sie in das Schwachstellen- und Lizenzmanagement einfließen. Genau hier haben Teams Schwierigkeiten. 58 % bezeichnen den Abgleich von Schwachstellen (CPE/PURL-Zuordnung, Fehlalarme) als große Herausforderung, und 60 % weisen auf Probleme mit der Datenqualität hin, wie unvollständige Komponenten und Identifikatoren. Lesen Sie unseren Artikel „Open-Source-Lizenzrisiken verstehen “, um mehr darüber zu erfahren, wie wir Risiken ermitteln und warum unsere Methode zuverlässig ist.

Lieferanten senden keine SBOMs

Die meisten Organisationen erhalten keine SBOMs von ihren Lieferanten, weil die meisten Lieferanten sie nicht senden.

• 39 % der Organisationen erhalten nie SBOMs für die kommerzielle Software, die sie kaufen. Weitere 39 % erhalten sie nur selten. Nur 2 % erhalten sie immer.
• Nur 10 % haben verbindliche SBOM-Klauseln in Lieferantenverträgen (obwohl 55 % daran arbeiten).
• 45 % geben an, dass weniger als ein Viertel ihrer Lieferanten ihre SBOM-Anforderungen erfüllen.
• Vollständigkeit (27 %), Genauigkeit der Identifikatoren (17 %) und Schwachstellenreferenzen (12 %) sind die größten Qualitätslücken.

Die Tiefe verschärft das Qualitätsproblem. 36 % der Organisationen benötigen SBOMs, die alle primären Komponenten und direkten Abhängigkeiten abdecken, aber nur 29 % erhalten dies. Bei SBOMs mit voller Tiefe beträgt die Lücke 24 % (benötigt) gegenüber 14 % (erhalten). Und 45 % wissen nicht einmal, welche Tiefe sie erhalten. 

Da die meisten realen Schwachstellen in transitiven Abhängigkeiten verborgen sind, begrenzt dies direkt den Sicherheitswert jedes SBOM-Programms.

Was die Daten außerdem zeigen

Der Bericht zeigt weitere Erkenntnisse, die eine Branche offenbaren, die das Problem zwar versteht, aber Schwierigkeiten bei der Umsetzung hat.

Was im Weg steht

• Sorge übersteigt Investitionen. Über 90 % der Organisationen sind besorgt über Lieferkettensicherheit, aber nur 34 % stellen dafür erhebliche Ressourcen bereit. Ein Fachkräftemangel verschärft das Problem, wobei 57 % einen Mangel an Fähigkeiten oder Personal als Hindernis nennen.
• Vollständigkeit ist das Haupthindernis. 62 % geben an, dass das Erreichen eines hohen Grades an SBOM-Vollständigkeit ziemlich oder extrem schwierig ist.
• Formatkriege sind nicht vorbei. CycloneDX führt (44 %) vor SPDX (29 %), aber 28 % verwenden immer noch proprietäre oder nicht-standardisierte Formate. Dies stellt ein direktes Compliance-Risiko dar, da die CRA ein gängiges, maschinenlesbares Format vorschreibt und die BSI-Richtlinie explizit CycloneDX 1.6+ oder SPDX 3.0.1+ erwartet.

Wer ist vorne und was kommt als Nächstes

• Kleine Unternehmen sind unerwartet führend. 23-25 % der Kleinst- und Kleinunternehmen berichten von einer ausgereiften, automatisierten SBOM-Implementierung, verglichen mit nur 4-6 % der mittleren und großen Unternehmen. Gleichzeitig sehen 36 % der großen Unternehmen SBOMs als „verpflichtende Last“.
• Der Markt wünscht sich eine Referenzimplementierung mit vorgefertigten Pipelines (26 %), Tool-Benchmarks und einen Einkaufsführer (22 %), Konformitätstests (18 %) sowie ein Profil, das definiert, wie eine „ausreichend gute“ SBOM aussieht (31 %).

Was das in der Praxis bedeutet

Die ENISA-Daten zeigen, dass die Nutzung die Herausforderung sein wird, die das Jahr 2026 prägen wird. Das bedeutet automatisierte Generierung bei jedem Build, kontinuierliche Updates über den gesamten Produkt-Support-Zeitraum, Schwachstellen-Workflows, die tatsächlich an SBOM-Daten gebunden sind, und Transparenz darüber, was Ihre Lieferanten Ihnen liefern. Dort zeigt die Umfrage die größten Lücken, und dort wird die CRA den größten Druck ausüben.

Wie Aikido Ihnen dabei hilft

Hier kommt Aikido Security ins Spiel, das die Lieferkettentransparenz über die Compliance-Checkliste hinausführt und in Ihre Schwachstellen- und Lizenzierungs-Workflows integriert.

Wie Aikido SBOMs Aikido , die man tatsächlich nutzen kann

Automatisierte SBOM

Aikido Syft zur Erstellung präziser SBOMs und ergänzt diese automatisch um genaue Lizenz- und Urheberrechtsangaben, um deren Gesamtqualität zu verbessern.

Direkte vs. transitive Abhängigkeiten

‍Der CycloneDX-ExportAikidotrennt automatisch Ihre direkten Abhängigkeiten von den transitiven. Dies entspricht genau der Anforderung Cyber Resilience Act, ein Verzeichnis der Abhängigkeiten der ersten Ebene zu führen. So erhalten Sie eine genaue SBOM, ohne den Abhängigkeitsbaum selbst manuell nachverfolgen zu müssen.

SBOM-Generierung mit einem Klick im richtigen Format 

Mit einem Klick generiert Aikido SBOMs für Ihre Repositories in CycloneDX und SPDX, den beiden Formaten, auf die die CRA- und BSI-Richtlinien verweisen. Dies deckt die 28 % der Organisationen ab, die noch an proprietären Formaten festhalten, sowie die Verpflichtung zu „Mindestinhalten in maschinenlesbarem Format“, und die Exporte können direkt in Ihre technische Dokumentation übernommen werden, wenn eine Marktüberwachungsbehörde nachfragt.

SBOM-Konsum, einschließlich selbstberichteter SBOMs

Das Generieren eigener SBOMs deckt nur den Code ab, den Sie schreiben. Aikido ermöglicht Ihnen auch den Import von SBOMs, die Sie von Anbietern und Lieferanten erhalten (selbstberichtete SBOMs), sodass Drittanbieter-Komponenten in dasselbe Schwachstellen-Monitoring wie Ihre eigenen Abhängigkeiten einbezogen werden. Angesichts der Tatsache, dass 39 % der Organisationen nie Lieferanten-SBOMs erhalten und die meisten, die sie erhalten, nicht darauf reagieren können, schließt ein Ort, an dem Lieferanten-SBOMs zu überwachtem Inventar werden, das kontinuierlich mit bekannten Schwachstellen abgeglichen wird, die von ENISA beschriebene Konsum-Lücke.

Aikido Device Protection: Transparenz, wo SBOMs nicht hinkommen

SBOMs beschreiben, was in Ihren Produkten enthalten ist. Aber Ihre Angriffsfläche umfasst auch die Maschinen, die diese Software erstellen und schreiben. Die Bereitstellung von Aikido Device Protection auf Build-Servern und Entwickler-Maschinen erweitert dieselbe Inventar- und Schwachstellen-Denkweise auf Ihre Entwicklungsumgebung und deckt ab, welche Tools, Runtimes und Pakete installiert sind, welche veraltet oder anfällig sind und ob die Umgebung, die Ihre „vertrauenswürdigen“ Builds erstellt, selbst vertrauenswürdig ist. Da Lieferkettenangriffe auf CI-Pipelines und Entwickler-Workstations abzielen, anstatt auf den Code selbst, schließt dies einen blinden Fleck, den Ihnen keine SBOM jemals zeigen wird.

Zusammen ermöglichen Ihnen diese drei Funktionen zu wissen, was Sie liefern, was Sie konsumieren und die Umgebung zu kennen, in der alles erstellt wird. Sie laufen kontinuierlich, ohne ein weiteres Dashboard hinzuzufügen, das Ihr Team ignoriert. Das ist Lieferkettensicherheit, die über die Compliance-Checkliste hinausgeht.

​