Från SBOM till sårbarhetsgrind: Syft och Grype i MSP:ers CI-pipeline

Managed service providers som kör CI-pipelines åt kunder kan kombinera två öppen källkods-verktyg från Anchore, Syft och Grype, till en enda grind för mjukvarans leveranskedja: Syft katalogiserar varje paket i en build som en materialförteckning för programvara (SBOM), och Grype kontrollerar den förteckningen mot kända sårbarheter innan builden får gå igenom. Den här guiden går igenom vad respektive verktyg gör, hur de kompletterar varandra och var kombinationen inte räcker på egen hand.

Skapa förteckningen först, med Syft

Syft, som underhålls av Anchore under Apache-2.0-licensen, genererar en SBOM i SPDX- eller CycloneDX-format från containeravbildningar, filsystem och paket. Anchore släppte syft v1.52.0 den 17 september och rättade då två katalogiseringsfel som gav felaktiga förteckningar: RPM-databaskatalogiseraren rapporterade en föråldrad biblioteksversion från en enskiktad Rocky Linux 10-avbildning, och Java-arkivkatalogiseraren returnerade en okänd version för uber-jars. Utgåvan innehåller också beroendeunderhåll: 52 ändringar som åtgärdar sex kända sårbarheter, inklusive en uppdatering av grpc-go-biblioteket som stängde flera publicerade rådgivningar. Katalogiseringsrättningarna spelar störst roll för team som förlitar sig på RPM-baserade avbildningar eller Java-uber-jars, där en föråldrad eller okänd version i SBOM:en annars skulle dölja vad en skanner längre fram faktiskt kontrollerar.

Grype gör om förteckningen till en grind

Grype, som också underhålls av Anchore, skannar containeravbildningar, filsystem och SBOM:er efter kända sårbarheter. Den 23 september 2026 visade dess GitHub-repo omkring 12 900 stjärnor och en commit från två dagar tidigare, vilket tyder på aktivt underhåll. Kopplad till en CI-pipeline direkt efter att SBOM:en genererats låter Grype en build misslyckas automatiskt så fort en känd CVE dyker upp, i stället för att förlita sig på att någon kommer ihåg att kontrollera senare. Standardflödet genererar SBOM:en under builden, ofta med Syft, och kör sedan Grype mot den SBOM:en och, valfritt, direkt mot den byggda avbildningen, och stämmer av varje listad komponent mot kända sårbarhetsdata. En allvarlighetströskel avgör om jobbet misslyckas: allt över den blockerar sammanslagningen om det inte finns ett namngivet undantag med tidsgräns registrerat.

Gör undantag synliga, inte tysta

En fail-closed-grind är bara till nytta om undantagen är synliga och har en ägare. Utan en skriftlig undantagsprocess stänger team antingen av grinden första gången den blockerar något akut, eller så samlas tysta överridningar på hög som gör själva skanningen meningslös. Ett undantag bör ange en ägare, en orsak och ett utgångsdatum då fyndet omprövas, i stället för att gälla på obestämd tid.

Vad grinden inte gör

Grype visar vad som är känt sårbart i det som är på väg att levereras; den installerar inga patchar, tvingar inte fram principen om minsta möjliga behörighet och ersätter inte runtime-övervakning när en arbetslast väl är driftsatt. Den beror också på hur aktuell dess sårbarhetsdatabas är, så att låsa skannern vid ett föråldrat flöde gör syftet om intet. Vid standardisering av det här upplägget över kundernas pipelines är det praktiska att först testa allvarlighetströsklar i en icke-produktionspipeline, eftersom en alltför aggressiv tröskel bara lär teamen att gå runt grinden. Att arkivera varje SBOM tillsammans med sitt buildartefakt gör dessutom samma förteckning till ett bevispaket för kunder eller försäkringsbolag, utan extra skanningskostnad. Leverantörer som behöver extern hjälp med penetrationstester, sårbarhetsbedömning, incidenthantering eller efterlevnad av NIS2/DORA/GDPR kan vända sig till Altovars cybersäkerhetstjänster.

Vad du bör göra

• Lägg till Syft som ett buildsteg som skapar en SPDX- eller CycloneDX-SBOM för varje avbildning eller artefakt, och låt builden misslyckas om genereringen ger ett fel.
• Kör Grype mot den SBOM:en, och valfritt mot den byggda avbildningen, direkt efteråt, med en allvarlighetströskel som testats i en icke-produktionspipeline först.
• Skriv ner undantagsprocessen innan grinden går live: vem som får bevilja ett undantag, vad det måste dokumentera och när det upphör att gälla.
• Arkivera varje SBOM tillsammans med sitt buildartefakt så att det senare kan fungera som ett bevispaket för kunder eller försäkringsbolag.
• Håll Grypes sårbarhetsdatabas uppdaterad; ett föråldrat flöde släpper igenom builds som grinden borde ha blockerat.
• Kombinera grinden med patchning och runtime-övervakning, eftersom inget av verktygen täcker vad som händer efter driftsättningen.

Källor: Grype på GitHub, anchore/syft-utgåvor.