SBOM-beheer in grote ondernemingen loopt vast bij opschaling om voorspelbare redenen. Dit zijn de vijf waarop programma's stuklopen.
Vraag een grote onderneming of ze "aan SBOM's doet", en het antwoord is meestal ja. De build-pipelines geven CycloneDX of SPDX uit, de bestanden belanden ergens, een compliancevinkje wordt gezet. Op papier werkt het programma.
Dan duikt op een vrijdagmiddag een kritieke CVE op, vraagt iemand "waar zijn we kwetsbaar", en botst het programma op de realiteit. Uren verstrijken. Teams doorzoeken repositories. Niemand kan over meer dan een handvol producten een helder antwoord geven. De SBOM's waren er de hele tijd. Ze konden alleen de ene vraag niet beantwoorden waarvoor ze bedoeld waren.
Dat is het verschil tussen het genereren van SBOM's en het beheren ervan. Genereren is goedkoop en grotendeels geautomatiseerd. SBOM-beheer is het deel dat de kwetsbaarheidsvraag op aanvraag moet beantwoorden, en het is het deel dat vastloopt bij opschaling.
Een SBOM genereren is ongeveer tien procent van het werk
Het toolingverhaal is voorbij. Open-sourcegeneratoren produceren uit vrijwel elke build een gestandaardiseerde SBOM, in beide grote formaten, zonder noemenswaardige kosten. Een team kan het genereren in een middag opzetten.
Een bestand is geen programma. Wat een grote onderneming nodig heeft, is het vermogen om over elke ooit geproduceerde of ontvangen SBOM vragen te beantwoorden: wat zit er in onze software, waar, in welke versie, met welke bekende kwetsbaarheden, en wel nu. Dat vermogen heeft weinig te maken met hoe het bestand wordt gemaakt en alles met wat er daarna mee gebeurt.
Waar teams op plannen | Wat het werk werkelijk opslokt |
|---|---|
SBOM's genereren in CI | Miljoenen ervan opslaan en indexeren |
Een formaat kiezen | Formaten, versies en identificatoren verzoenen die elkaar tegenspreken |
De compliancecheck halen | Antwoorden actueel houden terwijl nieuwe CVE's binnenkomen |
De pipeline van één product | Honderden teams, leveranciers en overnames |
De linkerkolom is een weekend. De rechterkolom is het programma. Ondernemingen die de twee verwarren, leveren het weekend op en vragen zich af waarom het programma niet werkt.
Breuk 1: Volume waarvoor niemand heeft gepland
Een grote onderneming heeft niet één SBOM. Ze heeft een SBOM per build, per service, per versie, per release, over elke productlijn en bedrijfseenheid heen. Eén middelgroot product kan honderden SBOM's per maand uitgeven. Vermenigvuldig dat over een portfolio en het aantal loopt in de miljoenen, met dagelijkse groei. Dit is SBOM-wildgroei, en het is het eerste wat breekt.
Het breekt geluidloos, omdat er niets foutmeldt. De map met JSON-bestanden die werkte bij tien SBOM's en de spreadsheet die werkte bij honderd, gooien bij tienduizend geen exceptie. Ze houden gewoon op bruikbaar te zijn terwijl ze nog lijken te functioneren. De bestanden stapelen zich ongelezen op.
Breuk 2: Geen twee SBOM's komen overeen
Volume zou beheersbaar zijn als elke SBOM er hetzelfde uitzag. Geen enkele doet dat.
De ene bedrijfseenheid produceert CycloneDX 1.4. Een andere 1.7. Een derde standaardiseerde op SPDX, en daarbinnen geeft een deel van de tooling nog het oudere 2.3 uit, terwijl nieuwere pipelines 3.0.1 produceren. Dezelfde component verschijnt in het ene bestand via purl, in het andere via CPE, en in een derde als vrije tekst met naam en versie. Een overgenomen bedrijf arriveert met zijn eigen toolchain en zijn eigen conventies, waarvan er geen bij de jouwe passen.
Probeer nu een portfoliobrede vraag te beantwoorden. Je kunt geen bestanden samenvoegen die het oneens zijn over structuur, en geen componenten dedupliceren die het oneens zijn over identiteit. De afhankelijkheid die het ene team log4j-core noemt, een ander org.apache.logging.log4j:log4j-core en een derde Apache Log4j, is dezelfde afhankelijkheid, maar geen naïef systeem weet dat. Zonder genormaliseerde componentidentiteit wordt elke overkoepelende vraag een handmatig verzoeningsproject, wat betekent dat hij niet beantwoord wordt.
Breuk 3: Het bestand is verouderd op het moment dat het wordt geschreven
Een SBOM is waar op build-moment en begint meteen te verouderen. Het legt de componenten vast zoals ze waren op het moment dat de build draaide. Het zegt niets over de kwetsbaarheid die volgende week tegen een van die componenten wordt gemeld.
Dit is de denkfout onder de meeste programma's: de SBOM behandelen als een te archiveren document in plaats van als te monitoren data. Een gearchiveerde SBOM beantwoordt "wat hebben we uitgeleverd". De vraag die er bij een incident toe doet, is "waar zijn we vandaag kwetsbaar", en een statisch bestand kan die niet beantwoorden. De component die bij de release schoon was, wordt een kritieke blootstelling op het moment dat een CVE binnenkomt, en een programma dat op opgeslagen momentopnames steunt, merkt het pas als iemand gaat kijken, meestal te laat.
Breuk 4: Leverancier-SBOM's komen als een rommeltje binnen, áls ze al binnenkomen
Een grote onderneming produceert niet alleen software. Ze consumeert die, van honderden leveranciers, en een groeiend deel van contracten en regelgeving verplicht die leveranciers nu om een SBOM te leveren.
Wat binnenkomt, is ongelijk. Sommige leveranciers sturen een schone, volledige SBOM. Sommige een schrale, waarin de helft van de componenten ontbreekt. Sommige het verkeerde formaat, een PDF, of niets totdat je erachteraan gaat. De inventaris van derden is precies de plek waar de gevaarlijkste onbekende componenten schuilen, en het is doorgaans het slechtst beheerde deel van het programma.
Breuk 5: Niemand is eigenaar van het geheel
Onder elk technisch falen ligt een organisatorisch falen. Vraag wie het SBOM-beheer in de onderneming bezit, en je krijgt meestal een stilte.
Engineering bezit het genereren en beschouwt de klus als klaar zodra het bestand bestaat. Compliance bezit de audit en verschijnt eens per jaar om bewijs te verzamelen. Productsecurity bezit kwetsbaarheden, vaak zonder een volledige, genormaliseerde inventaris om mee te werken. Elke functie raakt een stukje aan. Geen enkele bezit het geheel, en dat is precies de voorwaarde waaronder de portfoliobrede vraag onbeantwoord blijft.
De test die alles blootlegt: de volgende zeroday. Als een kwetsbaarheid van het kaliber Log4Shell toeslaat, telt alleen hoe snel je "elke plek waar we kwetsbaar zijn, over elk product en elke versie, inclusief wat we van leveranciers kregen" kunt beantwoorden. Een onderneming met echt SBOM-beheer antwoordt in minuten. Een onderneming met een stapel SBOM's antwoordt in dagen, met de hand, en weet nooit helemaal zeker of het antwoord volledig is. Beide genereerden SBOM's. Slechts één beheerde ze.
De oplossing is de beheerlaag, niet een betere generator
Geen van deze breuken wordt opgelost door betere bestanden. Ze worden opgelost door de laag die ondernemingen zelden inplannen: één systeem van registratie, genormaliseerde componentidentiteit, continue herbeoordeling, leverancier-ingestie en integratie met de securitystack. Dat is het echte werk dat compliancegedreven programma's uitstellen, omdat het genereren van het bestand aan de eis voldoet en het beheren van het bestand pas op een auditchecklist verschijnt op de dag dat het er opeens toe doet.
De ondernemingen die dit goed doen, stoppen met de SBOM als opleverstuk te behandelen en gaan haar behandelen als levende operationele data. De andere zullen SBOM's blijven genereren, audits blijven halen, en de vrijdagmiddag blijven verliezen waarop het ertoe doet.
Voor de concrete maatregelen die elk van deze vijf breuken onder controle houden, zie het begeleidende artikel: De checklist voor SBOM-beheer in de onderneming.
Interlynk geeft security- en complianceteams één systeem van registratie voor elke SBOM, intern en van leveranciers, met genormaliseerde componentidentiteit en ingebouwde continue monitoring. Genereer in CycloneDX of SPDX, houd elke uitvoer actueel terwijl je afhankelijkheden en de meldingen evolueren, en beantwoord de portfoliobrede kwetsbaarheidsvraag in minuten in plaats van dagen. Vertrouwd door security- en complianceteams bij meer dan 100 gereguleerde bedrijven.