Iedereen wil een SBOM, niemand wil ervoor instaan

Bij een aanbesteding staat tegenwoordig vaak dezelfde eis: de leverancier moet een SBOM aanleveren. De vraag wordt keurig opgenomen in het contract, de securityafdeling zet een vinkje en ergens belandt een JSON- of XML-bestand in een portal. Iedereen tevreden. Tot er een kwetsbaarheid wordt gevonden in een bibliotheek die volgens die SBOM in een bedrijfskritische applicatie zit.

Dan begint het doorschuiven. De leverancier zegt dat de component door een onderaannemer is geleverd. De onderaannemer wijst naar de buildstraat. Development zegt dat de applicatie al maanden niet meer wordt beheerd. Inkoop verwijst naar het contract. Security vraagt wie kan bepalen of de component werkelijk wordt gebruikt. En IT zoekt ondertussen naar het bestand dat ooit als bewijs van volwassenheid is geüpload.

De ongemakkelijke waarheid is dat een SBOM zelden faalt omdat het bestandsformaat verkeerd is. Hij faalt omdat niemand eigenaar wil zijn van de werkelijkheid die erin staat. Een SBOM is geen inventarisprobleem, maar een verantwoordingsprobleem. Zolang een organisatie niet kan aanwijzen wie de inhoud, actualiteit en opvolging beheert, is een SBOM vooral een keurige manier om onzekerheid te archiveren.

Iedereen vraagt om hetzelfde bestand

Een Software Bill of Materials moet zichtbaar maken uit welke softwarecomponenten een product of applicatie is opgebouwd. Dat kan waardevol zijn. Bij een kwetsbaarheid wil je snel weten welke versies aanwezig zijn, waar ze draaien, wie ze gebruikt en welke actie nodig is. Zonder dat inzicht begint ieder incident met handmatig zoeken, aannames en een reeks mails aan leveranciers.

Maar in de praktijk wordt de SBOM vaak behandeld als een leverbaar document. Inkoop vraagt erom, de leverancier levert hem en security bewaart hem. Daarmee ontstaat een merkwaardige keten waarin iedereen formeel iets heeft gedaan, maar niemand verantwoordelijk is voor het antwoord op de belangrijkste vraag: klopt deze informatie nog?

Software verandert voortdurend. Een component kan tijdens de build worden vervangen, een containerimage kan opnieuw worden opgebouwd, een dependency kan indirect worden toegevoegd en een product kan een andere configuratie krijgen zonder dat de naam verandert. Een SBOM die bij oplevering correct was, kan kort daarna onvolledig zijn. Dat maakt de datum van aanlevering veel minder interessant dan de vraag hoe de informatie wordt bijgewerkt en gecontroleerd.

Een SBOM beschrijft de software, maar beslist niets

Een SBOM kan melden dat een bepaalde bibliotheek met een bepaalde versie aanwezig is. Hij kan niet bepalen of die bibliotheek in productie actief is, of de kwetsbare functie wordt aangeroepen, of een compensatiemaatregel voldoende is en wie het risico accepteert. Dat zijn geen eigenschappen van een bestandsformaat. Dat zijn organisatorische besluiten.

Daar gaat het vaak mis. De aanwezigheid van een component wordt verward met de aanwezigheid van risico. Vervolgens wordt de afwezigheid van een component geïnterpreteerd als de afwezigheid van risico. Beide conclusies kunnen onjuist zijn. Een component kan in een testimage staan en nergens worden gebruikt, terwijl een kwetsbare functionaliteit in een andere distributie of via een externe service wel degelijk beschikbaar is.

Daarom moet een SBOM verbonden zijn met de context van de applicatie. Welke versie draait werkelijk? In welke omgeving? Welke businessfunctie raakt dit? Wie is de product- of applicatie-eigenaar? Hoe lang mag een probleem blijven bestaan? Zonder die verbinding blijft de SBOM een technisch overzicht naast de werkelijkheid, niet een bruikbaar onderdeel ervan.

De leverancier levert data, niet de verantwoordelijkheid

Het is logisch om van leveranciers een SBOM te eisen. Een afnemer kan moeilijk inzicht geven in software die hij niet zelf bouwt. Maar een contractuele leveringsplicht maakt de leverancier nog niet automatisch verantwoordelijk voor ieder risico dat uit die lijst voortkomt. De leverancier kent zijn product en bouwproces. De afnemer kent de eigen configuratie, blootstelling, gegevens en bedrijfsimpact. Beide perspectieven zijn nodig.

Een leverancier kan bovendien niet altijd instaan voor de kwaliteit van iedere transitive dependency. Dat is geen vrijbrief voor onzorgvuldigheid, wel een reden om preciezer te contracteren. Leg vast welke reikwijdte de SBOM heeft, hoe componenten worden geïdentificeerd, wanneer een nieuwe versie wordt geleverd en hoe omissies of onzekerheden worden gemeld. Vraag ook hoe de leverancier reageert wanneer een component achteraf onjuist blijkt te zijn beschreven.

De afnemer moet op zijn beurt stoppen met doen alsof het ontvangen bestand het einde van de controle is. Een SBOM hoort aan een product of applicatie gekoppeld te zijn, aan een eigenaar, aan een lifecycle en aan een proces voor kwetsbaarheden. Als dat niet is geregeld, koopt de organisatie geen transparantie maar een bewijsstuk voor de volgende audit.

De echte eigenaar zit tussen development en security

