Das 17-seitige Anforderungsdokument ist hier veröffentlicht.

Die wichtigsten Anforderungen lassen sich wie folgt zusammenfassen:

1. Die Erstellung eines SBOM ist obligatorisch, um die CRA zu erfüllen.

2. Ein SBOM MUSS bestimmte Mindestinformationen enthalten, kann jedoch nach Belieben erweitert und detailliert werden.

3. Ein neues, separates SBOM MUSS für jede Softwareversion erstellt werden.

4. Eine neue Version des SBOM für eine bestimmte Softwareversion MUSS nur dann erstellt werden, wenn zusätzliche Informationen zu den enthaltenen Softwarekomponenten bereitgestellt werden oder Fehler in den SBOM-Daten korrigiert werden.

5. Es ist NICHT erforderlich, Schwachstelleninformationen im SBOM aufzunehmen.

6. Das SBOM muss in einer der beiden Spezifikationen vorliegen: CycloneDX Version 1.4 oder höher ODER SPDX Version 2.3 oder höher.

7. Das SBOM MUSS als Teil des Build-Prozesses oder eines entsprechenden Äquivalents erstellt werden, wenn der Build-Prozess nicht existiert.

8. Der Ersteller des SBOM MUSS per E-Mail identifiziert werden oder auf eine URL zurückgreifen.

9. Das Datum und die Uhrzeit der Datensammlung des SBOM MUSS enthalten sein.

10. Für jede im SBOM enthaltene Komponente —

11. Der Komponentenname, die Version (bevorzugt SemVer oder Kalender) und die Liste der Komponenten, von denen diese Komponente abhängt, MUSS enthalten sein.

12. Die Lizenz der Komponente MUSS für jede Lizenz angegeben werden und muss mit ihrem SPDX-Identifikator identifiziert werden.

13. Wenn die Lizenz nicht in SPDX gefunden wird, muss die ScanCode LicenseDB AboutCode verwendet werden. Diese müssen mit LicenseRef-scancode- identifiziert werden.

14. Wenn keiner die Lizenz findet, muss LicenRef-<unique-inventorying-entity> verwendet werden, um die SPDX Lizenzäußerungkriterien zu erfüllen.

15. Die Komponente MUSS einen Hashwert als SHA-256 enthalten.

16. Das SBOM DARF eine SBOM-URI enthalten.

17. Jede SBOM-Komponente DARF die URI des Quellcodes, die URI der ausführbaren Form der Komponente, den Hashwert des Quellcodes als SHA-256 (exakte Methode bleibt unbestimmt) und andere eindeutige Identifikatoren der Komponente wie CPE oder PURL enthalten.

18. Die Richtlinien empfehlen auch CSAF (mit einem VEX-Profil) als das Format zur separaten Verbreitung von Schwachstellen vom SBOM.

Die technische Richtlinie TR-03183 ist ein wichtiger Schritt vorwärts zur Klärung der genauen Schritte, die Softwareanbieter unternehmen müssen, um die Compliance mit CRA zu erfüllen. Es muss jedoch noch beantwortet werden.

Ohne CPE oder PURL als Identifikationsanforderung sind Schwachberichtserstellungen aus dem SBOM fehleranfällig.

‍Die Richtlinie verwendet „Lieferumfang“, um die Tiefe zu definieren, in der die transitive Komponente aufgelistet werden muss. Es fehlen jedoch Hinweise zur akzeptablen „Lieferumfang“.

‍Die Richtlinien erkennen ausdrücklich an, dass die Methode zur Berechnung von SHA-256 des Quellcodes noch abgeschlossen werden muss.

Die Richtlinien fordern die Aufnahme aller transitiven Komponenten rekursiv auf, verlangen jedoch nicht ausdrücklich, dass Beziehungen zwischen diesen Komponenten angegeben werden. Nach unserer Erfahrung ist das Fehlen/Überspringen von Beziehungen ein häufiges Problem bei SBOM-Generatoren und beeinträchtigt die Nutzung des SBOM für das Schwachstellenmanagement.