De zachte materialenlijst

Wat is een SBOM? Het is een relatief nieuw begrip in het security werkveld waar ik flink aan moet wennen. In eerste instantie omdat de afkorting nog niet gangbaar is, maar ook omdat het gebruik van de term in het onderbewustzijn een alarm laat afgaan. Een bom, welke soort dan ook, moet toch slecht nieuws zijn?

SBOM staat voor ‘Software Bill of Materials’ Het is een document dat een gedetailleerde lijst omvat van de componenten en afhankelijkheden van een softwarecomponent. Het is vergelijkbaar met een traditionele Bill of Materials (BOM) die wordt gebruikt in de maakindustrie om de samenstellende onderdelen van een product te identificeren. Er is ook een belangrijk verschil: het gebruik ervan. Een traditionele BOM is een belangrijk sturend element in de processen rond industriële planning en productie. Bij de productie van tastbare producten moeten onderdelen in voldoende aantallen beschikbaar zijn. We hebben tijdens de COVID-19-crisis gezien wat een verstoring in de beschikbaarheid kan doen. We hadden te maken met warenhuizen vol met koelkasten en parkeerplaatsen vol met auto’s die wachtten op de montage van chips. En toen alle processen weer opgestart werden, duurde het maanden voordat beschikbaarheid en planning weer helemaal op orde waren, als ze dat al zijn.

Software is anders. Een softwareproduct bestaat uit bits. Het is onbeperkt te kopiëren en elektronisch te leveren. Je hebt geen last van een scheefligger in het Suezkanaal. Waar je wel last van hebt, zijn kwetsbaarheden die meegebakken worden in het productieproces. Daar is al zo’n twintig, dertig jaar een standaardantwoord op: software updates. Na productie kwetsbare componenten in hardware vervangen is complex. Dat vergt terugroepacties om het product te vervangen of te laten repareren: logistiek complex, heel kostbaar voor de fabrikant en iets wat zoveel mogelijk voorkomen wordt door strenge eisen te stellen aan de hele productieketen. De BOM speelt hierin een grote rol, alle eisen die gesteld worden staan hierin en worden bij het betrekken van de componenten al meegenomen.

Deze rol heeft de SBOM niet. Wellicht kan het in de toekomst hier naartoe groeien, maar de software-industrie is hier nog lang niet aan toe. De SBOM stelt je wel in staat makkelijk en snel vast te stellen welke kwetsbaarheden in je softwareproducten zitten. Dan moet je er zelf nog iets mee doen. In het beste geval worden updates meegenomen in een automatische dienst van de leverancier, in alle andere gevallen is het aan jou om de kwetsbaarheid te detecteren en te repareren.

De verhalen over incidenten waarbij het misging zijn talrijk. ‘Heartbleed’, ‘SolarWinds’, ‘Colonial Pipelines’ en ‘log4j’ zijn wereldnieuws geweest. SBOM is een handige component in de detectie van de kwetsbaarheden, doordat de informatie in de SBOM te combineren is met publicaties van kwetsbaarheden. Dit is ondoenlijk met de hand, hier heb je automatisering voor nodig. Zonder SBOM zou je de software zelf moeten scannen en hopen dat je daarmee alles vindt. En dan updates krijgen die de kwetsbaarheden oplossen of zorgen voor andere acceptabele alternatieven.

Dus qua beveiliging is de bijdrage van een SBOM primair detectie. En dan alleen wanneer je dit kunt integreren in je vulnerability scanning-proces. Andere responsprocedures rond patch management kunnen hierdoor geïnitieerd worden, maar dan moeten die wel beschikbaar zijn en de capaciteit hebben. Het geeft ook de mogelijkheid om kwaliteitseisen te stellen aan de leveranciers in je ketens. Je kunt eisen dat een leverancier vulnerability management aantoonbaar op orde heeft met integratie van SBOMs. En de aantoonbaarheid hiervan is ook relatief eenvoudig door een check op de current state SBOM. Wellicht wordt dit iets om te standaardiseren voor NIS 2…

Lex Borger
Security consultant bij Tesorion en oud-hoofdredacteur van iB-Magazine.
Lex is bereikbaar via lex.borger@tesorion.nl

Deze column verscheen in IB5-2023.