Supply chain-aanvallen nemen toe, maar veel organisaties zijn er nog niet klaar voor. In dartikel legt Gonda Lamberink, cybersecurity executive bij Bureau Veritas, uit hoe SBOM's je kunnen helpen je voor te bereiden op toekomstige bedreigingen in de toeleveringsketen. Ze benadrukt dat het begrijpen van de context van kwetsbaarheden, zoals of software echt exploiteerbaar is, onmisbaar is om de waarde van SBOM's te maximaliseren.

De bedreiging: toename van aanvallen in de toeleveringsketen

Het wijdverbreide gebruik van open-source componenten in software en kwetsbaarheden zoals Log4j en SolarWinds hebben de kwetsbaarheid van toeleveringsketens blootgelegd.

In 2024 stelt Sonatype in zijn 10e jaarlijkse State of the Software Supply Chain Report dat de aanvallen op de softwaretoeleveringsketen zijn toegenomen en verdubbeld ten opzichte van het voorgaande jaar. In augustus waren er meer dan 700.000 kwaadaardige open source software (OSS) pakketten geïdentificeerd - een duizelingwekkende stijging van 156% ten opzichte van vorig jaar - wat de escalerende risico's onderstreept voor organisaties die er niet in slagen om hun OSS afhankelijkheden effectief te beheren.

Desondanks de toenemende risico's voor toeleveringsketens is het reactievermogen van organisaties laag. Volgens de Global Cybersecurity Outlook 2024 van het World Economic Forum (WEF) gelooft 55,9% van de leiders dat technologieën zoals Generative AI aanvallers momenteel een voordeel geven, terwijl slechts 8,9% het cyberlandschap in het voordeel van verdedigers ziet. Als het gaat om aanvallen in de toeleveringsketen, heeft 54% van de organisaties onvoldoende inzicht in de cyberkwetsbaarheden in hun toeleveringsketen.

SBOM's: deel van de oplossing

Als professional in de cyberbeveiligingsindustrie ben ik van mening dat SBOM's een groot deel van de oplossing zijn voor dit beveiligingsprobleem van de toeleveringsketen en vooral voor het huidige gebrek aan transparantie in de toeleveringsketen van software. Ze hebben de potentie om een essentieel onderdeel van softwarebeveiligingspraktijken te worden: ze kunnen de samenwerking en verantwoording in de toeleveringsketen vergemakkelijken om risico's te beperken.

Wat is een SBOM?

Een SBOM (Software Bill of Materials) is in wezen een gedetailleerde lijst van alle componenten waaruit een stuk software bestaat, zoals de ingrediëntenlijst op verpakte voedingsmiddelen, geschreven in een standaardformaat. Het bevat een catalogus van alle open-source en propriëtaire softwarecomponenten. SBOM's geven organisaties transparantie in hun software supply chain, zodat ze hun beveiligingsrisico's, compliance-eisen en operationele kwetsbaarheden beter kunnen beheren.

Waarom zijn SBOM's belangrijk?

Omdat SBOM's de componenten van een softwaresysteem of -product documenteren, zijn ze essentieel voor het creëren van inzicht in potentiële kwetsbaarheden en afhankelijkheden. Twee spraakmakende incidenten benadrukken het belang van SBOM's:

• SolarWinds (2020): Aanvallers injecteerden kwaadaardige code tijdens het bouwen van de software, waardoor meer dan 18.000 klanten werden gecompromitteerd, waaronder federale agentschappen en grote bedrijven. Hoewel SBOM's de aanval niet hadden kunnen voorkomen, zouden ze cruciale ondersteuning hebben geboden: het had organisaties kunnen helpen te controleren of ze de getroffen softwareversie gebruikten en sneller te handelen om de risico's aan te pakken.
• Log4j (2021): Iedereen herinnert zich deze aanval. Een kritieke fout in een veelgebruikte Java-bibliotheek had gevolgen voor miljoenen applicaties. In tegenstelling tot SolarWinds, waar de aanval gericht was op een proces, benadrukte Log4j de risico's van afhankelijkheid van componenten. Veel organisaties wisten niet dat ze op Log4j vertrouwden, waardoor hun reactie vertraging opliep. Hier zouden SBOM's een transformatie teweeg hebben gebracht. Door organisaties gedetailleerd inzicht te geven in softwareafhankelijkheden, hadden SBOM's het mogelijk kunnen maken om het gebruik van Log4j snel te identificeren, prioriteiten te stellen voor herstel en de enorme impact van de kwetsbaarheid echt te beperken.

Regulerende druk voor gebruik van SBOM's

