Software Bill of Material (SBOM) är en innehålls- och materialförteckning av hur en programvara eller ett IT-system är uppbyggt. Förteckningen kan ses som en inventeringslista eller recept för hur mjukvaran är konstruerad och vilka komponenter den består av för att fungera. SBOM är ett fil- och datautbytesformat för att automatisera och maskinellt granska hela leveranskedjan av komponenter och deras ursprung. En SBOM fil kan innehålla; licensvillkor, version, ursprung, tidsstämpel, kontrollsummor, beroende till andra mjukvarukomponenter och deras version, med mera. Detta möjliggör bland annat automatisering av efterlevnadskontroll av licenser, verifiering att komponenter inte manipulerats med skadlig kod av illvilliga aktörer eller innehåller gamla moduler med kända säkerhetshål. Dagens programvara blir alltmer komplex och öppen källkodskomponenter finns i nästan alla modern mjukvara; SBOM är ett informationsutbytesformat för att skydda digital infrastruktur mot sårbarheter.
SBOM startade som ett initiativ av Linux Foundation runt 2010-talet tillsammans med bland annat träning och utbildning och var del av ett program för att kvalitetssäkra och möjliggöra efterlevnadskontroll av licenshantering för öppen källkodskomponenter och programvara. Software Packages Data Exchange (SPDX) standarden lanserades 2011 och var en del av programmet för att maskinellt hantera och utbyta information om öppen källkodslicenser. Senare under 2010-talet inkluderades möjligheten att identifiera sårbarheter och spåra beroenden till externa mjukvarukomponenter i standarden. 2021 blev SPDX formatet en ISO/IEC standard (ISO/IEC 5962:2021). CycloneDX är en annan standard som lanserades 2017 av Open Web Application Security Project (OWASP) med syfte att spåra sårbarheter, licenser och beroenden till utdaterade komponenter. Båda standarderna har utvecklats fortlöpande och kan idag hantera mer komplexa programstrukturer för att identifiera sårbarheter och kvalitetssäkra leveranskedjor som nyttjar öppen källkodskomponenter och mjukvara.
2021 utfärdades ett presidentdekret (Biden-administrationen) om att all öppen mjukvara som levereras till amerikanska staten och offentlig sektor måste innehålla SBOM beskrivningar för att stärka cybersäkerhet, digitala leveranskedjor och utbyta information om sårbarheter. Syftet med dekretet är att skydda öppen källkod som ses som en betydelsefull nationell digital resurs för att främja innovation. Vita huset har tillsammans med stora mjukvaruleverantörer och techbolag (White House meeting readout 2022) enats om att stödja öppen källkods communityns arbete med efterlevnadskontroll eftersom det används av den nationella säkerhetstjänsten (NSA, CIA, etc.) och är central för amerikansk ekonomi. Amerikanska myndigheten Cybersecurity and Infrastructure Security Agency (CISA) arbetar med att stötta utvecklingen av SBOM standarder och finansiera öppen källkod communityn som driver utvecklingsarbetet. Exempelvis är Microsoft en av leverantörerna som bidrar till Linux Foundation’s SPDX projekt och genererar SPDX filer för mer än 5000 program som dagligen byggs och paketeras.
Nuläge
Under senaste decenniet har SBOM standarden blivit en allt viktigare byggsten i arbetet med att upprätthålla säkerheten för digital infrastruktur och mjukvarukomponenter som är avgörande för den digitala utvecklingen. Öppen källkod finns i nästan all modern mjukvara och kartläggningar visar att mellan 93 (Tidelift) och 96 (Synopsys) procent innehåller öppen källkodskomponenter och bibliotek. I takt med att cybersäkerhetshoten ökar behöver hela leveranskedjan för mjukvaruutveckling stärkas eftersom den inte är starkare än sin svagaste länk. Det räcker med ett säkerhetshål i en komponent för att en illvillig aktör skall kompromettera mjukvaran. SolarWind (känt som Sunburst) är en av 2000-talets största cyberattacker som genomfördes på grund av en svaghet i en komponent i leveranskedjan till ett systemstöd för nätverksövervakning; det tog över ett år innan säkerhetshålet identifierades. Attacken infekterade över 30,000 offentliga och privata organisationer, som exempelvis Microsoft, Intel, Cisco, Homeland Security, State Department med flera. Ett svenskt exempel är Coops kassasystem Visma EssCom, som bestod av en tredjepartskomponent från Kaseya för att fjärrstyra och uppdatera kassasystemet, vilket hade ett säkerhetshål som kunde utnyttjas för att genomföra en så kallad ”ransomware-attack”.
All mjukvara innehåller buggar och säkerhetshål. Däremot erbjuder öppen källkod i kontrast till proprietär mjukvara transparens om hur den är uppbyggd och möjligheten att genomlysa koden innan den används. Fallet med Coop visar på svårigheterna att få insikt i leveranskedjor av proprietära systemstöd och avtal med systemleverantör har liten betydelse när drabbade verksamheter oftast måste hantera konsekvenserna själva. För att sätta press på stora systemleverantörer driver Google projektet Project Zero som offentligt publicerar information om sårbarheter om leverantören inte uppdaterar och åtgärdar säkerhetshålet i mjukvaran efter 90 dagar.
SBOM tillsammans med andra verktyg som exempelvis digital signering, hashkoder, purl behövs för att trygga leveranskedjan och säkerställa integriteten av mjukvara så den inte innehåller komprometterade komponenter. DevOPS är en metodologi för att snabba upp leveranskedjan av mjukvara och bygger på principer att skapa transparens, delat ägarskap, automatiserade arbetsflöden och skapa återkoppling för processen av mjukvaruutveckling. SBOM harmoniserar väl med DevOps principerna och tillför transparens för livscykelhanteringen genom att skapa synlighet om beroende och säkerhetshål i underliggande komponenter som ingår i mjukvaran. SBOM standarder finns i olika format (SPDX, CycloneDX, SWID) som har olika ändamål och kan användas tillsammans för att komplettera varandra. SPDX initierades för efterlevnadskontroll av licensvillkor, men inkluderar idag även möjligheter för sårbarhetsanalyser genom att länka in information för identifiering av sårbarheter och buggfixar för att åtgärda säkerhetshålen (VEX, CPE, CVE, etc.). CycloneDX initierades för att identifiera sårbarheter och inaktuella mjukvarukomponenter, men innefattar idag även efterlevnadskontroll av licensvillkor. SWID är ett enklare format för identifiering och märkning av programvara och är inte en komplett SBOM standard. Det finns flera SBOM öppen källkodsprogram för att generera SBOM filer som inkluderar licensvillkor, beroenden till tredjepartskomponenter och sårbarheter.
De två dominerande standarderna SPDX och CycloneDX, har stöd för hantering av olika protokoll för att kommunicera och prenumerera på sårbarhetsrapporter i maskinläsbara format. En sådan är CVE (Common Vulnerabilities and Exposures) som listar och indexerar mer än 200 000 kända sårbarheter i JSON format. En annan är VEX (Vulnerability Exploitability eXchange) som är ett format för att kommunicera hur sårbarheter påverkar olika typer av IT-system och programvara. VEX använder sig av CVE för att beskriva hur specifika sårbarheter påverkar olika typer av mjukvara vilket gör det lättare för systemadministratörer att veta om och hur det påverkar deras IT-system. Både CVE och VEX drivs och finansieras inom ramen för olika amerikanska myndigheter som arbetar med cybersäkerhet tillsammans med öppen källkod communityn.
Svenskt perspektiv
I Sverige finns det ingen enskild myndighet som ansvarar för cybersäkerheten, utan det är Nationellt center för cybersäkerhet (NCSC) som koordinerar samarbetet mellan Försvarets radioanstalt, Försvarsmakten, Myndigheten för samhällsskydd och beredskap (MSB) samt Säkerhetspolisen som tillsammans ansvarar för uppgiften. MSB:s rapport från 2022 om digitala leveranskedjor med 50 rekommendationer för att stärka samhällsäkerheten, nämner inte SBOM som ett verktyg för att praktiskt jobba med förebyggande, identifiering och hantering av cyberhot. Rapporten nämner heller inte standarder som SPDX och CycloneDX, vilket är ett missat tillfälle att konkretisera säkerhetsarbetet kring digitala leveranskedjor.
Riksrevisionen rapport (RiR 2023:8) från 23 april 2023, kritiserar regeringens svaga styrning, bristande praxis, strategier och splittrade ansvar mellan myndigheter. En av rekommendationerna rapporten belyser är upprättande av riktlinjer för säkert informationsutbyte mellan myndigheter, offentlig och privat sektor. Riksrevisionens bedömning är att NSCS koordinerande roll inte har skapat de förmågor som behövs nationellt, samt att det inte finns någon holistiskt sammanhållen styrning för hur säkert informationsutbyte och skydd mot cybersäkerhetshot skall implementeras.
Sammanfattning
Öppen källkod fungerar som ett globalt allmängods som behöver skyddas eftersom det är centralt för innovation och digital infrastruktur som driver den digitala transformationen av samhället. Öppen källkods communityn arbetar aktivt och besitter kompetensen att säkra leveranskedjor av mjukvarukomponenter. Amerikanska staten stödjer idéburna organisationer som Linux Foundation och OWASP, som tillsammans med globala techbolag arbetar med att utveckla SBOM standarder. Myndigheter som CISA och NTIA samarbetar med communityn för att utarbeta livscykelprocesser och verktyg som amerikanska staten använder sig av för att skydda kritisk digital infrastruktur.
EU publicerade ett första utkast av Cyber Resilience Act (CRA) 2022 som kommer att påverka alla leverantörer att tillhandahålla SBOM för all mjukvara som säljs, nyttjas och används inom unionen. Bristen på konkreta strategier för implementering och tydlig styrning från svenskt perspektiv innebär, enligt Riksrevisionsverket, att nationella intressen inte kommer att reflekteras i utformningen av akten som berör cybersäkerhet, effektivt resursutnyttjande och informationsutbyte mellan myndigheter och stater. Sverige har gått längre än de flesta andra länder i att outsourca och lämnat över digitaliseringen av samhället till den privata marknaden, vilket har medfört till inlåsningseffekter som Konkurrensverket rapporterade om 2016. Rapporten tar upp bristen på nyttjande av öppna standarder i upphandlingar vilket skapat leverantörsberoenden och inlåsningseffekter som resulterar i stora kostnader för samhället och försvårar möjligheten att ta tillvara på digitaliseringens effekter. Inlåsningen och leverantörsberoenden hänger ihop med avsaknaden av förespråkande av öppen källkod i upphandlingar som skulle kunna främja interoperabilitet och informationsutbyte eftersom dessa uteslutande bygger på öppna standarder.
ISO/IEC standarden för SPDX erbjuder minimikrav och transparens för hur mjukvara konstrueras med tillhörande metadata kring licensvillkor, beroenden till mjukvarukomponenter/bibliotek och eventuella sårbarheter. Genom att ställa krav på att programvara och systemstöd uppfyller standarden i upphandlingar skapar det transparens även för proprietär mjukvara. Samt att det möjliggör att verksamheter kan utföra egna sårbarhetsanalyser och agera snabbare om en delkomponent innehåller en sårbarhet, istället för att invänta systemleverantörens respons. Hackerattacken SolarWind tog runt 14 månader att uppdagas, och då var det ett annat företag än leverantören som identifierade sårbarheter. Svenska myndigheter och offentlig sektor som hanterar känslig information behöver anskaffa kunskap och börja implementera sårbarhetsanalyser, efterlevnadskontroll av licenser och leveranskedjor samt börja kravställa SBOM för verksamhetskritiska systemstöd. Att invänta myndighetssamverkan och statlig styrning är inte ett alternativ då Sverige inte ens är delaktigt i Europeiska kommissionens arbete kring RCA, och där EU dessutom ligger steget efter USA. Det fina i kråksången är däremot att allt arbete som öppen källkods communityn utför på uppdrag av den amerikanska staten är tillgängligt som öppen källkod med undantag för vissa implementeringsspecifikationer (ISO/IEC) och analysprogram.