Van SBOM naar kwetsbaarheidspoort: Syft en Grype in de MSP CI-pipeline

Managed service providers die CI-pipelines voor klanten draaien, kunnen twee opensourcetools van Anchore, Syft en Grype, combineren tot één poort voor de softwaretoeleveringsketen: Syft catalogiseert elk pakket in een build als software bill of materials (SBOM), en Grype toetst dat overzicht aan bekende kwetsbaarheden voordat de build wordt doorgelaten. Deze gids beschrijft wat elke tool doet, hoe ze samenwerken en waar de combinatie tekortschiet.

Genereer eerst het overzicht, met Syft

Syft, onderhouden door Anchore onder de Apache-2.0-licentie, genereert een SPDX- of CycloneDX-SBOM uit containerimages, bestandssystemen en pakketten. Anchore bracht op 17 september syft v1.52.0 uit, met een oplossing voor twee catalogerbugs die onnauwkeurige overzichten opleverden: de RPM-database-cataloger meldde een verouderde bibliotheekversie bij een single-layer Rocky Linux 10-image, en de Java-archiefcataloger gaf een onbekende versie terug voor uber-jars. De release bevat ook onderhoud van afhankelijkheden: 52 wijzigingen die zes bekende kwetsbaarheden verhelpen, waaronder een update van de grpc-go-bibliotheek die meerdere gepubliceerde advisories sloot. De catalogercorrecties zijn vooral relevant voor teams die RPM-images of Java-uber-jars gebruiken, waar een verouderde of onbekende versie in het SBOM anders zou verhullen wat een scanner verderop daadwerkelijk controleert.

Grype maakt van het overzicht een poort

Grype, eveneens onderhouden door Anchore, doorzoekt containerimages, bestandssystemen en SBOM's op bekende kwetsbaarheden. Op 23 september 2026 toonde de GitHub-repository ongeveer 12.900 sterren en een commit van twee dagen eerder, wat wijst op actief onderhoud. Direct na het genereren van het SBOM in een CI-pipeline ingebouwd, laat Grype een build automatisch mislukken zodra een bekende CVE opduikt, in plaats van te vertrouwen op iemand die het later controleert. De standaardflow genereert het SBOM tijdens de build, meestal met Syft, en voert Grype vervolgens uit tegen dat SBOM en optioneel rechtstreeks tegen de gebouwde image, waarbij elk vermeld onderdeel wordt getoetst aan bekende kwetsbaarheidsgegevens. Een ernstdrempel bepaalt of de job mislukt: alles daarboven blokkeert de merge, tenzij er een benoemde uitzondering met vervaldatum is vastgelegd.

Maak uitzonderingen zichtbaar, niet stil

Een fail-closed poort heeft alleen zin als uitzonderingen zichtbaar zijn en een eigenaar hebben. Zonder een schriftelijk uitzonderingsproces zetten teams de poort uit zodra die iets urgents blokkeert, of stapelen ze stille overrides op die het hele doel van de scan tenietdoen. Een uitzondering moet een eigenaar, een reden en een vervaldatum vermelden waarna de bevinding opnieuw wordt beoordeeld, en niet onbeperkt gelden.

Wat de poort niet doet

Grype laat zien wat bekend kwetsbaar is in wat op het punt staat te worden uitgerold; het patcht niets, dwingt geen minimale rechten af en vervangt geen runtimemonitoring zodra een workload is uitgerold. Ook is het afhankelijk van hoe actueel de kwetsbaarhedendatabase is, dus de scanner vastzetten op een verouderde feed ondermijnt het doel. Bij het standaardiseren hiervan over klantpipelines is het praktisch om ernstdrempels eerst in een niet-productiepipeline te testen, want een te agressieve drempel leert teams alleen om de poort te omzeilen. Elk SBOM archiveren naast het bijbehorende buildartefact maakt van datzelfde overzicht ook een bewijspakket voor klanten of verzekeraars, zonder extra scankosten. Wie externe hulp nodig heeft bij penetratietests, kwetsbaarheidsbeoordelingen, incident response of NIS2/DORA/AVG-naleving kan terecht bij de cybersecuritydiensten van Altovar.

Wat te doen

• Voeg Syft toe als buildstap die voor elke image of elk artefact een SPDX- of CycloneDX-SBOM oplevert, en laat de build mislukken als het genereren een fout geeft.
• Voer Grype direct daarna uit tegen dat SBOM, en optioneel tegen de gebouwde image, met een ernstdrempel die eerst in een niet-productiepipeline is getest.
• Leg het uitzonderingsproces vast voordat de poort live gaat: wie een uitzondering mag toekennen, wat die moet vastleggen en wanneer die vervalt.
• Archiveer elk SBOM samen met het bijbehorende buildartefact, zodat het later als bewijspakket voor klanten of verzekeraars kan dienen.
• Houd de kwetsbaarhedendatabase van Grype actueel; een verouderde feed laat builds door die de poort had moeten blokkeren.
• Combineer de poort met patchen en runtimemonitoring, want geen van beide tools dekt wat er na de uitrol gebeurt.

Bronnen: Grype op GitHub, releases van anchore/syft.