SBOM med Syft + Grype: Sårbarhetshantering i CI/CD

En modern applikation består till största delen av kod ni inte skrivit själva: öppna bibliotek, bas-images, transitiva beroenden i flera led. När en allvarlig sårbarhet dyker upp i ett populärt paket är den första frågan alltid densamma: använder vi det, och var? Bolag som inte kan svara snabbt får panik; bolag som har en SBOM svarar på minuter. Den här guiden visar hur du bygger den förmågan med Syft och Grype, direkt i din CI/CD-pipeline.

Jag bygger sårbarhetshantering in i utvecklingsflöden inom cybersäkerhet, och poängen är att göra säkerheten kontinuerlig istället för en periodisk granskning som alltid ligger steget efter. Vi har sett gång på gång hur en enda sårbarhet i ett brett använt bibliotek kan utlösa veckor av brandsläckning över hela branschen. De bolag som hanterade sådana händelser lugnt var inte de med flest säkerhetsexperter, utan de som på minuter kunde svara på var det sårbara paketet fanns. Den förmågan är förvånansvärt billig att bygga, och den här guiden visar hur.

Vad en SBOM är och varför den är grunden

En SBOM, Software Bill of Materials, är en strukturerad förteckning över alla komponenter i en applikation, i praktiken en innehållsdeklaration för din mjukvara. Utan den är beroendekedjan en blackbox, och sårbarhetshantering blir gissningar. Med den blir frågan om en ny sårbarhet en sökning, inte en utredning. SBOM är också ett krav som dyker upp allt oftare i upphandlingar och hör ihop med säker utveckling under NIS2 artikel 21.

Syft: generera SBOM:en

Syft är ett öppet verktyg som skannar ett filsystem eller en container-image och producerar en SBOM i standardformat som SPDX eller CycloneDX. Det går att köra mot en byggd image i pipelinen så att varje release får en aktuell innehållsdeklaration. Tanken är enkel: ingen artefakt går vidare utan att man vet vad den innehåller.

Grype: hitta sårbarheterna

Grype tar SBOM:en (eller en image direkt) och matchar komponenterna mot kända sårbarhetsdatabaser. Resultatet är en lista över sårbarheter med allvarlighetsgrad, kopplad till exakt vilket paket och vilken version som är drabbat. Eftersom det utgår från SBOM:en blir skanningen både snabb och spårbar.

En fördel med att separera de två stegen, Syft genererar, Grype matchar, är att SBOM:en blir en bestående artefakt med ett eget värde. Den beskriver vad ni byggde vid en viss tidpunkt och kan skannas om i framtiden mot nya sårbarheter utan att ni behöver bygga om något. När en ny allvarlig sårbarhet offentliggörs kan ni alltså köra Grype mot era sparade SBOM:er och omedelbart se vilka releaser som är drabbade, även sådana som redan ligger i produktion. Det är just den retroaktiva förmågan som gör att bolag med SBOM kan svara på minuter där andra famlar i timmar eller dagar.

Här gör jag mid-vägs alltid en första baslinjeskanning av era befintliga images. Den visar nuläget, ofta finns det redan kända sårbarheter i produktion som ingen haft verktyg att upptäcka. Vill ni ha den gjord ingår det i cybersäkerhetsuppdraget.

Integrera i CI/CD utan att bromsa teamet

• Generera SBOM vid varje bygge med Syft och spara den som en artefakt knuten till releasen.
• Skanna med Grype som ett steg i pipelinen.
• Sätt en rimlig tröskel. Bryt bygget vid kritiska sårbarheter, men undvik att blockera på allt, annars lär sig teamet att ignorera larmen.
• Hantera falska positiva och accepterad risk med en tydlig process, så att undantag är medvetna och dokumenterade.
• Skanna om regelbundet. En image som var ren igår kan ha en ny sårbarhet idag, nya CVE:er publiceras hela tiden.

SBOM som ett krav, inte bara ett verktyg

Värt att notera är att SBOM håller på att gå från god praxis till uttryckligt krav. Allt fler kunder, särskilt större och offentliga, begär en innehållsförteckning över mjukvaran de köper, och regelverk kring säker utveckling pekar i samma riktning. Det betyder att förmågan ni bygger för er egen sårbarhetshantering dessutom blir en konkurrensfördel i upphandlingar och en pusselbit i compliance-arbetet, exempelvis kravet på säker systemutveckling under NIS2 artikel 21. Med andra ord: ni bygger inte bara säkerhet, ni bygger något ni snart ändå kommer att behöva kunna visa upp.

Det vanligaste misstaget

Det vanligaste misstaget är att sätta tröskeln på noll sårbarheter och bryta varje bygge. Resultatet blir larmtrötthet: teamet börjar kringgå skanningen, och då har den förlorat sitt syfte. Bättre att börja med att blockera på kritiska och allvarliga sårbarheter, etablera en rutin för åtgärd, och skärpa tröskeln över tid. En sårbarhet med hög allvarlighetsgrad i ett bibliotek som aldrig exponeras mot nätet är dessutom inte lika brådskande som en medelallvarlig i något internetvänt, kontext spelar roll, och en mogen process väger in det istället för att stirra blint på siffran. Det här hänger ihop med en fungerande incidentberedskap, som jag beskriver i incident response-planen.

Var jag brukar börja

Börja med en baslinjeskanning av det ni redan kör i produktion. Den ger en realistisk bild av nuläget och blir ofta argumentet som gör att teamet vill ha skanningen i pipelinen, det är konkret att se vad man faktiskt har. Därefter automatiserar vi steget för steg. Se hur jag lägger upp liknande uppdrag i kundcase.

Relaterat

• Cloudflare Zero Trust för SMB: Ersätt VPN på en eftermiddag
• NIS2 artikel 21 i praktiken: Checklista för svenska bolag
• DORA-förordningen för fintech: Vad CTO:n måste veta innan 2027

Vill du ta det vidare?

Jag bygger SBOM och automatiserad sårbarhetsskanning in i er pipeline, kontinuerligt och utan att bromsa teamet. Boka ett samtal så ser vi över ert flöde.