En sbom – software bill of materials, på svenska mjukvaruförteckning – är ett formaliserat och strukturerat dokument som inte bara räknar upp allt som ingår i en mjukvaruprodukt, utan också beskriver leveranskedjan för varje komponent. Förteckningen beskriver vilka paket och bibliotek som finns med i din applikation samt förhållandet mellan dessa paket och biblioteket och andra projekt uppströms. Det är särskilt viktigt när det gäller återanvänd kod och öppen källkod.

Du känner kanske till materialföreckningen för bilar. Det är ett dokument som ingående räknar upp alla komponenter som gör att din nya bil kan gå. Bilindustrins leveranskedja är synnerligen invecklad. Även om din bil har monterats av Volvo eller Kia, så har många av dess beståndsdelar tillverkats av underleverantörer från hela världen. Materialförteckningen visar dig varifrån var och en av dessa delar kommer, och det är inte bara värdelöst vetande. Om till exempel en viss serie av krockkuddar har återkallats av tillverkaren behöver biltillverkarna snabbt kunna ta reda på vilka bilar just dessa krockkuddar sitter i.

Att skriva mjukvara är förstås inte riktigt samma sak som att montera en bil. Men eftersom vi allt oftare använder bibliotek i öppen källkod för att bygga containeriserade och distribuerade applikationer har de två verksamheterna fått mer gemensamt än man kanske tror. Det är därför som mjukvaruförteckningar har blivit allt vanligare.

Både utvecklare och användare kan använda en sbom för att ta reda på exakt vad som ingår i den mjukvara som de sprider och använder. Det har några intressanta följdverkningar, särskilt för it-säkerheten.

Varför behöver du en mjukvaruförteckning?

De monolitiska, slutna kodbaserna för mjukvara hör till det förflutna. Moderna applikationer är ofta byggda på massor av återanvänd kod och använder ofta bibliotek i öppen källkod. Och applikationerna delas ofta upp i mindre, självständigt användbara funktionella komponenter som kallas för containrar. De hanteras av plattformar för så kallad orkestrering av containrar, till exempel Kubernetes, och körs lokalt eller i molnet.

På det hela taget har denna utveckling varit gynnsam för mjukvaruutvecklingen. Den har helt klart höjt utvecklarnas produktivitet och sänkt kostnaderna. Men på många sätt har den blivit en mardröm för it-säkerheten. Genom att utvecklarna har gjort sig beroende av kod från tredje part, utan att de kanske så noga vet hur den är upplagd, har de skapat en leveranskedja av mjukvarukomponenter som är precis lika komplex som de som finns i tillverkningsindustrin. Och eftersom en applikation inte kan vara säkrare än dess minst säkra komponent får mjukvara som har satts samman på detta sätt unika sårbarheter som branschen nu måste brottas med.

2020-talet har präglats av en rad attacker mot leveranskedjor, vilket ingen som läser branschpressen kan ha missat. I slutet av 2020 lyckades hackare med koppling till det ryska underrättelseväsendet smussla in bakdörrar i en nätverksövervakningsplattform från Solarwinds. Den plattformen används i många andra säkerhetsprodukter, och alla drabbades. Och i slutet av 2021 upptäcktes en allvarlig sårbarhet i ett Javabibliotek som ingår i Apache Log4j. Det används för loggning av systemhändelser. Det kan låta tråkigt ända tills man betänker att nästan alla existerande Javaapplikationer använder Log4j i någon utsträckning – vilket gör alla till måltavlor.

Sådana kriser belyser den roll som mjukvaruförteckningar kan spela i säkerhetsvärlden. Många användare kan ha hört talas om dessa sårbarheter, men de kan ha varit lyckligt ovetande om att de själva kör Log4j eller en komponent från Solarwinds. Men med en korrekt sbom skulle de veta exakt vilka paket som de körde – och, vilket är viktigare, vilken version av dessa paket. Om du vet det så kan du uppdatera till en säker version.

Mjukvaruförteckningar är inte bara till för it-säkerheten. De kan också hjälpa utvecklare att hålla reda på mjukvarulicenserna för den öppna källkod som ingår i deras mjukvara. Det är viktigt när man ska sprida en applikation.

Presidenten kräver mjukvaruförteckningar

I synnerhet attacken mot Solarwinds skrämde upp USA:s federala statsförvaltning. Många federala organ använde den komprometterade komponenten. Det var därför som ett direktiv direkt från USA:s president i maj 2022 innehöll krav på mjukvaruförteckningar. Handelsdepartementet fick i uppdrag att publicera minimikraven på en sbom. Detta ska sedan bli ett krav som ställs på alla som säljer mjukvara till amerikanska staten.

