Det intressanta med SBOM är hur snabbt teori möter drift: en kontroll måste fungera även när systemet uppdateras, felsöks och utsätts för fel. En SBOM gör mjukvarans innehåll sökbart när en ny sårbarhet publiceras och minskar tiden från frågan ”använder vi detta?” till ett verifierbart svar.
SBOM i praktiken
Första byggstenen: SBOM bör beskriva både direkta och transitive komponenter när verktyget kan se dem. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Format som SPDX eller CycloneDX gör data maskinläsbar. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Komponentversion utan koppling till release ger begränsat värde. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: SBOM är inventering och behöver kompletteras med riskbedömning. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Så skulle jag testa det i en riktig miljö
- Generera SBOM i samma pipeline som artefakten.
- Koppla filen till build-id och releaseversion.
- Lagra SBOM tillsammans med releasen.
- Sök historiska releaser när en ny dependency-sårbarhet kommer.
- Verifiera slumpmässigt att deklarerade komponenter faktiskt motsvarar byggresultatet.
För SBOM håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Praktiskt exempel
När en allvarlig bibliotekssårbarhet dyker upp vill jag kunna söka flera releaser direkt. Utan SBOM blir svaret ofta en manuell jakt genom gamla lock-filer, images och byggloggar.
Misstag som skapar falsk trygghet
- Att generera SBOM en gång och aldrig uppdatera den.
- Att bara lista toppnivåpaket.
- Att behandla förekomst av en CVE som bevis på exploaterbarhet.
Verifiering före stängning
För SBOM vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Varje release har en entydig SBOM.
- Komponent kan spåras till exakt release.
- Historisk fråga kan besvaras utan att bygga om gammal kod.
Ett negativt test hör också till SBOM: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
SBOM – veta vilka komponenter som faktiskt finns i en levererad applikation handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.