A Reality Check on SBOM-based Vulnerability Management: An Empirical Study and A Path Forward
Deze empirische studie toont aan dat hoewel lock-files nauwkeurige SBOMs genereren, downstream-scanresultaten vaak door valse positieven worden overspoeld door bereikbaarheidsproblemen, maar dat het combineren van deze SBOMs met functie-call-analyse deze alarmen met 61,9% kan reduceren en zo een praktische tweestapsaanpak biedt voor effectief kwetsbaarheidsbeheer.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
De Hoofdgedachte: Een Reality Check voor Softwareveiligheid
Stel je voor dat je een gigantische, complexe machine bouwt (zoals een auto of een robot). Je hebt zelf niet alle onderdelen gemaakt; je hebt ze gekocht van verschillende leveranciers. Je hebt een lijst met onderdelen nodig om te weten wat er in je machine zit. In de softwarewereld heet deze lijst een SBOM (Software Bill of Materials).
De onderzoekers van dit paper hebben gekeken naar hoe goed deze lijsten worden gemaakt en hoe goed ze worden gebruikt om veiligheidsrisico's te vinden. Hun conclusie? We doen het nu op twee manieren verkeerd, maar we hebben een oplossing.
Deel 1: Het Probleem met de Lijst (De SBOM)
De situatie:
Veel ontwikkelaars maken hun lijst met onderdelen op basis van een "wenslijstje" (een projectbestand). Ze schrijven daarop: "Ik wil een motor, en die moet tussen de 100 en 200 pk zijn."
- Het probleem: De lijst vertelt niet welke motor er precies is gemonteerd. Misschien is het een 100-pk, misschien een 199-pk. Als je een lijst maakt op basis van dit wazige wenslijstje, krijg je een onnauwkeurige SBOM. Soms staat er een onderdeel op dat er niet is, of mist er eentje dat er wel is.
De oplossing (De "Lock File"):
De onderzoekers zeggen: "Gebruik geen wenslijstje, gebruik de factuur!"
In de softwarewereld heet dit een Lock File. Dit is een bestand dat precies aangeeft: "Op dit moment, op deze machine, zit er een 150-pk motor van merk X met serienummer Y in."
- De uitkomst: Als je deze exacte factuur (Lock File) gebruikt, krijgen verschillende tools exact dezelfde, perfecte lijst. Geen ruzie meer, geen twijfel. Het is 100% accuraat.
Vergelijking: Het is als het verschil tussen een recept dat zegt "voeg wat suiker toe" (onnauwkeurig) en een recept dat zegt "voeg precies 50 gram suiker toe" (nauwkeurig).
Deel 2: Het Grootste Probleem (De Valse Alarmen)
Dit is het meest verrassende deel van het onderzoek. Zelfs als je die perfecte lijst (de SBOM) hebt, werkt de veiligheidscontrole nog steeds slecht.
De situatie:
Stel je voor dat je een auto bouwt met duizenden onderdelen. De veiligheidscontroleur (de scanner) kijkt naar zijn database en zegt: "Oeps! De motor van deze auto heeft een bekend veiligheidsprobleem. De remmen van deze auto hebben een defect. De radio heeft een lek."
De controleur kijkt alleen naar de naam van het onderdeel. Hij ziet dat de motor in de lijst staat, en dus zegt hij: "Gevaar!"
De realiteit:
In jouw specifieke auto heb je die motor wel, maar je gebruikt hem nooit. Je hebt een elektrische motor gebruikt, en de verbrandingsmotor (met het probleem) zit erin, maar hij is afgesloten en wordt nooit aangeraakt.
- Het resultaat: De scanner schreeuwt om hulp, maar er is geen gevaar. Dit heet een valse alarm.
De cijfers:
De onderzoekers keken naar 2.414 softwareprojecten. Ze ontdekten dat 92% van de veiligheidsalarms die de scanners gaven, valse alarmen waren!
- Ontwikkelaars worden overspoeld met meldingen ("Alert Fatigue").
- Omdat er zoveel onzin is, beginnen ze de meldingen te negeren.
- Het gevaarlijke is: als ze alles negeren, missen ze misschien wel het échte gevaar dat er wél is.
Vergelijking: Het is als een huisalarm dat afgaat als er een vliegje binnenkomt. Als het alarm elke dag afgaat voor vliegjes, ga je het op een dag uitzetten. En dan komt er een inbreker, en hoor je niets.
Deel 3: De Oplossing (Kijken naar wat er echt gebeurt)
Hoe lossen we dit op? We moeten niet alleen kijken naar de lijst met onderdelen, maar ook kijken naar hoe de machine werkt.
De oplossing:
De onderzoekers hebben gekeken of ze kunnen analyseren of het "gevaarlijke onderdeel" wel echt wordt gebruikt.
- Ze keken of de code die het probleem veroorzaakt, wel echt wordt aangeroepen door de software.
- Als de code niet wordt gebruikt, is het veilig. Geen alarm!
Het resultaat:
Door deze extra stap (die ze "functie-analyse" noemen) konden ze 62% van de valse alarmen weggooien.
- In plaats van 100 meldingen, krijg je er nog maar 38.
- Die 38 meldingen zijn veel waardevoller en kunnen sneller opgelost worden.
Vergelijking: In plaats van te zeggen "Er zit een gevaarlijk mes in de keuken, wees voorzichtig!", zegt de nieuwe scanner: "Er zit een gevaarlijk mes in de keuken, maar niemand gebruikt het, dus je kunt rustig slapen. Maar let op, die schaar op tafel wordt wel gebruikt, die is gevaarlijk."
Samenvatting: Wat moeten we doen?
De onderzoekers geven een duidelijk stappenplan voor de toekomst:
- Gebruik de "Factuur" (Lock Files): Zorg dat je software bouwt met tools die een exacte lijst maken van wat er geïnstalleerd is. Gebruik geen vage wenslijstjes. Dit zorgt voor een betrouwbare basis.
- Kijk naar de "Gebruik" (Reachability): Veiligheidstools moeten niet alleen kijken naar wat er in de lijst staat, maar ook analyseren of die onderdelen wel echt worden gebruikt. Als ze niet worden gebruikt, is het geen risico.
Conclusie:
Als we dit doen, stoppen we met het creëren van een lawaai van valse alarmen. Ontwikkelaars krijgen rustigere, duidelijkere meldingen over de echte gevaren. Dat maakt software veiliger voor iedereen.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.