Visserligen gäller detta direktiv enbart företag som säljer direkt till amerikanska staten. Men staten har långa tentakler, och många företag är angelägna att få federala jobb. Och de produkter som säljs till staten, och som behöver ha en mjukvaruförteckning som listar alla komponenter, säljs också till andra företag och organisationer. Många mjukvarutillverkare hoppas, även om initiativet kommer från staten, att kunder i den privata sektorn också ska se mjukvaruförteckningar som ett mervärde.

Till det kommer att federala uppdrag i sig är en leveranskedja:

– Det finns bara ett visst antal företag som gör affärer direkt med de federala myndigheterna, och de kommer naturligtvis att påverkas direkt, säger Sounil Yu. Han var tidigare förste it-säkerhetsforskare på Bank of America. Nu är har it-säkerhetsdirektör och forskningsledare på JupiterOne:

– Men den sekundära effekten, alltså de företag som säljer till företag som i sin tur säljer till staten, blir mycket större.

Vad bör ingå i en mjukvaruförteckning?

Men anledning av presidentens direktiv publicerade USA:s federala myndighet för telekommunikationer och information (NTIA) ”The minimum elements for a software bill of materials”. Den anger vad som en sbom måste omfatta för att uppfylla amerikanska statens krav. Återigen: med tanke på vilken betydelse federala uppdrag har i it-branschen kan man räkna med att det dokumentet blir en de facto-standard för mjukvaruförteckningar. NTIA räknar upp sju punkter som bör ingå i alla mjukvaruförteckningar.

  • Leverantörens namn: Namnet på den organisation som skapar, definierar och identifierar den aktuella komponenten.
  • Komponentens namn: Den beteckning som har tilldelats den aktuella mjukvaran av den ursprungliga leverantören.
  • Komponentens version: Ett kännetecken som leverantören använder för att ange en förändring av mjukvaran jämfört med en tidigare identifierad version..
  • Andra unika kännetecken: Andra kännetecken som används för att identifiera en komponent, eller för att användas för uppslagning i lämpliga databaser. Det kan till exempel vara ett kännetecken från NIST:s CPE Dictionary.
  • Beroendeförhållanden: Beskrivning av förhållanden som att en uppströmskomponent X ingår i applikationen Y. Detta är särskilt viktigt för projekt som använder öppen källkod.
  • Upphov till respektive uppgift: Namn på den organisation som har sammanställt sbom-data för varje enskild komponent.
  • Tidsuppgift: Datum och klockslag då förteckningen sammanställdes.

Mjukvaruförteckningar måste också uppfylla dessa krav:

  • En sbom måste finnas i något av tre standardformat: SPDX, CycloneDX eller SWID tags— så att den är maskinläsbar.
  • En ny sbom måste sammanställas för varje ny version av mjukvaran så att man säkert vet att den är aktuell.
  • Förutom att den ska redovisa ingående beroenden mellan komponenter måste en sbom också redovisa var det troligen finns sådana beroenden, även om de är okända för den organisation som sammanställer mjukvaruförteckningen.

Hur man sammanställer en mjukvaruförteckning

När du läser detta finner du kanske att sammanställning av en mjukvaruförteckning låter ganska avskräckande. Att luska ut alla dessa beroenden för hand måste väl vara rena mardrömmen. Men som tur är är det inget som du förväntas göra själv. I de flesta fall sammanställs mjukvaruförteckningar automatiskt av verktyg för automatisk analys av mjukvarustacken (software component analysis, SCA). SCA-verktyg används ofta i Devsecops-pajpar och används för mer än att göra mjukvaruförteckningar

SCA-verktyg söker igenom dina kodkataloger efter paket och jämför dem med databaser på nätet så att de kan kollas mot kända bibliotek. Och det finns alternativ även till detta. Det finns till exempel verktyg som helt enkelt sammanställer en mjukvaruförteckning som del av mjukvarubyggprocessen.

Owasp Foundation, den vördnadsvärda säkerhetsorganisation som utvecklade standarden CycloneDX, har satt samman en tämligen omfattande lista med SCA-verktyg. Listan är belysande, för den går hela sträckan från nakna verktyg som styrs av kommandoraden till flashiga kommersiella produkter. Om du vill titta närmare på detta slags produkter finns CSO:s ”7 top software supply chain security tools” som är inriktat på verktyg för sammanställning av mjukvaruförteckningar och som innehåller en rätt djupgående diskussion av våra rekommendationer.

Om du utvecklar och sprider mjukvara blir det mer och mer nödvändigt att du införlivar mjukvaruförteckningar i utvecklingsarbetet. Du kanske inte jobbar åt USA:s federala myndigheter, men du måste ändå tänka på risken för attacker i leveranskedjan. Och mjukvaruförteckningar ger insyn i den svarta låda som återanvänd kod från tredje part kan vara.