Der Prüfling
- Datei
- sbom_cdx.json aus STM32CubeF4 v1.28.3
- SHA-256
- 5418487d4a2bd5b3134101885c6b7d4a2e302733b9eb3a7a35d281901d0d96fa
Warum eine vorhandene SBOM nicht automatisch reicht
Eine Stückliste aus dem Quellbaum oder dem Paketmanager nennt, was im Repository liegt. Der CRA fragt nach dem Produkt, das Sie in Verkehr bringen: Komponenten, die der Build übernommen hat, mit Version, je ausgelieferter Firmware.
Die fünf Prüfungen unten funktionieren mit jeder CycloneDX-Datei; für SPDX gelten dieselben Fragen mit anderen Feldnamen.
Prüfung 1: Format und Umfang
Die Technische Richtlinie TR-03183-2 des BSI verlangt seit Version 2.1.0 für neu erstellte SBOMs CycloneDX ab 1.6 oder SPDX ab 3.0.1.
jq -r '.bomFormat + " " + .specVersion' sbom_cdx.jsonCycloneDX 1.5
jq '.components | length' sbom_cdx.json74
Prüfung 2: Komponenten ohne Version
Hier vollständig. Eine Komponente ohne Version bleibt in der Liste, lässt sich aber keiner Schwachstelle sicher zuordnen: ein Abgleich übergeht sie oder meldet jede Lücke des Produkts.
jq '[.components[] | select(.version == null or .version == "")] | length' sbom_cdx.json0
Prüfung 3: Kennungen für den Abgleich
NVD ordnet Schwachstellen über CPE zu, andere Datenbanken über purl. Ohne eine der beiden Kennungen muss ein Werkzeug die Komponente am Namen erkennen, und ein Name wie „BSP Common“ ist nicht eindeutig.
jq '[.components[] | select(.purl)] | length' sbom_cdx.json1
jq '[.components[] | select(.cpe)] | length' sbom_cdx.json0
Prüfung 4: Hashes
Die TR-03183-2 verlangt je Komponente einen SHA-512-Hash der ausgelieferten Datei. Mit ihm lässt sich prüfen, ob die Stückliste zu dem passt, was tatsächlich geliefert wurde.
jq '[.components[] | select(.hashes)] | length' sbom_cdx.json0
Prüfung 5: fehlen eingebaute Bibliotheken?
Das ist die wichtigste Prüfung und die einzige, die nicht in der SBOM selbst steckt: Sie brauchen eine zweite Quelle, die zeigt, was im Produkt ist. Für Firmware ist das der Build, der auf das Gerät geht. Eine Bibliothek, die dort Funktionen hinterlässt, gehört in die SBOM.
ls Middlewares/Third_PartyFatFs FreeRTOS LibJPEG LwIP mbedTLS
grep -ciE 'lwip|mbed|freertos|fatfs|libjpeg' sbom_cdx.json0
Was Sie mit dem Ergebnis tun
- 01
Je Release eine SBOM
aus dem Build, der ausgeliefert wird.
- 02
Fehlende Bibliotheken ergänzen
alles, was der Linker übernommen hat, mit Version.
- 03
Kennungen nachtragen
purl oder CPE je Komponente, damit der Abgleich mit Schwachstellen trifft.
- 04
Format anheben
CycloneDX 1.6 oder SPDX 3.0.1, wenn ein Kunde nach der TR-03183-2 fragt.
Was LegacyMind dabei automatisch macht
Sie laden Ihre vorhandene SBOM an das Gerät und die Firmware dazu. LegacyMind gleicht die SBOM gegen Schwachstellen ab und liest aus der Firmware das Inventar, das tatsächlich im Image steckt. Beides steht am selben Gerät nebeneinander.
Die Konformitätsaussage treffen Sie. Diese Seite und unsere Berichte liefern technische Feststellungen als Grundlage dafür.
Häufige Fragen
01Wir erzeugen die SBOM schon für die Funkanlagenrichtlinie. Reicht das für den CRA?
Wenn sie je Release aus dem ausgelieferten Build entsteht und jede eingebaute Komponente mit Version und Kennung nennt, ja. Die fünf Prüfungen zeigen, ob das zutrifft.
02Muss die SBOM auch transitive Abhängigkeiten enthalten?
Der CRA verlangt zumindest die obersten Abhängigkeiten (Anhang I Teil II Nr. 1). Die TR-03183-2 verlangt die Auflösung der Abhängigkeiten für alles, was zum Lieferumfang gehört.
03Gehören Schwachstellen in die SBOM?
Die TR-03183-2 schließt das aus: Eine SBOM mit Schwachstellen ist nicht TR-konform (§ 8.1.14). Schwachstellen gehören in CSAF mit VEX-Profil, weil sich die Schwachstellenlage täglich ändert, die Stückliste nur mit dem Release.