Hoe evalueer je een SBOM-generator voor embedded firmware

Vindt hij code zonder manifest?

De meeste firmware-afhankelijkheden zijn door een persoon in de tree gekopieerd. Er is geen package.json, geen lockfile, vaak geen versiebestand. Tools die werken door manifesten te lezen, waaronder Syft en Trivy in hun standaardmodi, geven voor deze projecten weinig of niets terug. Dat is geen bug in die tools; het is waarvoor ze zijn ontworpen.

Let op de identificatie van vendored bibliotheken zoals FreeRTOS, lwIP, Mbed TLS of FatFs vanuit de broncode zelf. Kijk hoeveel het tool kan ontdekken buiten wat een package manager heeft gedeclareerd.

Krijgt hij de versie goed?

Een componentnaam zonder versie is nutteloos voor vulnerability matching. Vendored code maakt versies lastig: de versie kan in een header-macro, een changelog, of nergens staan. Siliciumleveranciers leveren ook aangepaste forks, dus "FreeRTOS 10.4.3" in een ST- of NXP-SDK is mogelijk niet byte-identiek aan upstream.

Vergelijk gerapporteerde versies met je ground truth. Vraag hoe het tool omgaat met ontbrekende versie-informatie, onzekerheid en aangepaste code, en controleer of het bewijs de gerapporteerde versie ondersteunt.

Rapporteert hij wat wordt uitgeleverd, of wat in de repo staat?

Een vendor-SDK kan honderden componenten bevatten. Je build compileert er misschien een dozijn, en de linker gooit ongebruikte delen daarvan weg. Een SBOM van de repository overrapporteert, wat betekent dat je team kwetsbaarheden triageert in code die nooit een apparaat bereikt. Een SBOM van alleen de binary onderrapporteert, omdat gecompileerde C zeer weinig identificerende informatie behoudt.

Vraag of het tool onderscheid maakt tussen code in de tree, gecompileerde code en code die in het image is gelinkt. Controleer de gerapporteerde componenten tegen je build om te begrijpen of de SBOM de repository of de firmware die je uitlevert beschrijft.

Gaat hij om met statisch linken en toolchain-bibliotheken?

Firmware is statisch gelinkt. Zodra de linker alles tot één image samenvoegt, zijn de componentgrenzen weg, en binary-scanners worstelen. Er zit ook code in je image die nooit in je broncode-tree verschijnt: de C-runtime (newlib of de IAR-runtime-bibliotheek), libgcc en startup-code uit de toolchain. Die hebben versies, licenties en af en toe kwetsbaarheden.

Controleer of statisch gelinkte bibliotheken en runtime-componenten van de toolchain in de SBOM verschijnen. Vraag welke build- of linker-informatie het tool nodig heeft om code te identificeren die van buiten je broncode-tree komt.

Werkt hij met je daadwerkelijke build?

Vraag wat het tool van je nodig heeft. Sommige vereisen een specifiek build-systeem (Zephyr's west spdx en Yocto's create-spdx zijn goed en werken alleen binnen die ecosystemen). Sommige vereisen een rebuild met een wrapper om de compiler. Sommige hebben een cloud-upload van broncode of binaries nodig, wat ze uitsluit voor defensie- en veel medische teams.

Evalueer het tool met je daadwerkelijke IAR-, Keil-, Make- of CMake-build. Begrijp de integratie-inspanning, eventuele vereiste build-wijzigingen, en of het offline kan draaien als je team dat nodig heeft. Toets vereisten voor broncode- en binary-uploads vroeg aan je randvoorwaarden.

Kun je zien waarom hij elke identificatie deed?

Elk tool in dit domein gebruikt heuristieken, en heuristieken maken fouten. Wat telt is of je ze kunt controleren. Voor elke component zou je het bewijs moeten kunnen zien: welke bestanden, welke compile-regel, welke hash of string overeenkwam, en hoe zeker het tool is. Een auditor zal je dezelfde vraag stellen.

Inspecteer het bewijs voor afzonderlijke componenten, inclusief onzekere identificaties. Vraag hoe vertrouwen wordt gecommuniceerd en of je team de resultaten kan beoordelen en corrigeren.

Komen de identificatoren overeen met kwetsbaarheidsdatabases?

