Firmware-SBOM-nauwkeurigheid: source vs binary en hoe je bewijst wat er wordt uitgeleverd
| Interlynk
Waarom firmware-SBOM's elkaar tegenspreken: broncode-scans zien wat aanwezig is, binaire analyse ziet het image maar leidt de identiteit af, en build-bewuste generatie leest de echte build. Hoe je bepaalt welke klopt en bewijst wat er werkelijk is uitgeleverd.
Aanwezig in de repository is niet hetzelfde als uitgeleverd in de binary
Laat drie SBOM-tools over hetzelfde firmware-project lopen en je krijgt mogelijk drie verschillende antwoorden. Dat betekent niet per se dat een ervan kapot is. Elke aanpak kijkt naar een ander deel van het pad van broncode naar uitgeleverd image.
Een broncode-scan rapporteert wat hij kan identificeren in de repository en de projectmetadata. Een binaire analyse rapporteert wat ze kan herkennen in het firmware-image. Een build-bewuste generator rapporteert welke inputs de build heeft geselecteerd en, afgestemd op de linker map, welke daarvan in het uiteindelijke image zijn gebleven.
Bij embedded software zit de moeilijkheid van SBOM-nauwkeurigheid precies in de kloof tussen "aanwezig" en "uitgeleverd". Die kloof bepaalt ook of een kwetsbaarheidsmelding een echt risico is of een component dat je team nu op toepasselijkheid moet onderzoeken.
Deze gids legt uit hoe de drie aanpakken verschillen, waar elk het beste werkt en hoe je een bewijsspoor opbouwt voor wat er werkelijk is uitgeleverd.
Het korte antwoord
Een broncode-scan is nuttig om te begrijpen wat een project bevat, maar kan componenten rapporteren die nooit in een bepaald image terechtkomen. Binaire en firmware-analyse beginnen bij het artefact dat wordt uitgeleverd en kunnen code identificeren die er echt is, al worden identiteit en versie van componenten vaak afgeleid uit de binary. Build-bewuste generatie leest de inputs en de configuratie van de build om te bepalen welke componenten binnen de scope vallen en waarom, en stemt ze vervolgens af op de linker map voor het specifieke image. Wanneer je de build beheert, geeft het combineren van build-bewijs met image-specifiek bewijs, samen met het vastleggen van wat onbekend blijft, de sterkste basis voor een verdedigbare firmware-SBOM.
De juiste methode hangt af van de vraag die je moet beantwoorden.
Vier lagen tussen je bronboom en je firmware
Veel nauwkeurigheidsproblemen ontstaan doordat verschillende vragen als één worden behandeld. Een typische embedded build heeft minstens vier technische lagen, plus een vijfde vraag over toewijzing:
Aanwezig in de repository. Dit omvat vendor-SDK's, RTOS-ports, HAL-drivers, crypto- en netwerkbibliotheken, test-utilities, voorbeeld-apps en oude compatibiliteitscode.
Geselecteerd door de build-configuratie. Dit zijn de targets en bestanden die de specifieke CMake-, Make- of IAR-configuratie binnenhaalt.
Gecompileerd of aangeleverd als build-input. Dit omvat de voor de build gecompileerde broncode, kant-en-klare statische archieven en andere artefacten die in de link terechtkomen.
Behouden in het uiteindelijke firmware-image. Dit zijn de delen die linken en dead-code-eliminatie overleven en werkelijk worden uitgeleverd.
Toe te wijzen aan een component met herkomst. De behouden code moet met bewijs dat je team kan verdedigen aan een bekend component en versie worden gekoppeld.
Een kwetsbaar component in een gedeelde third_party-map kan op de eerste laag staan en het uiteindelijke image nooit bereiken. De hele map als uitgeleverd rapporteren kan een grote reeks kwetsbaarheidsmeldingen opleveren die niet op dat image van toepassing zijn.
Het omgekeerde komt ook vaak voor. Een statisch archief of een toolchain-runtime kan op laag drie of vier in de build binnenkomen zonder in een pakketmanifest te verschijnen. Een scan die alleen manifesten leest, kan code missen die wel wordt uitgeleverd.
Broncode-SBOM's zijn sterk voor projectinventaris
Een broncode-scan is een nuttig startpunt. De tool doorloopt de repository, leest pakketmanifesten, lockfiles en meegeleverde broncode (vendored source) en produceert een CycloneDX- of SPDX-document. Hij is snel en heeft geen build nodig.
Dat maakt hem nuttig voor een basisvraag: wat bevat dit project?
Stel dat de repository third_party/mbedtls bevat. Een broncode-scan kan vaststellen dat het project mbedTLS bevat. Hij kan niet vaststellen dat mbedTLS voor een bepaald board is gecompileerd, in een bepaald image is gelinkt of na dead-code-eliminatie is behouden.
Bij serverzijdige toepassingen, waar het grootste deel van de repository vaak wordt uitgeleverd, kunnen projectinventaris en uitgeleverde software redelijk dicht bij elkaar liggen. Firmware is anders. Een grote bronboom kan terugvallen tot een klein, target-specifiek image. Daardoor kan een broncode-scan veel meer mogelijke componenten rapporteren dan er in een enkel image aanwezig zijn.
Binaire en firmware-analyse begint bij het artefact
Binaire analyse werkt vanaf het andere eind van het proces. Ze inspecteert een gecompileerde binary of firmware-image en identificeert de componenten die ze kan herkennen. Dit is de juiste aanpak wanneer het uitgeleverde artefact alles is wat je hebt, zoals firmware van derden of oudere firmware die je team niet heeft gebouwd. Aanbieders als ONEKEY en Binarly zijn rond dit gebruik gebouwd.
Binaire analyse kan zeer effectief zijn wanneer het image sterk bewijs behoudt, waaronder symbolen, ingebedde metadata of herkenbare versiereeksen. In die gevallen kan ze uit het artefact zelf resultaten met hoge betrouwbaarheid leveren.
De lastigere vraag is herkomst. Identiteit en versie worden vaak afgeleid uit signatures, strings en heuristieken. De betrouwbaarheid kan sterk dalen bij gestripte of statisch gelinkte builds. Een binaire analyse kan aantonen dat een bepaalde implementatie waarschijnlijk aanwezig is, zonder genoeg informatie om de exacte upstream-bron, fork of versie te bepalen.
Dat maakt binaire analyse bijzonder waardevol wanneer je alleen het image hebt. Wanneer je de build beheert, kunnen build-gegevens extra bewijs leveren over waar de code vandaan komt en waarom die bij een bepaald target hoort.
Build-bewuste generatie gebruikt het bewijs uit de build
Build-bewuste generatie leest de build zelf. Ze draait na je bestaande build zonder opnieuw te bouwen en leest de compiler- en linker-aanroepen die de build voortbrengt. Dat legt details bloot die een scan van alleen de repository niet kan zien, waaronder de gekozen configuratie, bronbestanden, compile-opties, include-paden, archief-inputs en linker-inputs.
Ze levert twee verwante soorten bewijs:
Build-bewijs laat zien waarom een input bij het gebouwde target hoort.
Linker-map-bewijs laat zien of en hoe die input in het uiteindelijke image is behouden.
Samen geven deze gegevens een preciezer beeld dan aannemen dat alles in de repository is uitgeleverd. Ze vermijden ook om een binaire signature te behandelen als bewijs van een exacte upstream-versie.
Build-bewijs onderbouwt scope en herkomst. Identiteit en versie van een component blijven afhankelijk van bron- of leveranciersmetadata. Wanneer die gegevens niet bevestigd kunnen worden, moet de SBOM dat aangeven in plaats van de velden met een gok te vullen.
Dit is de aanpak die een groot deel van de kloof dicht tussen wat aanwezig is en wat bij firmware wordt uitgeleverd. Daarvoor is Interlynks lynkctl gebouwd.
Source vs binary vs build-bewust in een oogopslag
Vraag | Broncode-scan | Binaire of firmware-analyse | Build-bewuste generatie |
|---|---|---|---|
Ziet wat er in het project aanwezig is | Ja | Nee | Ja |
Ziet wat het image heeft behouden | Beperkt | Ja | Ja, afgestemd op de linker map |
Weet welke configuratie het selecteerde | Soms | Nee | Ja |
Identiteit en versie van het component | Uit manifesten en broncode, indien beschikbaar | Afgeleid uit het artefact, met wisselende betrouwbaarheid | Uit build-bewijs plus bron- of leveranciersmetadata |
Verwerkt statische archieven en meegeleverde code | Gedeeltelijk | Kan bijgedragen code detecteren, maar identiteit kan ondoorzichtig zijn | Zichtbaar als build- en link-inputs, herkomst kan meer bewijs vereisen |
Vereist de broncode en build | Alleen broncode | Geen van beide | Draait na de build, zonder opnieuw te bouwen |
Beste keuze bij | Projectinhoud begrijpen | Een artefact analyseren wanneer de build niet beschikbaar is | Firmware bouwen en image-specifieke herkomst nodig hebben |
Zo bewijs je wat er werkelijk is uitgeleverd
SBOM-nauwkeurigheid gaat niet over het maken van de grootst mogelijke componentenlijst. Het gaat erom de scope van elk component duidelijk te maken en het bewijs erachter te bewaren.
Deze praktijken helpen om een SBOM te maken die engineering-, security- en complianceteams kunnen gebruiken:
Stem de SBOM af op de linker map van het image. Het map-bestand is specifiek voor een image. Een bootloader, een beveiligd firmware-image en een applicatie-image zijn aparte SBOM-onderwerpen wanneer ze apart worden uitgeleverd of bijgewerkt. Genereer en stem een SBOM af voor elk ervan.
Houd detectie gescheiden van herkomst. Is een component gevonden via een binaire signature, leg dat dan vast als detectiebewijs. Is de bronrevisie bekend uit de build of een leveranciersgegeven, leg dat dan vast als herkomst. Dit zijn verwante beweringen, maar niet dezelfde.
Behandel versies als afgeleid tot ze bevestigd zijn. Komt de identiteit uit binaire heuristieken, markeer haar dan zo. Bevestig haar aan de hand van build- of bronbewijs voordat je er remediatiebeslissingen op baseert.
Leg vast wat onbekend blijft. Kan de leverancier of versie van een kant-en-klaar archief niet worden vastgesteld, zeg dat dan. Een transparante SBOM is nuttiger dan een die elk veld met een niet-onderbouwde waarde vult.
Houd build-tools gescheiden van uitgeleverde componenten. De compiler, linker en het build-systeem horen bij de build-omgeving. Een runtime-archief dat werkelijk in het image wordt gelinkt, zoals
libgcc.a, is iets anders en moet als uitgeleverde software worden behandeld.
Een uitgewerkt voorbeeld vind je in Trusted Firmware-M op een STM32H5. Meer achtergrond bij de onderliggende uitdaging lees je in waarom SBOM's voor C/C++ lastig zijn.
Hoe Interlynk hierin past
Interlynks generator lynkctl is de build-bewuste optie. Hij draait na een bestaande Make-, CMake-, IAR- of TI-Code-Composer-build zonder opnieuw te bouwen. Hij leest de compiler- en linker-aanroepen en stemt ze af op de linker map, zodat de SBOM weergeeft wat het image heeft behouden, in plaats van alleen wat er in de repository staat.
Elk component bevat een bewijsrecord met gegevens zoals het bronbestand, de compile-regel en een betrouwbaarheidsniveau. Zo kunnen engineering- en securityteams zien waarom een component verschijnt en gevestigd bewijs onderscheiden van resterende onzekerheid.
lynkctl kan in een air-gapped omgeving draaien en levert CycloneDX 1.6+ en SPDX 3+.
Voor gereguleerde producten kan dit bewijs de technische documentatie achter een SBOM versterken. Het is een implementatiekeuze, geen regelgevingsformaat. FDA 524B stelt SBOM-verplichtingen voor cyber devices binnen de reikwijdte ervan, en de EU Cyber Resilience Act vereist een machineleesbare SBOM die ten minste de top-level afhankelijkheden dekt. Welk bewijs achter die SBOM wordt vastgelegd, hangt af van je workflow en je tools.
Lees meer over de C/C++ SBOM-generator voor embedded software, lees de bredere gids over SBOM's voor embedded en IoT-systemen of vergelijk de opties in de vier manieren om een SBOM uit een CMake-build te halen.
Veelgestelde vragen
Waarom geven twee SBOM-tools verschillende resultaten voor dezelfde firmware?
Ze gebruiken verschillend bewijs. Een broncode-scan rapporteert wat hij in het project kan identificeren. Een binaire analyse rapporteert wat ze in het uitgeleverde image herkent. Een build-bewuste generator rapporteert welke inputs de target-build heeft geselecteerd en, afgestemd op de linker map, welke daarvan het image heeft behouden. De verschillen zijn het grootst bij firmware, waar een grote bronboom kan terugvallen tot een klein, target-specifiek image.
Is een broncode-SBOM of een binaire SBOM nauwkeuriger voor firmware?
Geen van beide is universeel nauwkeuriger. Ze beantwoorden verschillende vragen. Een broncode-SBOM is nuttig om projectinhoud en mogelijke afhankelijkheden te begrijpen. Binaire analyse is nuttig om code in een uitgeleverd artefact te identificeren. Wanneer je de build beheert, kan build-bewijs sterkere herkomst voor het target geven, vooral afgestemd op image-specifiek bewijs.
Hoe weet ik wat er werkelijk in mijn firmware-image is uitgeleverd?
Begin met de exacte release-configuratie. Leg de build-inputs vast en genereer de bijbehorende linker map. Stem die gegevens af op het uiteindelijke image en genereer vervolgens één SBOM per apart uitgeleverd image in plaats van bootloader en applicatie tot één onderwerp samen te voegen. Bewaar bewijs per component zodat elke vermelding te herleiden is naar de informatie die haar onderbouwt.
Verwerkt binaire analyse statische bibliotheken correct?
Ze kan code uit een statische bibliotheek detecteren wanneer die code herkenbaar bewijs in het image achterlaat. Het lastigere deel is toewijzing. De binary bevat mogelijk niet genoeg informatie om de exacte bibliotheek, versie of fork te bepalen. Wanneer je de build beheert, kan build-bewijs de identiteit en rol van het archief onderbouwen. De linker map kan dan laten zien of het aan het image heeft bijgedragen.
Welke aanpak moet ik gebruiken voor een FDA- of CRA-indiening?
De regelgeving schrijft niet één SBOM-generatiemethode voor. Kies een workflow die een volledige, machineleesbare SBOM voor het betreffende product produceert en het ondersteunende bewijs bewaart dat je kwaliteits-, security- en regelgevingsprocessen vereisen. Voor een build die je beheert, kan build-bewuste generatie nuttige, image-specifieke herkomst geven. Voor firmware van derden of oudere firmware waarbij je alleen het image hebt, kan binaire analyse nodig zijn. Sommige teams gebruiken beide aanpakken. Zie FDA 524B voor meer informatie.
Verder lezen
Vergelijk de generatiemethoden in de vier manieren om een SBOM uit een CMake-build te halen, bekijk het uitgewerkte voorbeeld in Trusted Firmware-M op een STM32H5 en verken de categorie in onze gids over de beste SBOM-tools.