Software is tegenwoordig zelden nog één groot geheel. Applicaties bestaan uit lagen met afhankelijkheden: open source componenten, derde partijen, bibliotheken én steeds vaker AI-modellen en externe datastromen. Juist daarom verschuift de focus bij securityteams: software transparency is geen vinkje meer, maar een operationele noodzaak om te kunnen begrijpen wat er daadwerkelijk draait.
In een gesprek met cybersecurity policy-expert Allan Friedman (zoals besproken in de SecurityWeek Podcast) draait het idee om SBOM, de opkomst van AI BOMs, en waarom VEX minstens zo belangrijk is als de lijst met componenten. Hieronder zetten we de kernpunten op een rij en vertalen we ze naar wat je vandaag kunt doen.
SBOM: het gaat om weten, niet om archiveren
Het oorspronkelijke SBOM-debat ging lang over vragen als: kunnen leveranciers SBOM’s leveren, en moeten klanten dat eisen? Friedman benadrukt dat de echte waarde pas ontstaat nadat je zo’n document ontvangt.
Een SBOM geeft in gestructureerde vorm weer welke componenten en afhankelijkheden samen de software vormen. Maar belangrijker is wat je organisatie ermee doet: hoe je sneller kunt handelen als er een kwetsbaarheid opduikt, er een compromis plaatsvindt, of er sprake is van een schadelijke update.
Snelle respons bij de volgende ‘grote’ kwetsbaarheid
In de praktijk wil je niet dagen of weken besteden aan uitzoeken welke systemen een kwetsbare component bevatten. Als de leverancier aantoonbaar kan aangeven welke componenten in het product zitten, kun je die blootstelling sneller beoordelen. Voor securityteams betekent dat kortere responstijd en gerichtere actie.
Friedman stelt daarbij een groeipad voor: SBOM moet niet alleen een statisch document zijn, maar onderdeel worden van je bredere beveiligingsdata. Denk aan koppelingen met vulnerability management, asset management en continue risicobeheersing.
Software transparency voorkomt dat je appels met peren vergelijkt
Meer zicht kan helpen, maar het is ook een valkuil: je kunt overspoeld raken met meldingen. Het feit dat een kwetsbaar component ergens in je toepassing zit, betekent niet automatisch dat het in jouw specifieke configuratie of implementatie ook daadwerkelijk misbruikbaar is.
Daarom is software transparency gebaat bij context: je wil niet alleen weten wat aanwezig is, maar ook of het relevant is.
VEX als context: van kwetsbaarheid naar exploitbaarheid
VEX (Vulnerability Exploitability eXchange) wordt in het gesprek neergezet als logische aanvulling op SBOM. Waar SBOM vooral inventory en afhankelijkheden levert, richt VEX zich op de vraag: maakt deze kwetsbaarheid in dit product echt een verschil?
Een voorbeeld: een applicatie kan een bibliotheek bevatten met een bekende zwakte, maar die bibliotheek wordt in jouw gebruiksscenario misschien niet aangesproken. In zo’n situatie helpt VEX om onderscheid te maken tussen het aanwezig zijn van een kwetsbaar component en een daadwerkelijk exploiteerbare situatie.
Prioritering tegen de ‘vulnerpocalypse’
Friedman gebruikt in het gesprek een knipoog naar de dreiging van een “vulnerpocalypse”: organisaties hebben steeds meer kwetsbaarheidsinformatie, maar niet genoeg menskracht om alles handmatig te onderzoeken. Juist dan wordt software transparency waardevol wanneer het leidt tot betere prioritering. Met SBOM + VEX kun je focus aanbrengen op wat echt risico oplevert.
AI BOMs maken transparency complexer (maar niet minder nodig)
De volgende stap is al onderweg. Zodra organisaties machine learning, generatieve AI en autonome agents in hun toepassingen verwerken, kan een traditionele software inventory niet meer volledig dekkend zijn.
Friedman beschrijft de opkomst van AI BOMs als een logische evolutie. Een AI-systeem blijft software, dus traditionele componenten blijven relevant. Maar AI brengt extra elementen mee die je mogelijk moet vastleggen en kunnen reconstrueren, zoals het model zelf, data die het model ondersteunt, externe datastromen en de infrastructuur of “harnesses” die nodig zijn om het systeem te laten werken.
Welke vragen duiken er bij AI BOMs op?
Bij AI BOMs komen onder meer vragen naar voren zoals:
- Waar komt het model oorspronkelijk vandaan?
- Welke data is gebruikt om het model te ondersteunen?
- Welke externe data kan tijdens runtime worden toegevoegd?
- Wie is verantwoordelijk voor het model?
- Wat gebeurt er wanneer een agent dynamisch een tool aanmaakt, een actie uitvoert en vervolgens weer verdwijnt?
Met name die laatste situatie—dynamische, agentische interacties—maakt het lastiger om alles één-op-één vooraf te documenteren. Friedman geeft aan dat het antwoord mogelijk vaker zit in een samenkomst van BOM-achtige inzichten, logging, informatiearchitectuur en derde-partij risicoverantwoording.
Transparency moet de verdediger helpen
Een veelgehoorde weerstand tegen SBOM is het risico op intellectueel eigendom en de vrees dat gedetailleerde componentinformatie aanvallers zou helpen. Friedman zet daar vraagtekens bij: moderne reverse engineering stelt aanvallers vaak al in staat componenten te identificeren, en geautomatiseerde aanvalskaders of ransomware operaties kunnen systemen soms testen tegen bekende exploit-patronen zonder SBOM.
De verdedigingskant heeft juist baat bij zicht. Friedman verwoordt dat punt als volgt: het zijn de Blue Teams die visibility nodig hebben om te weten waar kwetsbare componenten zich bevinden, verspreid over mogelijk duizenden systemen.
Bovendien kunnen SBOM-standaarden volgens Friedman ruimte bieden voor redaction wanneer er legitieme proprietary bezwaren zijn. Dan kan een leverancier bijvoorbeeld aangeven dat een dependency bestaat, zonder alle details te onthullen.
Van SBOM naar een breder transparency-ecosysteem
SBOM wordt in het gesprek niet neergezet als eindstation, maar als één laag in een groter transparency-verhaal. De term “omnibomb” is daarbij een luchtige verwijzing naar het idee dat verschillende vormen van transparantie samen kunnen komen.
Er worden in dat kader meerdere ‘bills’ genoemd:
- AI bills of materials voor AI-gerelateerde afhankelijkheden.
- Cryptographic bills of materials om cryptografische afhankelijkheden te identificeren, in aanloop naar crypto-agility en post-quantum scenario’s.
- Hardware bills of materials voor fysieke componenten, zoals semiconductors.
Of die convergentie er ooit precies zo komt, is nog niet zeker. Wat wel duidelijk is: er is nog veel werk aan interoperabiliteit. Friedman geeft aan dat twee SBOM-tools bij dezelfde software niet altijd dezelfde dependency graph opleveren. Daarom zijn harmonisatie, minimale verwachtingen en gemeenschappelijke normen belangrijk.
Praktische richting: continuous software transparency
De einddoelstelling is volgens Friedman geen nieuwe compliance-papieren stapel. Het draait om continuous software transparency: je organisatie moet begrijpen waarop systemen leunen, dat kunnen correleren met opkomende dreigingen en kwetsbaarheden, en vervolgens snel bepalen waar je echte exposure zit.
Belangrijk detail: software transparency lost niet “alle” cybersecurityproblemen op. Het is data. De veiligheidswaarde ontstaat pas wanneer je die data inzet in je processen: van monitoring tot analyse en besluitvorming.
Wil je breder lezen over hoe securityteams hiermee omgaan in recente praktijkgevallen, dan is dit artikel relevant: Fireworks AI: LLMjacking en billingdata bloot. Het laat zien hoe afhankelijkheden en externe interacties ook in AI-omgevingen concrete impact kunnen hebben.
Conclusie
Software transparency verandert het spel voor securityteams. SBOM helpt je de bouwstenen en dependencies te kennen, maar de waarde zit in wat je daarna doet. Met VEX voeg je context toe zodat je sneller onderscheid maakt tussen aanwezigheid en exploitbaarheid. En zodra AI en agents onderdeel worden van je applicaties, worden AI BOMs en aanvullende evidencebronnen steeds belangrijker.
De kern blijft: niet alleen weten wat er in software zit, maar vooral sneller en gerichter reageren op echte risico’s—voordat een incident of kwetsbaarheid je organisatie voorbijloopt.
