OpenChain Automotive SBOM Framework 1.0: Wat het vereist in 2026
| Interlynk
Het OpenChain Automotive SBOM Framework 1.0 van de Linux Foundation definieert een gemeenschappelijke set informatie voor overdrachten tussen automotive leveranciers. Dit is wat het raamwerk vereist, wat het openlaat en waarom correcte generatie blijft tellen.
Overzicht
Op 7 oktober 2026 kondigde de Linux Foundation versie 1.0 van het OpenChain Automotive SBOM Framework aan, gepresenteerd op de Open Source Summit Europe in Praag. Het raamwerk moet autofabrikanten en leveranciers een gedeelde manier geven om informatie over softwarecomponenten in de automotive toeleveringsketen te beschrijven en uit te wisselen.
Het is geen vervanging van SPDX of CycloneDX. In plaats daarvan definieert het een gemeenschappelijke set informatie en laat het zien hoe die informatie in gevestigde SBOM-formaten kan worden weergegeven.
Dat onderscheid is belangrijk. Een SBOM-raamwerk kan leveranciers voorschrijven welke informatie zij moeten aanleveren. Het kan die informatie echter niet uit zichzelf correct maken. De kwaliteit van de uiteindelijke inventaris hangt nog steeds af van hoe die wordt geproduceerd en welk bewijs elk veld ondersteunt.
Opzet en structuur van het raamwerk
De specificatie van het raamwerk verdeelt het werk in drie gebieden: datavelden, automatiseringsondersteuning, en praktijk en proces. Het onderdeel datavelden is het meest concrete deel van versie 1.0. Het definieert een minimale set informatie om componenten te identificeren, relaties te begrijpen en later werk aan licenties, kwetsbaarheden en traceerbaarheid te ondersteunen.
Elk veld is ofwel verplicht (Required) ofwel optioneel (Optional). De specificatie voert geen aparte categorie „aanbevolen" in. Verplichte velden worden in elke implementatie verwacht. Optionele velden mogen worden weggelaten, tenzij een contract, een organisatiebeleid of een branchevoorschrift ze noodzakelijk maakt.
De verplichte veldenset
De vereiste informatie valt in twee brede groepen: metadata op SBOM-niveau en componentattributen.
Op SBOM-niveau vereist het raamwerk de auteursnaam, het tijdstempel, het SBOM-type en de primaire component. Het tijdstempel geeft aan wanneer de SBOM is aangemaakt, terwijl het SBOM-type beschrijft waar de inventaris zich in de softwarelevenscyclus bevindt. Het raamwerk gebruikt de zes typen uit de CISA-richtlijn: Design, Source, Build, Analyzed, Deployed en Runtime.
Voor elke component vereist het raamwerk een naam, een versie, de leveranciersnaam, de relatie, een unieke identificatie, de bestandsnaam, de vastgestelde licentie, de copyrightvermelding en externe documentverwijzingen.
Het onderscheid tussen een gedeclareerde en een vastgestelde licentie is belangrijk. Een gedeclareerde licentie is wat de auteur of uitgever van de component opgeeft. Een vastgestelde licentie is de licentie die de SBOM-maker na beoordeling van toepassing acht. Beide kunnen gelijk zijn, maar dat hoeft niet. In versie 1.0 is de gedeclareerde licentie optioneel, terwijl de vastgestelde licentie verplicht is.
Downloadlocatie en cryptografische hash zijn optioneel in de veldtabel van het raamwerk. Wanneer een hash wordt opgenomen, gebruiken de voorbeelden in de specificatie SHA-256.
De veeleisendste vereisten zijn niet per se de meest zichtbare. Een leverancier kan componentnaam en versie meestal makkelijk invullen, maar een betrouwbare unieke identificatie, de verantwoordelijke leverancier en de vastgestelde licentie kunnen onderzoek vergen, zeker wanneer de software als binair bestand is geleverd, in een broncodeboom is gekopieerd of in een SDK is gebundeld.
Formaatneutraliteit en standaardaansluiting
Het raamwerk schrijft geen enkel SBOM-formaat en geen enkele formaatversie voor. Het stelt dat elk formaat mag worden gebruikt, zolang het de verplichte datavelden kan uitdrukken en de organisatie tegelijk de specificatie van dat formaat volgt. Voorbeelden die bij publicatie worden genoemd, zijn SPDX 2.x en 3.x, naast CycloneDX 1.4, 1.5, 1.6 en 1.7.
De specificatie bevat een dekkingstabel voor drie concrete gevallen: SPDX Lite zoals gedefinieerd in SPDX 2.3, ISO/IEC 5962:2021 (SPDX 2.2.1) en CycloneDX 1.6. ISO/IEC 5962:2021 is de gepubliceerde ISO-norm voor het SPDX-dataformaat.
Die tabel legt een praktisch interoperabiliteitsprobleem bloot. SPDX Lite biedt geen directe plek voor diverse vereisten van het Automotive SBOM, waaronder het SBOM-type, de primaire component, de componentrelatie, de cryptografische hash en externe documentverwijzingen. Een leverancier kan het datamodel van het raamwerk nog steeds gebruiken, maar SPDX Lite alleen kan niet elk verplicht veld uit de tabel weergeven.
Voor de velden die wel afgebeeld kunnen worden, geeft de specificatie concrete voorbeelden. Het SBOM-type wordt in de SPDX-2.2.1-afbeelding weergegeven via CreatorComment en in CycloneDX via metadata.lifecycles. De primaire component wordt afgebeeld op een SPDX-DESCRIBES-relatie en op metadata.component in CycloneDX. Hashes worden afgebeeld op SPDX-packagechecksums en CycloneDX-componenthashes.
Gekoppelde SBOM's en voertuigtraceerbaarheid
Het automotive model is geen enkele applicatie die in één repository wordt gebouwd. Een voertuig kan software van veel leveranciers en niveaus bevatten, met componenten die volgens verschillende releaseschema's worden beheerd. Het raamwerk beschrijft daarom een hiërarchisch model in plaats van één enorm bestand op voertuigniveau.
In dat model kunnen SBOM's voor afzonderlijke componenten apart worden beheerd en via externe documentverwijzingen worden verbonden. De specificatie beschrijft traceerbaarheid van een voertuigidentificatienummer, via het bijbehorende softwareonderdeelnummer, tot de bijbehorende SBOM. Ze merkt ook op dat de softwareconfiguratie van een voertuig na levering kan veranderen door herverwerking of over-the-air-updates, zodat ook de bijbehorende SBOM-informatie moet veranderen.
Dit is meer dan een voorkeur voor een bestandsformaat. Het is een manier om eigenaarschap en updates beheersbaar te houden en tegelijk de koppelingen te bewaren die voor onderzoek nodig zijn. Als jaren na levering van een voertuig een kwetsbaarheid bekend wordt, is de nuttige vraag niet simpelweg „wat zat er in de oorspronkelijke SBOM?". Ze luidt „welke softwareconfiguratie was op het betreffende moment aan dit voertuig gekoppeld?".
Het raamwerk biedt een structuur voor die traceerbaarheid. Het definieert echter niet uit zichzelf de productlevenscyclusdatabase, het updatebeleid of het kwetsbaarheidsresponsproces van een OEM.
Grenzen van versie 1.0
Versie 1.0 houdt bewust sommige informatie buiten de kern-veldenset. Dynamische informatie, zoals kwetsbaarheidsbevindingen, maakt geen deel uit van de SBOM-veldenset. In plaats daarvan moet de SBOM voldoende identiteits- en relatie-informatie bieden om componenten te matchen met externe kwetsbaarheids- en licentiebronnen. Ook organisatiespecifieke bedrijfsinformatie, zoals voertuigmodeldetails, valt buiten het raamwerk en moet via aparte, implementatiespecifieke schema's worden afgehandeld.
Het raamwerk benoemt ook verschillende punten die buiten de reikwijdte van versie 1.0 vallen of normaal gesproken door het onderliggende SBOM-formaat worden geleverd. Daartoe behoren de handtekening van de auteur, de naam en versie van het SBOM-tool, de SBOM-versie en de naam en versie van het dataformaat.
Die afbakening is redelijk, maar heeft een operationeel gevolg: conformiteit met de Automotive-SBOM-veldenset is niet hetzelfde als een volledig governance- of kwetsbaarheidsmanagementprogramma. Organisaties hebben nog steeds processen nodig om SBOM's te genereren, veilig uit te wisselen, bevindingen te beoordelen en beslissingen vast te leggen.
Het generatieprobleem
De verplichte velden gaan ervan uit dat een leverancier kan vaststellen wat er in de software is gegaan en wie daarvoor verantwoordelijk is. Dat is eenvoudig voor een schoon pakket uit een openbare registry. Het is minder eenvoudig voor embedded en automotive firmware.
Firmware-builds combineren vaak ingevoegde C- of C++-broncode, als binaire bestanden geleverde statische bibliotheken en SDK's van chipleveranciers. Sommige componenten komen binnen zonder manifest, zonder stabiele pakketidentificatie en zonder duidelijke licentiemetadata. Een bestandssysteemscan vindt de artefacten misschien wel, maar stelt mogelijk niet hun herkomst of de verantwoordelijke leverancier vast.
Juist hier kan een conforme SBOM toch onvolledig of misleidend zijn. Elk verplicht veld met gissingen invullen levert geen betrouwbare inventaris op. De betere aanpak koppelt componentgegevens waar mogelijk aan bewijs uit het ontwikkel- en buildproces. Build-bewuste generatie kan helpen door compiler- en linker-invoer te observeren, waaronder bronbestanden, archieven en SDK-objecten die een proces dat alleen op manifesten steunt, kan missen.
Voor Interlynk beschrijft het bedrijf precies deze rol voor lynkctl: SBOM-gegevens genereren uit de buildactiviteit voor embedded en firmware software, en vervolgens met het Interlynk-platform de volledigheid en kwaliteit van SBOM's beoordelen en wijzigingen bewaken. Dat zijn productmogelijkheden, geen eisen van het OpenChain-raamwerk. Het bredere punt staat los van één enkel hulpmiddel: het raamwerk definieert de uit te wisselen informatie, terwijl de generator bepaalt of de geleverde informatie door bewijs wordt gestaafd.
Eerste stappen voor leveranciers
Een leverancier die versie 1.0 beoordeelt, kan met vier controles beginnen:
Vergelijk de huidige SBOM-uitvoer met de verplichte velden van het raamwerk.
Bevestig dat het gekozen documentformaat elk verplicht veld kan uitdrukken; SPDX Lite is op zichzelf mogelijk niet toereikend.
Test hoe het proces omgaat met ingevoegde broncode, binaire bibliotheken, SDK-inhoud en componenten met onzekere licentie- of leveranciersgegevens.
Bepaal hoe SBOM's op componentniveau onderling en met de productgegevens voor traceerbaarheid na levering worden gekoppeld.
Het doel is niet louter een bestand produceren dat een schemacontrole doorstaat. Het gaat erom componentgegevens te produceren die een andere organisatie kan identificeren, interpreteren en aan de juiste softwareconfiguratie kan koppelen.
Conclusie
Het OpenChain Automotive SBOM Framework 1.0 is nuttig omdat het een leveranciersoverdracht concreter maakt. Het definieert een gedeelde veldenset, ondersteunt een model van gekoppelde SBOM's en blijft compatibel met gevestigde formaten in plaats van nog een propriëtair documenttype te creëren.
De grenzen ervan zijn even belangrijk. Het kiest geen enkel formaat, beslecht niet elke procesvraag en levert geen kwetsbaarheidsbevindingen. Vooral lost het niet het bewijsprobleem op voor componenten die diep in firmware-builds zitten of zonder bruikbare metadata worden geleverd.
Het raamwerk geeft de sector een duidelijker definitie van wat er moet worden uitgewisseld. De volgende uitdaging is ervoor te zorgen dat wat er wordt uitgewisseld, ook correct is.
Bronnen
Over Interlynk. Interlynk biedt tools om SBOM's te genereren, te beheren en te operationaliseren in de software-toeleveringsketen. Het product lynkctl is gericht op build-bewuste SBOM-generatie voor embedded en firmware software, terwijl het Interlynk-platform de opname van SBOM's en CBOM's, kwaliteitsbeoordeling, risicobeoordeling en wijzigingsmeldingen ondersteunt.
Dit artikel is informatief en vormt geen juridisch of compliance-advies. Conformiteitseisen van raamwerken, wettelijke verplichtingen en branchevoorschriften evolueren; verifieer de actuele eisen aan de hand van de primaire bronnen en uw eigen juridisch adviseur.