Een SBOM genereren voor een webapplicatie is meestal eenvoudig. Een package manager heeft de afhankelijkheidsgraaf al opgelost, namen en versies toegekend en vastgelegd in een lockfile. Een SBOM-generator hoeft die gestructureerde data eigenlijk alleen nog te vertalen naar CycloneDX of SPDX.
Embedded firmware is anders.
Een typisch firmware-image combineert mogelijk gegenereerde code, een leveranciers-SDK, een RTOS, middleware, gekopieerde source-trees, statische archieven, runtime-bibliotheken van de compiler, propriëtaire binaire blobs en applicatiecode. Sommige componenten worden in een IDE geselecteerd. Andere verschijnen alleen in compiler-commando's, linker-scripts of de uiteindelijke linker-map. Een universeel pakketmanifest ontbreekt vaak – en er is geen enkel bestand dat de hele waarheid vertelt.
De terugkerende vragen in de community's van STMicroelectronics, NXP en Nordic wijzen allemaal op hetzelfde probleem:
Hoe maak ik een SBOM voor de firmware die ik daadwerkelijk uitlever – en niet alleen voor de SDK-map waarmee ik ben begonnen?
Deze Q&A beantwoordt die vraag – en de lastige vragen erachter.
Wat is een embedded of IoT-SBOM?
Een embedded SBOM is een machineleesbare inventaris (een softwarestuklijst) van de softwarecomponenten die horen bij een specifieke firmware-release van een apparaat.
Ze moet minimaal het product en de release identificeren, de meegeleverde third-party- en open-sourcecomponenten, hun versies en leveranciers, en de relaties daartussen. Waar mogelijk bevat ze ook licenties, hashes, externe identifiers zoals Package URL's en bewijs dat uitlegt hoe elke component is geïdentificeerd.
De belangrijkste woorden zijn specifieke firmware-release. Een inventaris van alles wat in een leveranciers-SDK beschikbaar is, is nuttige leveranciersinformatie – maar niet automatisch de SBOM van uw product.
Waarom zijn SBOM's makkelijker voor web-, mobile- en desktopapplicaties?
Moderne applicatie-ecosystemen bieden doorgaans drie dingen:
Standaardmanifesten en lockfiles zoals
package-lock.json,pom.xml,packages.lock.jsonofpoetry.lockCentrale registries met genormaliseerde pakketnamen, versies, licenties en identifiers
Package managers die directe en transitieve afhankelijkheden vóór de build oplossen
Embedded C en C++ hebben geen universeel equivalent. Afhankelijkheden worden naar Drivers/ gekopieerd, als Git-submodules toegevoegd, als ZIP-archieven geleverd, via een grafische configurator geselecteerd of gelinkt vanuit een propriëtaire toolchain.
De afhankelijkheidsgraaf bestaat wel, maar ligt verspreid over projectbestanden, build-commando's, include-paden, gegenereerde configuratie, archieven en linker-uitvoer.
Lost een door de leverancier geleverde SDK-SBOM het probleem op?
Ze lost een deel van het probleem op.
ST publiceert inmiddels CycloneDX-SBOM's bij een groeiend aantal STM32Cube-pakketten; de STM32CubeF1-repository bevat bijvoorbeeld een sbom_cdx.json. Dat is waardevol, want de leverancier kan de componenten, versies, herkomst en licenties van zijn eigen distributie het best identificeren.
Maar een SDK-SBOM beantwoordt de vraag:
Welke componenten heeft de leverancier in deze SDK-release geleverd?
Uw product-SBOM moet beantwoorden:
Welke componenten, versies, patches, configuraties en binaire objecten zijn in deze firmware-build gebruikt?
Dat is niet dezelfde vraag. Een volledig STM32Cube-pakket kan drivers voor veel boards bevatten, voorbeelden die u nooit compileert, meerdere middleware-opties en evaluatiecomponenten die nooit in uw product terechtkomen. Uw team patcht misschien een HAL-driver, vervangt een middleware-versie of voegt een RTOS en een propriëtaire bibliotheek toe.
Behandel de leveranciers-SBOM als gezaghebbende upstream-metadata. Stem haar af op uw build- en link-bewijs om de product-SBOM te maken.
Kan STM32CubeMX de definitieve SBOM voor mijn firmware genereren?
STM32CubeMX-metadata is nuttig, maar configuratie-intentie alleen is niet genoeg.
Het .ioc-bestand kan onder meer identificeren:
MCU-familie en -type
STM32Cube-firmwarepakket en versie
CubeMX-versie
Geconfigureerde middleware
Project- en toolchain-keuzes
Dat is sterke context. Het kan een SBOM-generator vertellen dat een project op STM32F4 mikt en een bepaald STM32Cube-firmwarepakket declareert. Het bewijst op zichzelf niet dat elke geconfigureerde middleware-component de uiteindelijke binary heeft gehaald.
Projecten driften. Ontwikkelaars regenereren maar een deel van een project, wijzigen gegenereerde bestanden, upgraden middleware handmatig, sluiten bestanden uit in de IDE of houden een oud .ioc-bestand aan nadat de build is veranderd.
De betrouwbare volgorde van bewijs is:
Leveranciersmetadata vertelt u wat de SDK bevat.
Project- en configuratormetadata vertelt u wat de build wil gebruiken.
Compiler- en buildsysteemmetadata vertelt u wat er is gecompileerd.
Linker-bewijs vertelt u wat het firmware-artefact heeft gehaald.
Handmatige, gecontroleerde invoer dicht de resterende gaten.
Waarom is het scannen van de source-directory niet genoeg?
Een directory-scan ziet beschikbaarheid, geen gebruik.
Als een repository FreeRTOS, lwIP, Mbed TLS, FatFs, USB-host, USB-device en tientallen board-voorbeelden bevat, rapporteert een scanner over de hele tree ze mogelijk allemaal. Dat levert false positives op: componenten die in de source-tree staan maar geen deel uitmaken van de uitgeleverde firmware.
Het omgekeerde probleem komt ook voor. Een source-scan kan missen:
Voorgecompileerde
.a-archievenPropriëtaire binaire bibliotheken
Runtime-bibliotheken van de compiler
Buiten de repository gegenereerde code
Afhankelijkheden die via een extern SDK-pad worden gerefereerd
Objecten die pas tijdens het linken binnenkomen
Source-scans blijven nuttig om gekopieerde (vendored) code te identificeren en licentiebewijs te extraheren. Ze worden veel betrouwbaarder wanneer ze worden begrensd door de build-graaf en afgestemd op de uiteindelijke link.
Horen ongebruikte of door de linker verwijderde componenten in de SBOM?
Er zijn twee verdedigbare benaderingen.
Voor een klantgerichte product-SBOM laten teams vaak componenten weg waarvan bewezen is dat ze niet in het uitgeleverde artefact zitten. Dat houdt kwetsbaarheidsresultaten gefocust op het product.
Voor engineering- en auditworkflows kan het waardevol zijn die componenten te behouden met een expliciete „excluded"-scope. Dat bewaart het bewijsspoor en verklaart waarom een component die in het project zichtbaar is, niet als uitgeleverd verschijnt.
De belangrijke regel: meng „aanwezig", „beschikbaar", „optioneel" en „uitgesloten" nooit stilzwijgend. Scope moet expliciet zijn en door bewijs onderbouwd.
Hoe moeten statisch gelinkte bibliotheken worden weergegeven?
Een statische bibliotheek hoort als component te worden weergegeven wanneer ze een betekenisvolle identiteit heeft: naam, versie, leverancier of herkomst, en idealiter een hash of externe identifier.
Het lastige is bewijzen of er code uit het archief is geselecteerd. Dat libfoo.a op de linker-commandoregel staat, bewijst niet dat de linker er een member uit heeft gehaald. Een linker-map laat vaak zien welke archief-members aan het uiteindelijke image hebben bijgedragen.
Wanneer een statisch archief propriëtair is of versiemetadata mist, leg dan minimaal vast:
Leverancier en bibliotheeknaam
Release- of leveringsidentifier
SHA-256-hash
Leveringsbron
Licentieclassificatie
Support- of end-of-life-informatie, indien beschikbaar
Verandert het archief terwijl de bestandsnaam gelijk blijft, dan wordt de hash extra belangrijk.
Hoe zit het met propriëtaire binaire blobs, SoftDevices, radio-stacks en bootloaders?
Ze horen in de SBOM wanneer ze deel uitmaken van het geleverde product, ook als hun binnenkant ondoorzichtig is.
De discussie in de Nordic-community rond de oudere nRF5-SDK vat de praktijk goed samen: scannen door derden helpt, maar voorgecompileerde bibliotheken en niet automatisch te ontdekken details vragen soms om handmatige invoer. Een binaire component is niet vrijgesteld enkel omdat de broncode ontbreekt.
Leg voor een ondoorzichtige component de best beschikbare identiteit vast:
Veld | Waarom het belangrijk is |
|---|---|
Naam | Stabiele, menselijk leesbare identiteit |
Versie of release-ID | Correlatie met updates en kwetsbaarheden |
Leverancier | Eigenaarschap en escalatiepad |
SHA-256 | Exacte identiteit van de geleverde bytes |
Leveringsbron | Traceerbaarheid voor inkoop en audit |
Licentie | Gebruiks- en distributieverplichtingen |
Product- of artikelnummer | Correlatie met leveranciersdocumentatie |
Einddatum support | Langetermijnrisico van het product |
Referentie naar leveranciers-SBOM of VEX | Kwetsbaarheidscontext downstream |
Een component met beperkte metadata is nog altijd beter dan een onzichtbare component.
Horen compilers, IDE's, debuggers en flash-tools in de SBOM?
Scheid software in het product van software waarmee het product wordt gebouwd.
Compiler, IDE, codegenerator, debugger en flash-utility worden doorgaans niet in de apparaatfirmware meegeleverd. Ze horen niet als gewone runtime-componenten van het product te worden weergegeven. Het blijven wel belangrijke build-afhankelijkheden; leg ze vast in de build-provenance of als build-tool-relaties.
Runtime-code van de compiler is een ander geval. Bibliotheken zoals libgcc, C-runtime-bibliotheken, IAR-DLIB-varianten of andere runtime-support kunnen statisch in de firmware zijn gelinkt. Die bytes zijn deel van het artefact en horen in aanmerking te komen voor de product-SBOM.
Dit onderscheid voorkomt twee veelgemaakte fouten: gelinkte runtime-code weglaten – en ten onrechte claimen dat een IDE of debugger op het apparaat is geïnstalleerd.
Hoe ga je om met gegenereerde code?
Gegenereerde code moet herleidbaar zijn naar zowel de geleverde bronbestanden als de generator-context.
CubeMX-gegenereerde initialisatiecode kan na generatie zijn aangepast. De product-SBOM moet het relevante STM32Cube-pakket en de gelinkte HAL- of middleware-componenten identificeren, terwijl de build-provenance de gebruikte CubeMX-versie en -configuratie vastlegt.
Behandel „gegenereerd door tool X" niet als vervanging voor componentidentiteit. Generator, template- of SDK-pakket, geselecteerde modules, lokale wijzigingen en het uiteindelijk gelinkte resultaat zijn afzonderlijke feiten.
Hoe ga ik om met patches op leveranciers- of open-sourcecode?
Behoud de upstream-identiteit en leg vast dat de component gewijzigd is.
Een praktische registratie omvat:
Upstream-componentnaam en -versie
Upstream-repository of leverancier
Exacte lokale commit- of source-hash
Patch-set of interne wijzigingsreferentie
Licentie
Relatie met de productrelease
Verzin geen nieuwe versie die op een upstream-release lijkt. Gebruik een lokale qualifier of property die de gewijzigde staat duidelijk aangeeft. Zo blijft kwetsbaarheids-matching werken, terwijl duidelijk is dat de bytes niet identiek zijn aan de leveranciersrelease.
Wat te doen als een component geen versie heeft?
Niet gokken.
Probeer, in deze volgorde:
Release notes of pakketmetadata van de leverancier
Git-tag en commit
Source-headers of versiemacro's
Archiefpad en toolchain-metadata
Cryptografische hash plus leveringsidentifier
Een gecontroleerde handmatige override
Blijft een versie onbekend, zeg dat dan – en geef een diagnose af. Een transparant „onbekend" is beter verdedigbaar dan een zelfverzekerde maar onjuiste versie.
Zijn headers afhankelijkheden, componenten of gewoon bestanden?
Dat hangt af van hun rol.
Headers kunnen zijn:
Onderdeel van een grotere component die al in de SBOM staat
Header-only-bibliotheken die in de applicatie worden meegecompileerd
Gegenereerde configuratie-input
Publieke interfaces van een binaire bibliotheek
Ongebruikte bestanden die simpelweg in een SDK staan
Elke header als top-level softwarecomponent opnemen levert meestal ruis op. SBOM-detail op bestandsniveau kan nuttig zijn voor bewijs of audits, maar componentidentiteit hoort doorgaans op het niveau van bibliotheek, SDK-module, RTOS, middleware of applicatiemodule te blijven.
Voor header-only-code leveren compile-afhankelijkheden en include-paden sterker bewijs dan een directory-scan alleen.
Hoe genereer ik SBOM's voor verschillende firmware-varianten?
Genereer een SBOM per uitleverbare configuratie.
Een debug-build, release-build, bootloader, applicatie-image, board-revisie, regiospecifieke radioconfiguratie en feature-flag-combinatie kunnen verschillende componenten bevatten. Eén „master-SBOM" voor de repository kan ze niet betrouwbaar allemaal representeren.
Elke SBOM hoort gekoppeld te zijn aan:
Product en firmwareversie
Build-ID of artefact-hash
Doel-MCU of hardware-revisie
Build-configuratie
Feature- of productvariant
Source-revisie
Toolchain-versie
Tijdstip van generatie
Bewaar voor vloten de koppeling van apparaat of apparaatcohort naar firmware-artefact en SBOM. Dat is wat een securityteam in staat stelt te antwoorden op: „Welke uitgerolde apparaten bevatten de getroffen component?"
Hoe zit het met apparaten die 10 of 20 jaar in het veld blijven?
Een lange productlevensduur maakt SBOM-beheer een release-engineering-discipline, geen eenmalige compliance-taak.
Archiveer de SBOM bij elk uitgeleverd artefact, inclusief hotfixes en backports. Bewaar de source-revisie, build-configuratie, compiler- en linkerversies, leveranciers-SBOM's, handmatige aanvullingen en de hashes die nodig zijn om de inventaris te reproduceren of te verklaren.
De SBOM moet beschikbaar blijven, ook nadat de oorspronkelijke SDK-download, het CI-image, het ontwikkelwerkstation of het leveranciersportaal is verdwenen.
Vereist de EU Cyber Resilience Act een SBOM?
De EU Cyber Resilience Act verplicht fabrikanten om, als onderdeel van de verplichtingen rond kwetsbaarheidsafhandeling, een SBOM op te stellen in een gangbaar, machineleesbaar formaat die ten minste de top-level-afhankelijkheden van het product dekt. De verordening geldt in het algemeen vanaf 11 december 2027; de meldplichten voor fabrikanten onder artikel 14 gelden al vanaf 11 september 2026. De gezaghebbende tekst is Verordening (EU) 2024/2847.
Twee nuances zijn belangrijk.
Ten eerste: de CRA zegt niet dat elke SBOM automatisch aan elke gebruiker moet worden gepubliceerd. De gebruikersinstructies moeten vermelden waar de SBOM toegankelijk is als de fabrikant haar aan gebruikers beschikbaar stelt; autoriteiten kunnen op grond van de verordening relevante technische documentatie en SBOM-informatie opvragen.
Ten tweede: „top-level-afhankelijkheden" is een juridisch minimum, niet per se een operationeel toereikende inventaris. Wie op een kritieke kwetsbaarheid reageert, heeft vaak diepere zichtbaarheid in componenten en transitieve afhankelijkheden nodig dan het minimum alleen biedt.
Dit artikel is engineering-richtlijn, geen juridisch advies. Productscope, conformiteitsbeoordeling, sectorspecifieke regels en contractuele leveringsverplichtingen horen met gekwalificeerde juristen te worden beoordeeld.
Wie is verantwoordelijk als leveranciers geen SBOM leveren?
De fabrikant van het eindproduct heeft nog steeds een verdedigbare inventaris en een kwetsbaarheidsbeheerproces nodig voor alles wat hij integreert.
Leveranciers-SBOM's zijn het beste vertrekpunt, omdat leveranciers hun eigen componenten het best kennen. Inkoop- en engineeringcontracten horen te vragen om:
CycloneDX of SPDX in machineleesbaar formaat
Eén SBOM per geleverd artefact of release
Stabiele versie- en artefact-hashes
Leveranciers- en broninformatie
Licentiegegevens
Periode van security-support
Afspraken over kwetsbaarheidsmelding en updates
VEX voor bekende kwetsbaarheden met grote impact, waar passend
Levert een leverancier alleen een pdf of spreadsheet, bewaar die dan als bronbewijs, maar normaliseer de componentdata in het release-SBOM-proces. Maak machineleesbare levering een contractueel doel in plaats van het formaat open te laten.
Zijn handmatige SBOM-gegevens acceptabel?
Ja – wanneer ze gestructureerd, versiebeheerd, gecontroleerd en herhaalbaar zijn.
Handwerk is niet de vijand. Ongetraceerd handwerk wel.
Beheer handmatige aanvullingen als aparte YAML-, JSON- of andere controleerbare invoer onder versiebeheer. Geef elke component een minimale identiteit, leg vast waarom ze is toegevoegd, en voeg ze in de release-pipeline samen met de automatisch ontdekte componenten.
Dit is passend voor:
Propriëtaire archieven en blobs
Ingekochte protocol-stacks
SDK's met ontbrekende metadata
Gepatchte componenten
Gesloten PLC- of OT-bibliotheken
Componenten die buiten de reguliere source-repository worden geleverd
De voorkeursuitkomst is één samengevoegde SBOM per release. Vereisen organisatorische beperkingen aparte gegenereerde en handmatig samengestelde SBOM's, versioneer ze dan samen en stel ze samen of refereer ze als één release-set.
Zijn Conan, vcpkg, PlatformIO, Zephyr en Yocto makkelijker?
Ze bieden meer structuur, maar het uiteindelijke artefact blijft bepalend.
Conan en vcpkg verbeteren componentnaamgeving en versieresolutie voor de afhankelijkheden die ze beheren. Handmatig gekopieerde source, propriëtaire archieven of elke toolchain-runtime beschrijven ze niet automatisch.
PlatformIO centraliseert framework- en bibliotheekmetadata, maar teams moeten blijven verifiëren dat gedeclareerde bibliotheken overeenkomen met de gekozen omgeving en de uiteindelijke firmware.
Zephyr en west bieden manifestgebaseerd versiebeheer van sources over modules heen. Dat is een sterke basis voor een SBOM, zeker in combinatie met de geconfigureerde build en link-uitvoer.
Yocto is een van de meest volwassen embedded-Linux-ecosystemen voor SBOM-generatie. De
create-spdx-class kan SPDX-informatie voor images en SDK's rechtstreeks vanuit het buildsysteem genereren.
De algemene regel blijft: pakket- of manifestmetadata voor identiteit, build-metadata voor selectie, artefact-bewijs voor de uitgeleverde scope.
Hoe zit het met PLC- en gesloten OT-engineeringomgevingen?
Gesloten OT-omgevingen geven vaak minder build-detail prijs dan MCU- of embedded-Linux-workflows. Afhankelijkheden kunnen verborgen zitten in propriëtaire projectcontainers, leveranciersbibliotheken, functiebouwstenen of exports van engineering-tools.
Gebruik het sterkste bewijs dat het platform biedt:
Geëxporteerde bibliotheekinventarissen
Project- of automatiserings-API's
Door de leverancier geleverde SBOM's
Ondertekende bibliotheekpakketten en hashes
Release-manifesten
Een versiebeheerde handmatige componentenlijst
Claim geen precisie op artefactniveau als de engineeringomgeving die niet kan leveren. Benoem de bewijsbron en het betrouwbaarheidsniveau, en verbeter het proces via leverancierseisen en ondersteunde exportinterfaces.
Hoe ziet een praktische SBOM-workflow voor embedded firmware eruit?
Gebruik een gelaagde workflow:
Bouw de exacte release-configuratie. Genereer de definitieve SBOM niet vanuit een willekeurige developer-checkout.
Verzamel leveranciers-SBOM's en release-metadata. Bewaar de originele bestanden.
Lees project- en buildsysteemmetadata. Inclusief gekozen targets, configuraties, bronbestanden, include-paden, archieven en toolchain-instellingen.
Genereer een linker-map. Stem gedeclareerde of gecompileerde input af op wat het artefact heeft gehaald.
Identificeer gekopieerde (vendored) source. Koppel gekopieerde source-trees en submodules aan upstream-componenten en -versies.
Voeg ondoorzichtige componenten handmatig toe. Leg hashes, leveranciers, versies, licenties en leveringsreferenties vast.
Genereer CycloneDX of SPDX. Valideer het document tegen het relevante schema.
Beoordeel diagnoses en onbekenden. Beschouw het aanmaken van een bestand niet als bewijs van SBOM-kwaliteit.
Koppel de SBOM aan het artefact. Sla firmware-hash, build-ID, source-revisie en variant op.
Archiveer, monitor en actualiseer. Gebruik de SBOM voor kwetsbaarheidsanalyse en maak VEX aan wanneer een kwetsbaarheid niet misbruikbaar is.
Hoe genereert lynkctl een embedded C/C++-SBOM?
lynkctl leest het build-bewijs dat embedded projecten toch al produceren. Het ondersteunt GNU Make-, CMake- en IAR Embedded Workbench-projecten, inclusief .ewp- en .eww-bestanden. Bij STM32CubeMX-projecten voegt .ioc-metadata pakket- en targetcontext toe, terwijl build- en link-bewijs bepalend blijven voor de componentscope.
Het bouwt het project niet opnieuw. Draai het na de normale release-build, zodat de geconfigureerde build-tree, artefacten en linker-map beschikbaar zijn.
Voor een GNU Make-firmwareproject:
Voor CMake:
Voor IAR Embedded Workbench:
Wanneer een third-party source-tree expliciete componentgrenzen nodig heeft:
Wanneer gezaghebbende metadata ontbreekt of gecorrigeerd moet worden, gebruik dan een versiebeheerde override:
Afsluiting van de sectie: Het resultaat is niet zomaar een bestandenlijst. Het is een componenteninventaris afgeleid van de gekozen build, verrijkt met componentidentiteit en onderbouwd met bewijs dat overeind blijft wanneer een klant, auditor of security-engineer vraagt: „Waarom staat deze component in de SBOM?"
Hoe ziet een hoogwaardige embedded SBOM eruit?
Een hoogwaardige embedded SBOM is:
Artefactspecifiek: gekoppeld aan de firmware die is uitgeleverd
Configuratiespecifiek: gekoppeld aan board, target en feature-set
Build-bewust: afgeleid van werkelijke project- en compiler-input
Link-bewust: onderscheidt uitgeleverde code van dode of ongebruikte code
Leveranciersgeïnformeerd: hergebruikt gezaghebbende upstream-metadata
Eerlijk over onzekerheid: legt bewijs, betrouwbaarheid en onbekenden vast
Volledig bij ondoorzichtige input: omvat propriëtaire en voorgecompileerde componenten
Reproduceerbaar: kan opnieuw worden gegenereerd en zinvol worden vergeleken
Operationeel: voedt kwetsbaarheidsmonitoring, VEX, klantlevering en incident response
Het moeilijkste deel van embedded SBOM-generatie is niet het produceren van geldige JSON. Het is een verdedigbare uitspraak doen over wat er in een specifiek firmware-image zit.
Daarom combineert het juiste embedded SBOM-proces automatisering met engineering-bewijs. Automatiseer wat de toolchain kan bewijzen. Bewaar wat leveranciers weten. Voeg ondoorzichtige componenten toe via gecontroleerde handmatige invoer. En herhaal het proces voor elke release en elke uitleverbare variant.
Laatste vraag: waar moet een team beginnen?
Begin met één productie-firmwaretarget en één release-configuratie.
Zet een linker-map aan. Verzamel de relevante SDK- en leveranciersmetadata. Genereer de eerste SBOM uit de voltooide build. Loop elke onbekende component en false positive na met het firmwareteam. Zet de correcties onder versiebeheer en maak dezelfde workflow onderdeel van de release-pipeline.
U hebt op dag één geen perfecte automatisering nodig. U hebt een proces nodig dat accuraat en controleerbaar is – en met elke release beter wordt.
Wilt u een SBOM genereren vanuit STM32CubeMX, MCUXpresso, een nRF-firmwareproject, GNU Make, CMake of IAR Embedded Workbench? Interlynks embedded C/C++-SBOM-tooling is gebouwd voor precies die kloof tussen de SDK die u hebt ontvangen en de firmware die u daadwerkelijk uitlevert.