En SBOM (Software Bill of Materials) är en detaljerad lista över alla komponenter som används i programvara. Cybersäkerhets- och infrastruktursäkerhetsbyrån (CISA) har identifierat sex olika typer av SBOM:ar, som speglar programvaras beståndsdelar i olika skeden av utvecklingslivscykeln (SDLC).
De vanligaste SBOM-typerna är Source SBOM och Build SBOM, men beroende på behov och miljö kan andra SBOM-typer vara värdefulla.
| SBOM-typ | Beskrivning | Användningsområde |
|---|---|---|
| Design SBOM | Planerad arkitektur och avsedda komponenter. | Används i designfasen för att identifiera potentiella problem. |
| Source SBOM | Byggs från källkoden och identifierar komponenter och beroenden. | Möjliggör tidig identifiering av sårbarheter och kodanalys. |
| Build SBOM | Genereras under byggprocessen och inkluderar alla faktiska beroenden. | Ger en verifierad och exakt representation av mjukvaran. |
| Analyzed SBOM | Skapas genom analys av en färdig artefakt, såsom en binär fil. | Används när källkod eller byggmiljö saknas. |
| Deployed SBOM | Dokumenterar installerade programvarukomponenter i en driftmiljö. | Visar aktuell mjukvara i produktion och identifierar konfigurationsspecifika detaljer. |
| Runtime SBOM | Övervakar ett körande system och identifierar aktiva komponenter. | Möjliggör analys av dynamiskt laddade beroenden. |
Nedan följer en närmare beskrivning av varje SBOM-typ och dess användningsområden inkl för- och nackdelar.
Design SBOM
Denna SBOM beskriver den planerade arkitekturen och de komponenter som förväntas ingå i en produkt. Den baseras ofta på designspecifikationer eller offertförfrågningar (RFP) och används för att identifiera potentiella problem i ett tidigt skede.
Fördelar:
- Hjälper organisationer att planera sina projekt och identifiera eventuella kompatibilitetsproblem innan utvecklingen startar.
- Kan fungera som en riktlinje för vilka komponenter som är godkända att använda i utvecklingsprocessen.
Begränsningar:
- Innehåller endast teoretiska komponenter, vilket gör att faktiska beroenden som tillkommer senare kan saknas.
- Kan vara svår att generera på ett detaljerat sätt.
Source SBOM
Skapas direkt från källkoden genom att analysera koden för att identifiera komponenter och beroenden. Genereras oftast med ett SCA-verktyg (Software Composition Analysis).
Fördelar:
- Möjliggör tidig identifiering av sårbarheter och beroenden i kodbasen.
- Ger en tydlig bild av vilka komponenter som används i en viss mjukvara.
Begränsningar:
- Kan inkludera beroenden som aldrig används i slutprodukten.
- Saknar insyn i komponenter som tillkommer senare i byggprocessen.
Build SBOM
Genereras under byggprocessen och inkluderar alla beroenden som faktiskt används för att skapa den färdiga mjukvaran.
Fördelar:
- Ger en hög grad av noggrannhet eftersom den speglar den faktiska byggprocessen.
- Möjliggör signering av SBOM och produktartefakt, vilket ökar förtroendet.
Begränsningar:
- Kräver anpassningar i byggprocessen för att generera korrekt.
- Kan missa beroenden som laddas dynamiskt vid körning (se Runtime SBOM).
Analyzed SBOM
Skapas genom analys av en färdigbyggd artefakt, som en binär fil, ett paket eller en container. Denna typ används ofta när man saknar tillgång till källkod eller byggmiljö.
Fördelar:
- Gör det möjligt att analysera äldre system eller programvara från tredje part.
- Kräver ingen insyn i byggprocessen och kan validera andra SBOM:ars data.
Begränsningar:
- Kan innehålla approximationer eftersom analysverktyg inte alltid identifierar alla komponenter korrekt.
- Beroende av heuristiska metoder som kan medföra felaktigheter.
Deployed SBOM
Dokumenterar vilka programvarukomponenter som faktiskt är installerade på ett system och används i en produktionsmiljö.
Fördelar:
- Ger en tydlig bild av programvarukomponenterna i den faktiska driftsmiljön.
- Kan kombinera data från flera SBOM:er och identifiera konfigurationsspecifika detaljer.
Begränsningar:
- Kräver detaljerad information från driftmiljön, vilket kan vara svårt att samla in.
- Speglar endast den aktuella installationen och kan förändras över tid.
Runtime SBOM
Genereras genom att övervaka ett körande system och identifiera de komponenter och beroenden som verkligen används vid drift.
Fördelar:
- Identifierar exakt vilka moduler och externa anrop som används i realtid.
- Möjliggör analys av dynamiskt laddade komponenter och externa anslutningar.
Begränsningar:
- Kräver aktiv övervakning av systemet, vilket kan innebära prestandapåverkan.
- Kan missa komponenter som endast används vid specifika körscenarier.
Vilken typ av SBOM är bäst?
De mest använda SBOM-typerna är Source SBOM och Build SBOM, eftersom de ger en detaljerad och verifierbar bild av mjukvarans sammansättning.
För tredjepartsmjukvara eller äldre system kan en Analyzed SBOM vara den mest realistiska lösningen.
I en ideal värld används en kombination av flera SBOM:ar för att skapa en så komplett bild som möjligt av en programvaras komponenter och säkerhetsrisker.