Regulatoren en beleidsmakers over de hele wereld hebben het belang van SBOMs onderkend. Dit zijn enkele belangrijke voorbeelden van regelgeving en beleid waarin het gebruik van SBOM's wordt genoemd of verplicht wordt gesteld:

• EU Cyber Resilience Act (CRA): Vereist SBOM's voor alle digitale producten om kwetsbaarheden in software aan te pakken en de verantwoordingsplicht in toeleveringsketens te versterken.
• US Executive Order 14028: Verplicht SBOM's voor federale overheidsopdrachten voor software, met richtlijnen van NTIA, NIST en CISA ter ondersteuning van de implementatie.
• Sectorspecifieke regels: Bedrijfstakken zoals gezondheidszorg, transport en kritieke infrastructuur leggen nu de nadruk op SBOM's om aan te sluiten bij bijv, FDA-richtlijnen voor cyberbeveiliging, UNECE-regelgeving voor typegoedkeuring van voertuigen en NIS2-regelgeving.

Hoe gebruik je SBOMs in de praktijk

Voorschriften en beleid staan natuurlijk niet gelijk aan actie. Ik zie een paar dingen die de industrie kan doen om SBOM's van de grond te krijgen en ik zou softwareleveranciers en gebruikers aanraden om het volgende te doen:

• Vendors: Genereer SBOMs in elke fase van de softwarelevenscyclus (bron, build, deployment) in overeenstemming met veelgebruikte SBOM-standaardformaten zoals SPDX en CycloneDX. Implementeer geautomatiseerde systemen voor real-time updates om de nauwkeurigheid te handhaven.
• Integrators: Neem SBOM's op in hun oplossingen en onderhoud een open communicatie met asset owners over het gebruik en de impact ervan.
• Asset owners en operators: Gebruikmaken van SBOM's om processen voor aanschaf, bedrijfsvoering, kwetsbaarhedenbeheer en incidentrespons af te stemmen op best practices voor softwarebeveiliging.

De adoptie van SBOMs wordt veel effectiever als organisaties gevestigde of ook nog steeds opkomende standaarden volgen, niet alleen voor het genereren ervan - zoals formaten als SPDX en CycloneDX - maar ook voor het delen en gebruiken ervan.

Daarnaast is mijn belangrijkste advies om SBOMs te integreren met bestaande tools, waaronder Software Composition Analysis (SCA), Continuous Integration/Continuous Deployment (CI/CD) pipelines, Governance, Risk en Compliance (GRC) systemen en vulnerability management oplossingen, wat hun bruikbaarheid enorm vergroot, vooral als ze gebruikt worden naast andere artefacten, die net zo belangrijk zijn als een SBOM, zoals een Vulnerability Exploitability eXchange (VEX) bestand, dat de status en impact bevat van kwetsbaarheden die geassocieerd zijn met een SBOM.

Deze benadering verandert SBOM's van een statische lijst in bruikbare kennis die de beveiliging, compliance en operationele workflows versterkt:

• Automatiseringstools kunnen het maken, bijwerken, delen en gebruiken van SBOM's gedurende de gehele softwarelevenscyclus stroomlijnen, waardoor het aantal fouten afneemt en de efficiëntie toeneemt.
• Door SBOM's te koppelen aan gecontextualiseerde kwetsbaarheidsgegevens, informatiefeeds over bedreigingen en governance frameworks kunnen organisaties kwetsbaarheden en risico's effectiever aanpakken.

Mijn conclusie: ja, SBOM's zijn een game-changer

Conclusie: SBOM's transformeren de beveiliging van de toeleveringsketen door te voorzien in de behoefte aan zichtbaarheid en verantwoordelijkheid, met name in kritieke sectoren. Ze leveren inzichten op waarmee organisaties risico's effectiever kunnen beheren en kwetsbaarheden beter kunnen identificeren, zoals te zien is in sectoren als de energiesector, waar SBOM's een sleutelrol spelen bij het voldoen aan compliance-eisen en het in stand houden van de activiteiten.

Ja, om antwoord te geven op de vraag die centraal staat in dit artikel: Ik denk dat SBOM's een game-changer zijn voor de beveiliging van de toeleveringsketen, vooral wanneer ze worden gecombineerd met context over de exploiteerbaarheid van kwetsbaarheden via VEX-bestanden. SBOM's identificeren kwetsbaarheden, terwijl VEX-bestanden effectief helpen om echte risico's te prioriteren en te verhelpen. Geen van beide moeten statische artefacten zijn: hun volledige potentieel wordt gerealiseerd door integratie met onder andere CI/CD-pijplijnen en systemen voor kwetsbaarhedenbeheer, waarbij automatisering ervoor zorgt dat ze consistent worden bijgewerkt en bruikbaar blijven.