In de industrie is het begrip BoM een goede bekende: de Bill of Material of stuklijst. De lijst met alle te maken of in te kopen onderdelen, die samen het eindproduct vormen. In een assemblageproces worden die onderdelen in een gestructureerde volgorde samengebouwd totdat zij samen een compleet eindproduct vormen. Elke leverancier houdt goed bij welke onderdelen geldig zijn en in hun producten zijn ingebouwd. Immers bij defecten zullen die onderdelen als reservedeel moeten kunnen worden vervangen . Onderdelen die later gevaarlijk blijken te zijn, moeten ook vervangen kunnen worden. In terugroep acties merken we dit soms ook bij auto’s. Dus stuklijsten zijn belangrijke documenten, zeker als een te vervangen onderdeel ook nog bepaalde versies van software in zich heeft. In de fysieke wereld is de Global Product Classification (GPC) methode van GS1 als een standaard voor onderdeel-identificatie.

NTIA

In de wereld van applicaties werd nooit over een lijst met onderdelen gesproken. Immers de applicatie werd regel voor regel, en set voor set geprogrammeerd en aldus opgebouwd. Maar die wereld is langzaam aan ook een wereld van ‘componenten’ geworden waar standaard libraries, executables of (open) source code worden samengebouwd tot een gezamenlijke functionaliteit. De National Telecommunication and Information Administration (NTIA) heeft de afgelopen maanden diverse artikelen over dit onderwerp gepubliceerd om visie en transparantie op het gebied van de SBoM te creëren: Software Bill of Materials.  

Een SBoM is een geldige lijst van ingrediënten die een software programma of applicatie in zich heeft. Net als in de auto-industrie een lijst met honderden of duizenden componenten die zelf zijn gemaakt, specifiek door derden op maat zijn gemaakt of standaard sets of code. Naast de SBoM is de assemblage volgorde van belang. Net als bij een auto is de volgorde hoe de componenten worden samengevoegd en getest ook voor een software programma van belang. Hoe meer standaard componenten een programma bevat, hoe makkelijker meestal de assemblage en het (eind-)testen zal zijn.

Code supply-chain management

Meer en meer bestaat software uit componenten van derde partijen. Maar er is eigenlijk weinig zichtbaarheid op de aanvoerlijnen van die code-componenten. Wie levert ze, hoe zijn ze ontwikkeld, door wie zijn ze getest en gecertificeerd? Supply-chain management in de software wereld komt nog relatief weinig voor. Maar stel dat een ingekocht software component zwakheden of Security-issues bevat, dan zul je de gebruikers van de totale applicatie, net als bij auto’s, moeten oproepen om deze componenten te verwisselen. Maar dan moet ook de klant weten dat hij deze component in zijn software heeft zitten en heeft hij dus (!) een stuklijst nodig. Dit document van de NTIA geeft daar een mooi voorbeeld van. 

Immers zodra een zwakheid is gevonden, willen eindklanten zelf kunnen beoordelen of zij risico lopen. Het gebrek aan transparantie in de applicatiewereld naar de eindklanten over hun eindproduct schiet op veel plaatsen tekort. Zeker met de ontwikkeling van betere cybersecurity en de wens eerder de potentiële zwakheden en gevaren te kennen, is de Software BoM aan een opmars bezig is. Dat betekent ook dat tijdens de gehele levenscyclus van software – net als bij fysieke producten – bij defecten, problemen of verwachte zwakheden ‘reservedelen’ beschikbaar moeten zijn. En dat moet per klant c.q. gebruiker worden vastgelegd, opdat de software in zijn geheel weer voldoet aan alle eisen en compliance. 

DBoM

In Github is een Digital BoM project gestart om structuren van samengebouwde Bills of Material te maken. Componenten als een ‘database agent’ of ‘mongodb-audit-watcher’ bestaan elk uit een boom met onderliggende functionaliteit die in Github op die wijze kan worden bijgehouden. Net zoals in de fysieke wereld via CAD en MRP uiteindelijk de standaard business ERP en Product Lifecycle management platformen zijn ontstaan, zien we die ontwikkeling dus in de software nu ook doorbreken. Nodig om ook te kunnen communiceren over verschillende BoM’s en deze ook te kunnen uitwisselen en beheren. 

Misschien de grootste uitdaging om transparantie in de software keten te realiseren, is het uniek kunnen identificeren van software componenten. Daarvoor is unieke wereldwijde herkenning nodig om betreffende componenten te kunnen zoeken en traceren. Dit zal globaal moeten en is een fikse uitdaging voor de verschillende software ecosystemen, sectoren en marken. Hoewel het vanzelfsprekend is om bestaande component identificatie systemen te (blijven) gebruiken, is er behoefte deze identificatie ook op hoger niveau over fabrikanten, sectoren en gebruikers mogelijk te maken. 

Component identificatie

Er is een uitspraak van Phil Karlton uit 1964 die stelt dat er ‘maar’ twee lastige zaken zijn in de computer wetenschap: ‘cache invalidation and naming things’.  En die uitspraak is in 2021 nog steeds geldig. Er is namelijk geen enkele wereldwijde geautoriseerde bron om software componenten te benoemen. Als twee verschillende SBoM-auteurs beiden een identificatie van eenzelfde software component zouden opstellen, zouden er twee verschillende identificaties ontstaan. Dit is uitdaging waar momenteel de sector voor geplaatst is en waar de NTIA probeert voortgang in te realiseren. 

De afgelopen jaren zijn verschillende standaarden ontwikkeld, zoals de Common Platform Enumeration (CPE), software identificatie (SWID) tags, Package URL’s (puls) and SoftWare Heritage persistent IDentifiers (SWHIDs). Maar nog steeds zijn te veel identificaties niet statisch genoeg en veranderen individueel nog te vaak om wereldwijd standaard te kunnen zijn. De vraag is of er ooit (ook) voor software een wereldwijd dekkende, unieke identificatie mogelijk zal zijn. Velen twijfelen daaraan, ook bij de NTIA, maar vooralsnog probeert men globale identificatie van softwarecomponenten mogelijk te maken, mogelijk met complex gebruik van aliassen of equivalentie-relaties. Er is nog heel wat werk aan de winkel  . . . 

Photo by Kotagauni Srinivas on Unsplash