Van SCA naar SBOM: een praktische migratiegids
| Interlynk
De meeste teams die Software Composition Analysis draaien, hebben in feite al een SBOM-pijplijn in bedrijf. Ze bewaren de uitkomst alleen niet. De tool bouwt een inventaris van hun afhankelijkheden, vergelijkt die met kwetsbaarheidsdata en sluit het resultaat op in een console die je per gebruiker huurt. De inventaris die centraal staat in dat hele proces is een software bill of materials (softwarestuklijst) in alles behalve de naam.
Zodra je SCA op die manier bekijkt, voelt migreren naar een SBOM-first-workflow niet langer als een rip-and-replace-project, maar als het terugnemen van een artefact dat je toch al produceerde. Deze gids loopt door wat de twee benaderingen feitelijk doen, waarom een open SBOM-workflow een losstaande scanner kan vervangen, aan welke voorwaarden je eerst moet voldoen, en een migratiepad dat je kunt afleggen zonder een gat in je dekking.
Wat een SCA-tool mechanisch gezien doet
Het helpt om te scheiden wát een SCA-product doet van hóe het verpakt is. Onder het dashboard bestaat het werk uit drie opeenvolgende stappen.
De tool bouwt een afhankelijkheidsinventaris. Hij loopt door je lockfiles en manifesten, lost de volledige transitieve boom op, en produceert een lijst met componenten inclusief versies en identifiers zoals purl en CPE. Deze lijst is per definitie een software bill of materials. Hij wordt simpelweg getoond binnen een propriëtaire interface in plaats van teruggegeven als een overdraagbaar bestand.
Vervolgens vergelijkt de tool die inventaris met een kwetsbaarheidsdatabase en een set licentiebeleidsregels, wat bevindingen oplevert.
Ten slotte presenteert hij die bevindingen via een workflow die je licentieert: dashboards, gates, rapporten en toegang per gebruiker.
De eerste stap is SBOM-generatie. De tweede is kwetsbaarheidsmatching. De derde is de verpakking. Inzien dat de eerste twee commodity-handelingen zijn, en dat de derde datgene is waarvoor je een premie betaalt, vormt de basis van het migratieargument.
Wat een SBOM-first-workflow doet
Een SBOM-first-workflow voert dezelfde twee mechanische handelingen uit. Het verschil is dat hij ze ontkoppelt en het artefact centraal houdt.
Je genereert een gestandaardiseerde SBOM tijdens de build. De twee dominante formaten zijn SPDX, de Linux Foundation-standaard die internationaal erkend is als ISO/IEC 5962:2021, en CycloneDX, de OWASP-vlaggenschipstandaard die geratificeerd is als ECMA-424. Beide zijn machineleesbaar, beide zijn open, en beide worden ondersteund binnen een uitgebreid ecosysteem van tooling.
Vervolgens vergelijk je die SBOM doorlopend met kwetsbaarheidsinformatie, en pas je triagedata toe om bevindingen te onderdrukken die niet op jouw deployment van toepassing zijn.
Het resultaat is een overdraagbaar, ondertekenbaar bestand dat precies vastlegt wat er is uitgeleverd. Je kunt het weken later opnieuw scannen, het delen met een klant, of het indienen bij een toezichthouder. Geen van die dingen kun je betrouwbaar doen met bevindingen die opgesloten zitten in een leverancierconsole.
Het echte onderscheid: eigenaarschap, niet capaciteit
Het is de moeite waard om precies te zijn over waar SCA en een SBOM-workflow daadwerkelijk verschillen, want dat zit niet in wat ze kunnen detecteren.
Een losstaande scanner produceert bevindingen binnen een interface die je niet bezit en niet kunt meenemen. Een SBOM-workflow produceert een gestandaardiseerd artefact dat je volledig in eigendom hebt en overal kunt hergebruiken. De kwetsbaarheidsmatching, de licentiecontroles, het oplossen van afhankelijkheden: die zijn in beide aanwezig. Wat verandert, is of je weggaat met een asset of met een abonnement.
Elk praktisch voordeel van de SBOM-benadering vloeit voort uit dat ene verschil. Overdraagbaarheid, herbruikbaarheid tussen teams, langetermijn-herscannen en direct gebruik voor compliance hangen allemaal af van het bezitten van het artefact in plaats van het bekijken ervan via het product van iemand anders.
U hebt de kwetsbaarheidsdatabase van de leverancier niet meer nodig
Jarenlang was het sterkste bezwaar tegen het loslaten van SCA de data. De aanname was dat de kwetsbaarheidsfeed van een commerciële leverancier wezenlijk beter was dan alles wat je zelf kon samenstellen. Dat voordeel is grotendeels verdwenen.
OSV.dev, de open kwetsbaarheidsdatabase van Google, levert nauwkeurige getroffen versiebereiken op versieniveau over ecosystemen heen, en de bijbehorende scanner leest SPDX- en CycloneDX-SBOM's rechtstreeks. Open matchers zoals Grype kruisverwijzen de NVD, OSV en ecosysteemspecifieke advisories, dat zijn dezelfde primaire bronnen waaruit commerciële tools putten. OWASP Dependency-Track gaat nog verder: in plaats van één keer te scannen, neemt het SBOM's op in een persistente opslag en herevalueert het ze doorlopend zodra er nieuwe CVE's worden gepubliceerd, met ingebouwde EPSS-gebaseerde prioritering.
Die doorlopende herevaluatie is de capaciteit die de meeste scannergebruikers onderschatten. Een momentopname-scan rapporteert wat kwetsbaar was op het moment dat hij draaide. Een gemonitorde SBOM rapporteert wat nú kwetsbaar is, want een component die schoon was tijdens de build kan ná de release worden geconfronteerd met een onthulde kritieke kwetsbaarheid. Een pijplijnscan die alleen bij een commit wordt getriggerd, mist dat venster volledig; een doorlopend gemonitorde SBOM niet.
Voor false positives laat VEX (Vulnerability Exploitability eXchange) je in een gedocumenteerde en auditeerbare vorm vaststellen dat een gemarkeerde kwetsbaarheid in jouw specifieke context niet bereikbaar of exploiteerbaar is, en je tooling die op die basis onderdrukken. Dit is een verdedigbaar, toetsbaar record in plaats van een instelling die verborgen zit in een propriëtaire console.
Voor gereguleerde teams is de SBOM al verplicht
In gereguleerde software is het argument voor een SBOM-first-workflow niet alleen gegrond, het is bijna onvermijdelijk, omdat de SBOM al een verplichte deliverable is.
Software voor medische apparatuur is het duidelijkste voorbeeld. Onder Section 524B van de FD&C Act, van kracht sinds 29 maart 2023, moeten fabrikanten van "cyber devices" een machineleesbare SBOM opnemen die commerciële, open-source en kant-en-klare componenten dekt in hun premarket-indieningen. De definitieve premarket-cybersecurityrichtlijn van de FDA, uitgebracht in juni 2025, maakt van een ontoereikende SBOM een grond voor een Refuse-to-Accept-besluit en wijst SPDX en CycloneDX aan als verwachte formaten.
In bredere zin verhogen CISA's 2025 Minimum Elements for an SBOM, voortbouwend op de NTIA-basislijn uit 2021, de verwachtingen met aanvullende velden waaronder componenthash, licentie, toolnaam en generatiecontext, allemaal bedoeld om machineverwerkbaar gebruik op schaal te ondersteunen.
De implicatie is direct. Als je in dit domein opereert, genereer je sowieso al een SBOM voor compliance, ongeacht welke scanner je draait. Je kwetsbaarheidsdetectie op datzelfde artefact richten voegt geen workflow toe; het consolideert er twee. Het alternatief is een leverancier betalen om een afhankelijkheidsinventaris te bouwen, en die inventaris vervolgens opnieuw op te bouwen in een ander formaat voor de toezichthouder, zonder gedeelde bron van waarheid tussen beide. Die duplicatie is het gat tussen operationele supply-chainbeveiliging en het afvinken van compliancevakjes, en het is precies de kostenpost die een SBOM-first-workflow wegneemt.
Hetzelfde patroon tekent zich af in Europa: onder de Cyber Resilience Act (CRA) staat de SBOM eveneens centraal, en onder NIS2 — en de Nederlandse omzetting daarvan — gelden verplichtingen voor supply-chainbeveiliging, met het NCSC-NL als de nationale autoriteit.
Twee voorwaarden voor een volledige vervanging
Een SBOM-first-workflow kan losstaande SCA volledig vervangen, maar alleen wanneer aan twee voorwaarden is voldaan. Het is de moeite waard ze expliciet te benoemen, want ze overslaan is de manier waarop SBOM-programma's mislukken.
Je hebt toegang nodig tot de code of de build. De meest accurate SBOM's worden gegenereerd tijdens de build, vanuit de broncode, waar de resolver de werkelijke transitieve boom en de exacte versies die worden uitgeleverd waarneemt. Achteraf een gesloten binary van derden scannen kan, maar levert verlies op. Als je CI kunt instrumenteren om bij elke build een SBOM te emitteren, behaal je een nauwkeurigheid die evenaart of overtreft wat een SCA-tool extern reconstrueert. Waar je de build niet kunt aanraken, is de SBOM-benadering wezenlijk lastiger, en dat moet meewegen in je planning.
Je hebt een gecoördineerde workflow nodig tussen Development en Compliance. Dit is het deel dat geen enkele tool kan leveren. Engineering is eigenaar van de generatie: SBOM's worden in CI geproduceerd als een standaard build-output, vergelijkbaar met een testrapport. Security en Compliance zijn eigenaar van de consumptie: het opnemen van SBOM's, ze doorlopend monitoren, VEX eraan koppelen en de regulatoire indiening voeden. Wanneer die twee helften niet verbonden zijn, worden SBOM's gegenereerd en nooit bekeken, wat precies de faalmodus is die het formaat zijn reputatie als afvinkoefening bezorgde.
Voldoe aan beide voorwaarden en er is geen functie die een losstaande scanner uitvoert die je eigen pijplijn niet kan, met aan het eind een overdraagbaar artefact in je bezit. Mis een van beide en de juiste zet is om eerst de workflow te repareren en je bestaande tooling te behouden tot je dat hebt gedaan.
Het migratiepad
De overgang vereist geen harde omschakeling. Draai de SBOM-workflow naast je bestaande scanner totdat hij pariteit bereikt, en zeg dan het abonnement op.
Genereer. Emit een SPDX- of CycloneDX-SBOM bij elke CI-build, vanuit de broncode, en behandel die als een eersteklas build-artefact.
Opslaan en monitoren. Neem die SBOM's op in een platform voor doorlopende monitoring, zodat ze worden herevalueerd tegen OSV-, NVD- en advisory-feeds zodra er nieuwe kwetsbaarheden worden gepubliceerd, en niet alleen op het moment van scannen.
Triage. Adopteer VEX voor gedocumenteerde, auditeerbare onderdrukking van niet-exploiteerbare bevindingen, en gebruik EPSS om de remediatie-inspanning te prioriteren waar het ertoe doet.
Verbind compliance. Stuur dezelfde SBOM's naar je regulatoire indieningen, zodat één artefact zowel kwetsbaarheidsbeheer als compliance bedient.
Vergelijk en schakel over. Draai beide systemen een release of twee parallel. Zodra de SBOM-workflow opvangt wat de scanner opving, terwijl hij óók doorlopende dekking en een artefact in eigen bezit biedt, zet je de losstaande tool buiten gebruik
Conclusie
Software Composition Analysis was een zinvol product in een tijdperk zonder SBOM-standaarden. Dat tijdperk ligt achter ons. SPDX en CycloneDX zijn internationale standaarden, de kwetsbaarheidsdata is open, de ondersteunende tooling is volwassen, en in gereguleerde software is de SBOM verplicht, ongeacht welke scanner je gebruikt.
Zodra je een gestandaardiseerde SBOM produceert die je zelf bezit, is een aparte leverancier betalen om diezelfde inventaris achter een console opnieuw op te bouwen, ronduit gesteld, betalen voor compliancetheater in plaats van operationele beveiliging. Met toegang tot de code en een gecoördineerde workflow tussen Development en Compliance doet een SBOM-first-pijplijn alles wat een losstaande SCA-tool doet, en houd je aan het eind het artefact in handen.
Verder lezen: SPDX (Linux Foundation, ISO/IEC 5962:2021) · OWASP CycloneDX (ECMA-424) · CISA 2025 Minimum Elements for an SBOM · FDA premarket cybersecurity guidance · OSV.dev · OWASP Dependency-Track