De verantwoordelijkheid voor een SBOM past niet netjes in één bestaande afdeling. Development kan de samenstelling van de software beïnvloeden, maar is niet altijd eigenaar van de bedrijfsimpact. Security kan kwetsbaarheden beoordelen, maar beheert niet iedere applicatie. Inkoop kan eisen stellen aan de leverancier, maar kan geen technische volledigheid vaststellen. Operations ziet wat draait, maar niet altijd hoe het is gebouwd.

Dat betekent niet dat iedereen gezamenlijk eigenaar is. Dat is meestal een nette formulering voor niemand. Er moet één aangewezen eigenaar zijn van het product of de applicatie die verantwoordelijk is voor de bruikbaarheid van de informatie. Die eigenaar hoeft niet zelf iedere component te controleren, maar moet wel kunnen uitleggen wie de SBOM genereert, waar de bron ligt, hoe actualiteit wordt vastgesteld en wat er gebeurt wanneer de informatie ontbreekt.

Daaronder moeten de taken wel helder zijn. De buildstraat kan een SBOM genereren. Een platformteam kan de opslag en koppeling met de runtime verzorgen. Security kan kwetsbaarheden en exploitatie beoordelen. Inkoop kan leveranciers verplichten tot transparantie. De applicatie-eigenaar beslist over herstel, acceptatie of uitfasering. Dat is geen bureaucratische rolverdeling. Het is het verschil tussen technische informatie en bestuurbare informatie.

Tooling maakt een slechte afspraak alleen sneller

Er zijn genoeg tools die SBOM’s kunnen genereren, samenvoegen, vergelijken en koppelen aan kwetsbaarheidsinformatie. Dat is nuttig, vooral wanneer een organisatie veel software produceert of gebruikt. Automatisering voorkomt handwerk en maakt afwijkingen eerder zichtbaar. Maar tooling lost geen onduidelijk eigenaarschap op.

Een scanner kan een component niet vinden die niet in het artefact zit dat wordt gescand. Een generator kan geen ontbrekende broninformatie raden. Een platform kan een verouderde SBOM prachtig indexeren. En een dashboard kan een rood vak tonen zonder dat iemand bevoegd is om productie stil te leggen of een risico te accepteren. De organisatie heeft dan meer zichtbaarheid, maar niet noodzakelijk meer grip.

De eerste volwassenheidsvraag is daarom niet welke tool wordt gekozen. Het is: welk besluit moet deze SBOM ondersteunen? Als het antwoord incidentrespons is, moeten versie, locatie en eigenaar snel vindbaar zijn. Als het antwoord leveranciersbeoordeling is, moeten herkomst en updateproces controleerbaar zijn. Als het antwoord veilige softwareontwikkeling is, moet de SBOM onderdeel zijn van de build en release, niet een bestand dat achteraf wordt samengesteld.

Ook de relatie met bestaande configuratie- en assetinformatie verdient aandacht. Een SBOM vervangt geen CMDB en een CMDB vervangt geen SBOM. De eerste beschrijft software-inhoud, de tweede probeert de technische werkelijkheid en relaties te beschrijven. Beide kunnen onbetrouwbaar zijn wanneer niemand de bron, definitie en actualiteit bewaakt. Zoals bij iedere inventaris geldt: de CMDB liegt niet vanzelf, maar wordt wel vaak als waarheid behandeld.

Maak van onzekerheid een expliciet besluit

Een goede SBOM is niet per definitie compleet. Soms is een component gesloten, wordt informatie door een leverancier niet geleverd of is de herkomst van oude software niet meer vast te stellen. De fout is niet altijd dat die onzekerheid bestaat. De fout is dat ze wordt verborgen achter een bestand dat er officieel uitziet.

Maak daarom zichtbaar wat bekend, afgeleid en onbekend is. Leg vast welke componenten niet konden worden vastgesteld, welke aannames zijn gebruikt en wie het resterende risico heeft beoordeeld. Een incomplete SBOM kan bruikbaar zijn als de beperking bekend is en het besluit erop aansluit. Een ogenschijnlijk complete SBOM zonder controleerbare herkomst is gevaarlijker, omdat hij vertrouwen simuleert.

Daarmee komt ook de grens van standaardisatie in beeld. Een standaard kan structuur en uitwisseling verbeteren, maar geen eigenaarschap afdwingen. Een standaard garandeert geen kwaliteit wanneer de organisatie niet controleert wat de gegevens betekenen en wie erop handelt. Hetzelfde geldt hier: een correct syntactisch document kan inhoudelijk nog steeds te oud, te smal of onbruikbaar zijn.

Wat is dan de echte IT-realiteit?

Een SBOM is geen eindproduct en ook geen verzekeringspolis tegen kwetsbaarheden. Het is een stuk keteninformatie dat pas waarde krijgt wanneer het verbonden is met een actuele softwareversie, een gebruikscontext, een verantwoordelijke eigenaar en een besluitproces. De vraag “hebben we een SBOM?” is daarom te zwak. De relevante vraag luidt: “Kunnen we bij een probleem aantonen wat er draait, wie daarover beslist en welke actie volgt?”

Dat vraagt om meer dan een clausule in een contract en meer dan een dashboard in de securityomgeving. Het vraagt om een eigenaar die de informatie mag betwisten, om leveranciers die transparantie niet als een eenmalige oplevering behandelen en om bestuurders die accepteren dat onbekendheid een risico is waarvoor iemand een keuze moet maken.

Wie alleen een SBOM verzamelt, bouwt een archief. Wie eigenaarschap organiseert, bouwt handelingsvermogen. Iedereen kan om een lijst vragen; de volwassen organisatie durft ook de naam op te schrijven van degene die verantwoordelijk is wanneer die lijst niet klopt.