Een SBOM is slechts zo nuttig als zijn identificatoren. Embedded-componenten zijn slecht gedekt: veel hebben geen CPE in de NVD, PURL's zijn inconsistent voor code die niet in een package-registry staat, en vendor-forks mappen niet netjes op upstream-entries. Draai de SBOM door een vulnerability-scanner en kijk in beide richtingen: bekende CVE's die werden gemist, en valse matches.

Beoordeel de CPE- en PURL-mappings tegen bekende componenten en kwetsbaarheden. Vraag hoe het tool omgaat met componenten zonder gevestigde mapping, en of correcties blijven bestaan over volgende runs heen.

Legt hij genoeg vast om de SBOM conform te kunnen maken?

Toezichthouders verwachten dat elke component specifieke data draagt. De NTIA Minimum Elements van 2021 vroegen om leverancier, naam, versie, unieke identificatoren, afhankelijkheidsrelaties, SBOM-auteur en tijdstempel. De CISA-update van 2026 voegt component-hashes, licenties, de naam van het genererende tool en de generatiecontext toe, en de eisen van FDA, EU CRA en BSI TR-03183 gaan verder. Verwacht niet dat een generator dat allemaal invult op scanmoment. Volledige verrijking tijdens het scannen van code is moeilijk, en voor embedded code vaak onmogelijk: een vendored bestand draagt geen leveranciersgegeven, en een in je tree gekopieerde bibliotheek heeft geen registry-entry om op te zoeken. Leveranciersnamen, genormaliseerde licenties en end-of-life-data komen van buiten de code en worden beter achteraf toegevoegd door een SBOM-managementplatform.

Wat de generator wél moet doen, is alles vastleggen wat alleen de broncode en de build kunnen leveren, omdat geen enkel downstream-tool het later kan herstellen: hashes, de licentie- en copyrighttekst die daadwerkelijk in de broncode is gevonden, accurate namen en versies, PURL- en CPE-identificatoren waar die te bepalen zijn, afhankelijkheidsrelaties, en de toolnaam en generatiecontext. Test beide helften. Controleer wat de generator vastlegde, laad de SBOM daarna in het managementplatform dat je wilt gebruiken, draai de verrijking ervan, en scoor het resultaat met een tool zoals sbomqs.

Is de output reproduceerbaar en standaard-valide?

Bouw dezelfde commit twee keer en vergelijk de SBOM's. Ze zouden identiek moeten zijn op tijdstempels na. Valideer de output daarna tegen het CycloneDX- of SPDX-schema, en scoor die met een open-source-kwaliteitstool zoals sbomqs. Als je uitlevert onder FDA 524B, de EU CRA of BSI TR-03183, controleer de vereiste velden nu, niet de week vóór indiening.

Controleer op consistente componentdata over runs heen, valide output, en de velden die je team vereist. Bevestig dat de SBOM kan worden geconsumeerd door de andere tools in je workflow.

Hoe is de prijsstelling opgebouwd?

Voer het prijsgesprek vooraf. Commerciële generatoren rekenen mogelijk per SBOM, per repository of per scanrun. Vraag wat als factureerbare eenheid geldt, en schat de kosten aan de hand van je verwachte aantal projecten, build-varianten en CI-runs. Een prijs die tijdens een proof of concept redelijk lijkt, kan er anders uitzien wanneer het tool bij elke build draait.

Open-source-generatoren zijn doorgaans gratis te gebruiken, al kosten setup en onderhoud nog steeds engineering-tijd. Als een open-source-tool aan je eisen voldoet en goed werkt in je omgeving, gebruik het.

Wat is de evaluatietijdlijn?

Stel de tijdlijn vast voordat je begint, en houd elk tool eraan. Een redelijk plan is één tot drie weken in totaal: een eerste SBOM binnen een dag of twee na installatie, een week om de bovenstaande tests tegen je ground truth te draaien, en een week om een tweede project met een andere toolchain of target te proberen, want een tool dat voor het eerste project door de engineers van de leverancier is afgestemd, struikelt vaak bij het tweede. Houd bij wie het werk deed. Een evaluatie die alleen slaagt met de leverancier aan het stuur is een dienstverleningstraject, geen tool.