Was ist eine SBOM -und warum reicht sie nicht?

Eine SBOM (Software Bill of Materials) ist eine Software-Stückliste: ein maschinenlesbares Verzeichnis aller Komponenten, die in einem Software-Produkt enthalten sind. Der CRA definiert sie als "formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten" (Art. 3 Nr. 39).

Warum ist eine SBOM Pflicht?

Mehrere EU-Gesetze fordern die Dokumentation von Software-Komponenten:

• DORA Art. 8 Abs. 4-6: Inventar aller IKT-Assets einschließlich Konfiguration und Abhängigkeiten, regelmäßig aktualisiert
• DORA Art. 28 Abs. 3: Informationsregister über alle IKT-Drittvereinbarungen
• NIS2 Art. 21 Abs. 2 lit. d: Sicherheit der Lieferkette als Pflichtmaßnahme -setzt Kenntnis aller Komponenten voraus
• CRA Anhang I Teil II Nr. 1: Schwachstellen und Komponenten müssen mittels SBOM ermittelt und dokumentiert werden
• CRA Art. 13 Abs. 24: Die SBOM muss in einem gängigen maschinenlesbaren Format vorliegen
• ISO 18974 (4.3.1): SBOM-Erstellung und -Pflege als kontinuierlicher Prozess mit NTIA-Minimum-Elementen

Eine SBOM ist also nicht optional. Sie ist eine gesetzliche Anforderung.

Das Problem: SBOM ist nicht gleich Sicherheit

Die meisten Unternehmen erstellen eine SBOM und glauben damit, ihre Pflicht erfüllt zu haben. Das ist ein gefährlicher Irrtum.

Eine SBOM ist ein Inventar -kein Sicherheitsinstrument. Sie zeigt Ihnen, was da ist. Sie sagt Ihnen nicht:

• Ob die Komponenten Schwachstellen haben, die in keiner CVE-Datenbank stehen
• Ob ein Projekt noch aktiv gepflegt wird oder seit Monaten verwaist ist
• Ob der einzige Maintainer gerade aufgehört hat
• Ob Sicherheitsfixes stillschweigend eingebaut wurden, ohne dass es eine öffentliche Meldung gab
• Ob die transitiven Abhängigkeiten -also die Abhängigkeiten Ihrer Abhängigkeiten -ebenfalls sicher sind

Transitive Abhängigkeiten sind besonders tückisch: Ihre SBOM zeigt vielleicht 200 direkte Komponenten. Tatsächlich hängt Ihre Software aber von 800 oder mehr Projekten ab, weil jede Komponente wiederum eigene Abhängigkeiten hat. Ein Sicherheitsproblem in der vierten Ebene betrifft Sie genauso wie eines in der ersten.

Was eine SBOM braucht, um nützlich zu sein

Eine SBOM wird erst dann zum Sicherheitsinstrument, wenn sie:

• Kontinuierlich aktualisiert wird -bei jeder Änderung, nicht einmal im Quartal (DORA Art. 8 Abs. 6)
• Gegen Schwachstellen abgeglichen wird -und zwar nicht nur gegen CVE-Datenbanken, sondern auch gegen Silent Fixes und Projekt-Gesundheitsdaten (ISO 18974, 4.1.5 Nr. 2)
• Mit Risikobewertungen versehen wird -pro Komponente, pro Schwachstelle (ISO 18974, 4.3.2 Nr. 2)
• Mit Maßnahmen verknüpft wird -dokumentiert, was bei einem Fund passiert ist (ISO 18974, 4.3.2 Nr. 3)

Was bedeutet das für Sie?

Wenn Sie eine SBOM erstellt haben, haben Sie den ersten Schritt getan. Aber eine SBOM allein erfüllt weder die Anforderungen von DORA, NIS2 noch die des CRA. Diese Gesetze verlangen aktives Risikomanagement, nicht bloße Inventarisierung. Der Unterschied zwischen "wir haben eine SBOM" und "wir managen unsere Open-Source-Lieferkette" ist der Unterschied, den ein Auditor prüfen wird.

Weiterlesen

• Warum Ihre SBOM verrottet
• Open-Source-Lieferkettensicherheit
• Silent Fixes - Die unsichtbare Gefahr

Sie haben eine SBOM erstellt und fragen sich, was als Nächstes kommt? Lassen Sie Ihre SBOM von OTTRIA analysieren.