De Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) heeft samen met G7-cyberpartners een richtlijn gepubliceerd met minimale elementen voor een AI software bill of materials (SBOM). Deze richtlijn helpt bij het beoordelen van de beveiliging en herkomst van AI-systemen die binnen organisaties worden ingezet.

De nieuwe richtlijn breidt het traditionele SBOM-concept uit naar AI door te vragen om documentatie van modellen, datasets, softwarecomponenten, leveranciers, licenties en andere afhankelijkheden. Volgens CISA zijn deze minimale elementen niet uitputtend of verplicht, maar weerspiegelen ze een consensus onder G7-experts en zullen ze meegroeien met de ontwikkeling van AI-technologie.

Voor beveiligingsprofessionals betekent dit dat AI-risico’s steviger worden ingebed in het toezicht op de softwareleveringsketen. AI SBOM’s kunnen zo onderdeel worden van de bestaande gesprekken over leveranciersrisico’s rondom software, cloudservices en derdepartijstechnologie. Een belangrijk verschil is dat AI SBOM’s verder moeten kijken dan alleen softwarecomponenten, omdat AI-risico’s ook worden bepaald door modellen, data, infrastructuur en systeemgedrag.

Volgens Sakshi Grover, senior research manager bij IDC Asia Pacific Cybersecurity Services, voegen AI-systemen nieuwe lagen van ondoorzichtigheid toe, zoals modelherkomst, trainings- en inferentiedata, fijn-afstemming, prompts, vector databases, derdepartijmodellen, API’s, orkestratielogica en runtime gedrag. Keith Prabhu, oprichter en CEO van Confidis, benadrukt dat AI-software probabilistisch is en dat outputs worden beïnvloed door dataherkomst naast code. Daarom moet een AI SBOM ook modellen, trainingsdata, prompts, systeeminstructies, modelgewichten, checkpoints en GPU-afhankelijkheden bijhouden.

Sanchit Vir Gogia, chief analyst bij Greyhound Research, stelt dat de vraag niet langer alleen is welke code een product bevat, maar welke code, modellen, data, infrastructuur, controles en leveranciersbeslissingen het gedrag van het systeem bepalen.

De richtlijn is vooral bruikbaar bij inkoop en leveranciersrisicomanagement. Beveiligingsteams kunnen leveranciers hiermee vragen om transparantie over modelherkomst, trainingsdata, software- en API-afhankelijkheden, licentievoorwaarden, beveiligingstests, updatecycli, runtime monitoring en verantwoordelijkheidsverdeling. De mate van controle kan verschillen per type leverancier. Grotere leveranciers moeten bijvoorbeeld inzicht geven in derdepartijmodellen, geografische datastromen, modelupdates en het gebruik van klantdata voor training. Startups moeten vooral governance, afhankelijkheidsbeheer, veilige ontwikkelpraktijken, identiteitscontroles en operationele monitoring aantonen.

Voor risicovollere toepassingen zouden AI SBOM’s onderdeel moeten zijn van een breder pakket aan leveranciersbewijs, inclusief documentatie over datastromen, beveiligingsarchitectuur, modelgedrag, privacy-effecten, red-team bevindingen, incidentrespons, logging en testen op prompt-injecties.

Een belangrijke beperking blijft dat een AI SBOM alleen inzicht geeft in wat een leverancier meldt over een AI-systeem, maar niet bewijst of het systeem betrouwbaar is voor het beoogde gebruik binnen een organisatie.