Vad är en S-BOM och varför behövs den

Om du öppnar en läskflaska och tittar på baksidan, hittar du en ingredienslista. Det visar exakt vad som finns i flaskan. Nu tänk dig att din kod är en läskflaska. En S-BOM är ingredienslistan för mjukvara.

Plötsligt dyker ordet upp överallt. I säkerhetsmöten. I inköpsavtal. I nya lagar. Och du kanske tänker: "Varför är detta min problem?" (Spoiler: det är ofta inte så svårt som det låter.) Det är här vi löser det tillsammans.

Vad är en S-BOM egentligen?

S-BOM står för Software Bill of Materials. Det är en detaljerad lista över alla komponenter som bygger upp en programvara. Alla bibliotek. Alla ramverk. Alla små koddelar från andra utvecklare som du använder.

Tänk på en bil. Den består av en motor, fyra hjul, ett stereoystem, och tusen andra delar. En S-BOM är samma sak fast för kod.

Vad hittar du i en S-BOM?

• Namn på varje komponent och vilken version du använder
• Vem som skrev komponenten
• Vilken licens komponenten har
• Andra komponenter som den är beroende av
• Om den innehåller kända säkerhetshål

Varför behöver du detta? Föreställ dig att du håller på med uppdateringar, och någon säger: "Vi hittade ett säkerhetshål i biblioteket du använder." Utan S-BOM måste du manuellt gräva genom all din kod för att hitta det. Med S-BOM får du svaret på några sekunder.

Varför började alla plötsligt prata om S-BOM?

För några år sedan brydde sig nästan ingen om S-BOM. Det var ett nischat begrepp. Men sedan ändrades allt.

År 2021 skrev USA:s president en order. Han sa att mjukvara måste bli säkrare. En del av det var att kräva S-BOM från alla som säljer mjukvara till regeringen. Och när USA bestämmer något stort, följer resten av världen efter.

Sedan kom nya regler. I Europa. DORA kräver att banker kan visa vad deras mjukvara innehåller. NIS2 säger att kritiska industrier måste ha bättre kontroll. CRA, en ny regel om cybersäkerhet, kräver att utvecklare kan visa vad som finns i koderna.

Sverige hänger med lite. Vi har Nationellt center för cybersäkerhet som jobbar på detta. Men vi saknar en tydlig nationell linje. Det gör att svenska företag ofta följer internationella krav istället.

Varför är det här praktiskt viktigt för dig? Eftersom nya jobb kräver det. Nya inköpsavtal kräver det. Och dina kunder kommer börja fråga efter det.

S-BOM i praktiken så använder du det

Det är dags för verktygen. Hur skapar du en S-BOM? Och hur bygger du in det i ditt arbete?

Först: välj ett format. SPDX och CycloneDX är de två stora. SPDX är äldre och väletablerat. CycloneDX är nyare och fokuserar på säkerhet. Båda fungerar. Båda är gratis.

Vilka verktyg kan hjälpa dig?

• CycloneDX har egen dokumentation och plugin för olika språk
• Syft skapar S-BOM automatiskt från din kod
• Trivy söker efter säkerhetshål i komponenter
• SPDX-licenslistan hjälper dig klassificera licenser rätt

Nästa steg: automatisering. Manuell arbete fungerar inte. Du glömmer delar. Du uppdaterar inte ofta nog. Därför behöver du lägga in S-BOM-generering i din CI/CD-pipeline. Det är de automatiserade process som körs varje gång du pushar kod.

Så här kan det se ut:

1. Du pushar kod till ditt system
2. Ett verktyg skannar automatiskt alla komponenter
3. S-BOM skapas automatiskt
4. Systemet söker efter kända säkerhetshål
5. Rapporten dyker upp för dig

Det tar sekunder. Inte timmar.

Automation är inte bara snabbare det är också säkrare. En människa gör misstag. En automerad process gör det samma sätt varje gång.

Licenser, sårbarheter och regelefterlevnad

En S-BOM löser tre stora problem. Låt oss gå genom dem.

Problem ett: Licenskaos. Du använder ett bibliotek från GitHub. Det är gratis. Men vilken licens har det? GPL? MIT? Apache? Några licenser säger att du måste göra din kod öppen om du använder dem. Andra säger att du måste nämna upphovsmannen. Utan S-BOM är detta en huvudvärkande manuell process. Med S-BOM ser du direkt om något kan orsaka juridiska problem.

Problem två: Säkerhetshål. Varje dag hittar säkerhetsforskare nya sårbarheter. De registreras i CVE-databasen en enorm lista över kända problem. Om din kod använder ett bibliotek med ett känt hål, behöver du veta det omedelbar. En S-BOM kan kopplas till CVE-databasen. Systemet söker automatiskt efter matchningar. "Du använder version 2.1 av det här biblioteket, och det innehåller hål nummer CVE-2024-12345. Uppdatera."

Problem tre: Regelkrav. Nya regler säger att du måste kunna visa vad din mjukvara innehåller. Inte bara för säkerhet utan för att bevisa att du arbetar ansvarsfullt. En S-BOM är det du visar.

Utan S-BOM? Du gissar. Du hoppas att ingen hål finns. Du hoppas att licenserna passar. Du hoppas på mycket.

Med S-BOM? Du vet.

Vanliga frågor när du börjar med S-BOM

Måste jag göra detta? I Sverige finns ingen lag som säger det. Men om du säljer mjukvara till regering, banker eller större företag ja. Om du jobbar med öppen källkod - ja. Om du vill ha ett modernt jobb då ja.

Hur ofta uppdaterar jag min S-BOM? Varje gång du släpper en ny version. Om du uppdaterar ett bibliotek uppdatera din S-BOM. Den ska alltid spegla vad som finns i koden nu.

Kan det garantera säkerhet? Nej. S-BOM är ett verktyg. Det hittar kända problem. Men det skyddar dig inte från noll-dagars-hål som ingen känner till ännu. Det är en del av ett större säkerhetspussel.

Vad är skillnaden från en vanlig BOM? En klassisk BOM är en lista över fysiska delar såsom en bil eller en möbel. En S-BOM är specifikt för kod. Den fokuserar på mjukvaru-komponenter, versioner, licenser och beroenden.

Kostar det pengar? De verktyg jag nämnde är gratis eller väldigt billiga. Men tiden för att implementera kostar. En utvecklare eller två behöver lägga några veckor på detta. Det är en engångskostnad som sparar dig många gånger över.

Vad gör du nu?

Du behöver inte vänta på en lag. Du kan börja nästa vecka.

Här är din plan:

1. Nästa måndag: Välj ett verktyg. Börja med Syft eller CycloneDX. Det tar 30 minuter att installera.
2. Vecka två: Kör det på ett av dina projekt. Se vad det hittar. Du blir förvånad över hur många komponenter som faktiskt finns där.
3. Vecka tre: Börja integrera det i din pipeline. Fråga ditt team vilka verktyg använder ni redan?

Sedan upprepar du processen för nästa projekt. Och nästa.

S-BOM är inte framtiden längre. Det är nutiden. Och det är mycket enklare att börja nu än att gissa senare varför din kod inte passar ett nytt inköpskrav.

Ditt nästa steg: öppna ditt projekt och fråga dig själv vad innehåller min kod egentligen?