Vorschriften für Software Bill of Materials verändern die Art und Weise, wie Anbieter ausgewählt werden.

Der Sicherheitsvorfall bei Ernst & Young in dieser Woche, den die Erpresserbande ShinyHunters für sich reklamiert, folgt einem Muster, das sich 2026 als Standardfehlermodus etabliert hat: Die Angreifer haben nicht EYs eigene Abwehr geknackt, sondern über einen Lieferketten-Anbieter Zugangsdaten kompromittiert und sind durch die Vordertür hereingekommen. Genau dieses Muster sollen Software-Bill-of-Materials-Vorschriften erkennen, bevor es passiert – und die meisten Unternehmen können mit den SBOMs, die sie bereits sammeln müssen, immer noch nichts anfangen.

Ein SBOM ist ein strukturiertes Inventar aller Komponenten innerhalb einer Software: jede Bibliothek, jede Abhängigkeit, jede Version, bis hin zum kleinsten Modul, inklusive Firmware. Die Idee ist simpel – wenn man genau weiß, was in einem Produkt eines Anbieters steckt, kann man es gegen bekannte Schwachstellen prüfen, sobald eine neue CVE veröffentlicht wird, anstatt es erst in einem Incident-Response-Call zu erfahren.

Die regulatorische Welle, die 2026 aufschlägt

Der EU Cyber Resilience Act, seit Dezember 2024 in Kraft, tritt dieses Jahr in die Durchsetzungsphase ein. Die Meldepflichten für Schwachstellen und Vorfälle werden im September 2026 wirksam, die vollständigen SBOM-Produktionsanforderungen folgen im Dezember 2027 – das gibt Anbietern eine Vorlaufzeit, aber keine unbegrenzte. Der CRA verlangt ein umfassendes Komponenteninventar von jedem Anbieter, der digitale Produkte auf dem EU-Markt verkauft, was in der Praxis die meisten globalen Software-Anbieter betrifft.

Finanzdienstleister stehen vor einer parallelen Anforderung. Gemäß dem EU Digital Operational Resilience Act (DORA) verlangen die Artikel 28 bis 30, dass regulierte Finanzunternehmen die gesamte Kette der Anbieter hinter jeder kritischen Funktion verstehen und managen – nicht nur ihren direkten Anbieter, sondern auch dessen Anbieter. Eine Bank kann ihren Cloud-Anbieter nicht länger als Blackbox behandeln; sie muss beantworten können, was tatsächlich darunter läuft.

In den USA verlangt die Executive Order 14028 bereits SBOMs nach NIST-Standard für die Beschaffung von Bundessoftware, von CISA in konkrete Vertragsanforderungen umgesetzt. Dieser einzelne politische Hebel hat mehr zur Normalisierung der SBOM-Produktion bei kommerziellen Anbietern beigetragen als jeder freiwillige Standard – Unternehmen, die Bundesaufträge wollen, müssen einen erstellen, unabhängig davon, ob ihre anderen Kunden danach fragen.

Warum ein SBOM zu haben nicht dasselbe ist wie es zu nutzen

Der Fehlermodus, der sich bei den Deployments 2026 zeigt, ist konsistent: Organisationen behandeln die SBOM-Erfassung als Compliance-Checkbox und nicht als operativen Input. Sie fordern SBOMs von Anbietern an, legen sie ab und hören dann auf. Wenige bauen die Pipeline, die eine statische Komponentenliste tatsächlich in eine Live-Entscheidung umwandelt – automatisch zu markieren, wenn eine neue CVE auf eine Bibliothek trifft, die drei Anbieter eingesetzt haben, und diese Warnung an denjenigen zu senden, der für die Anbieterbeziehung zuständig ist.

Diese Lücke ist genau der Ort, an dem das EY-artige Angriffsmuster lebt. Eine Lieferketten-Kompromittierung kündigt sich nicht als Schwachstelle im eigenen Stack an; sie zeigt sich als kompromittierte Zugangsdaten bei einem Anbieter, dessen interne Softwarezusammensetzung Sie vielleicht nie tatsächlich inventarisiert haben, geschweige denn auf neue Offenlegungen hin überwacht.

Was eine operationelle SBOM-Pipeline tatsächlich erfordert

• Maschinenlesbare Aufnahme, keine PDFs. SBOMs müssen in Standardformaten (SPDX oder CycloneDX) ankommen, die automatisch geparst werden können, nicht als Dokument, das ein Compliance-Team ablegt.
• Kontinuierlicher CVE-Abgleich. Das Inventar ist nur nützlich, wenn es fortlaufend gegen neue Schwachstellenmeldungen geprüft wird, nicht nur einmal beim Onboarding des Anbieters.
• Eigentümerzuordnung. Jede markierte Komponente benötigt einen benannten internen Verantwortlichen, der für die Nachverfolgung beim Anbieter zuständig ist – ohne das bleiben Warnungen unbearbeitet liegen.
• Tiefe jenseits von Tier One. DORA-artige Anforderungen existieren genau deshalb, weil die Risikobewertung von Tier-One-Anbietern den Kompromittierungsfall übersieht, der zwei oder drei Anbieter weiter unten in der Kette passiert, und genau dort haben tatsächlich die jüngsten hochkarätigen Sicherheitsvorfälle ihren Ursprung.

Handlungsempfehlungen

Wenn Ihre Organisation SBOMs nur sammelt, um eine Vertragsklausel oder einen Prüfer zufrieden zu stellen, tragen Sie die Compliance-Kosten ohne den Sicherheitsnutzen – und der EU-Durchsetzungszeitplan (September 2026 für Incident Reporting, Dezember 2027 für die vollständige SBOM-Produktion) bedeutet, dass die Anforderungen von hier an nur noch strenger werden. Beginnen Sie damit, eine Hochrisiko-Anbieterkategorie auszuwählen – die Art mit tiefem Zugang zu internen Systemen, wie die IT-Service-Management-Plattformen, die beim EY-Vorfall dieser Woche involviert waren – und bauen Sie zuerst die Pipeline von der Aufnahme bis zur Alarmierung für diese Kategorie auf, anstatt zu versuchen, jede Anbieterbeziehung auf einmal zu operationalisieren. Eine teilweise Pipeline, die tatsächlich Warnungen auslöst, ist besser als ein vollständiges SBOM-Archiv, das niemand abfragt.