Een Software Bill of Materials (SBOM) is een machinaal leesbare inventaris van alle componenten, libraries en afhankelijkheden in uw softwareproduct. Moderne applicaties leunen voor 70 tot 90 procent op code die iemand anders ooit heeft geschreven. Als één van die bouwstenen kapot is, breekt uw product.
Sinds de CRA is dit geen best practice meer maar een wettelijke eis: bij elke release moet u een actuele, machinaal leesbare SBOM kunnen overleggen (Annex I).
Twee formaten: SPDX en CycloneDX
U stelt een SBOM niet handmatig op: volwassen open-source tools (zoals Syft, Trivy of cdxgen) genereren hem automatisch uit uw build. U kiest alleen het formaat — er zijn twee erkende standaarden, elk met een eigen focus:
SPDX
Ontworpen vanuit juridisch en compliance perspectief (Linux Foundation). Ongeëvenaard in licentie-details. Officieel ISO-gecertificeerd en vaak geëist door overheden.
CycloneDX
Ontworpen door security-engineers (OWASP). Lichtgewicht en perfect geïntegreerd in snelle CI/CD pipelines. Biedt native ondersteuning voor VEX-documenten.
De Transitieve IJsberg
Een SBOM die alleen de "directe" ingrediënten laat zien (de libraries die uw developers expliciet hebben toegevoegd), geeft een vals gevoel van veiligheid. Zodra u één library toevoegt, trekt deze zijn eigen benodigdheden mee. Dit noemen we transitieve afhankelijkheden. Een simpel project met 5 libraries explodeert onder water al snel tot een web van 500+ geneste componenten. Uw SBOM-scanner moet de volledige diepte van deze ijsberg in kaart kunnen brengen.
De Redding: VEX (Vulnerability Exploitability eXchange)
VEX is een aanvullend, machinaal leesbaar document dat náást de SBOM leeft. Hierin specificeert u de werkelijke status van een lek. Staat de status op Not Affected (omdat de kwetsbare code nooit wordt aangeroepen)? Dan kleurt uw dashboard groen en filtert u de ruis weg. VEX stelt uw team in staat om alleen te patchen wat daadwerkelijk een risico vormt voor het eindproduct.
Verdrinken in de ruis
Zodra uw SBOM volautomatisch wordt gegenereerd, ontstaat het volgende probleem: de scanner slaat alarm. Vaak worden er honderden "Kritieke" CVE's (kwetsbaarheden) gevonden in uw duizenden transitieve dependencies. Ontwikkelaars importeren vaak een gigantische library om slechts 5% van de code (één functie) te gebruiken. Bevindt het lek zich in de ongebruikte 95%? Dan is uw applicatie niet hackbaar (onbereikbaar of Unreachable).
Twee technieken doen het zware werk. Reachability-analyse controleert of de kwetsbare code überhaupt in een actief codepad zit; VEX legt per lek vast of uw product daadwerkelijk geraakt wordt. Zet ze hieronder aan en zie hoe een typische lijst van bijna 500 meldingen inkrimpt tot de handvol die er écht toe doet:
Hoeveel ruis zit er in úw pijplijn?
Ontdek in twee minuten hoe ver uw SBOM- en VEX-aanpak is met de gratis Quickscan, of bouw het stap voor stap op in de 4-weekse Survival Challenge.