SBOM, Software Bill of Materials, är ett standardiserat sätt att beskriva exakt vad som är installerat för att en mjukvara ska fungera. Allt ifrån de applikationer som finns på den dator som kör programvaran, till programvaran i sig och de olika externa paket, bibliotek etc. de använder sig av.
Du kan jämföra det med ingredienser till ett recept. För en sockerkaka behöver du kanske ägg, smör, mjölk, socker, vetemjöl och bakpulver. De ingredienserna är sockerkakans SBOM. Sockerkaksformen har sin, mer komplexa, SBOM.
En SBOM kan vara i XML eller JSON-format, och en ganska enkel datapost i en sådan ser ut ungefär ut så här:
{
"name" : "tough-cookie",
"version" : "2.5.0",
"licenses" : [
{
"license" : {
"name" : "BSD-3-Clause"
}
}
],
"purl" : "pkg:npm/tough-cookie@2.5.0",
"type" : "library",
"bom-ref" : "45ac720d-c0df-46b6-a021-56c1f270e4ab"
},
Detta beskriver npm-biblioteket tough-cookie och att det är installerat i version 2.5.0 (som råkar ha två kända sårbarheter – så tuff var kanske inte den där kakan ändå). Som du kanske ser av exemplet ovan också, så finns även vilken licens som biblioteket har. Minst lika viktigt som säkerheten. Tänk dig att din leverantör gör sig beroende av bibliotek som de egentligen inte får använda i det sammanhang som de gör – då kan den som skrivit koden till biblioteket, dra tillbaka licensen. Och tänk dig att just det biblioteket var ansvarig för hela säkerheten i applikationen, och de som sålt programvaran till dig får skriva om den och antagligen använda andra bibliotek. Dyrt och onödigt. Så det är förståeligt att licens i den här kontexten är mycket viktigt.
En SBOM skapar en grundtrygghet för någon som vill upphandla vilken mjukvara som helst, om det så är en webbplats eller en programvara för att larma av och på kommunkontoret. Om mjukvaran från början har beroenden av bibliotek som är sårbara eller har fel licenser, är något allvarligt fel i det som upphandlats.
Om någon säger att på grund av säkerheten kan man inte dela med sig av en SBOM, då ska man dra öronen åt sig. För då är applikationen med största säkerhet skriven efter en dålig praxis. Säkerhet är inte att dölja sina beroenden, säkerhet är att visa dem.
Ett exempel där SBOM skulle ha gjort stor nytta:
För ett par år sedan exponerades ett stort antal applikationer och system för att de använde sig av Log4j. Många visste inte om de hade Log4j eller inte i sina system. Helt enkelt för att det är en komponent man använder tillsammans med den applikation som man kör egentligen – den för journal över vad huvud-applikationen gör – ofarligt kan man tycka. Men oj, oj, oj vad fel det var. Faktum är att det fortfarande finns applikationer där ute som kör sårbara versioner av Log4j – så många som 2 av 5 applikationer har kvar sårbarhetsproblem ännu i dag enligt forskare från säkerhetsföretaget Veracode (https://www.cybersecuritydive.com/news/log4j-haunts-security-community/702011/).
Om leverantören av dessa applikationer haft en SBOM av applikationen och de beroende systemen, så hade de varit medvetna och förhoppningsvis haft en process för att agera (jag vet att det finns företag och organisationer där ute som är fullt medvetna om att de har problemet, men inte gör något åt det, men det är en annan bloggpost).
En SBOM berättar vad en applikation behöver för att fungera, vilka bibliotek och program och i vilka versioner den använder. Leverantörer som inte kan, eller inte vill dela med sig av en SBOM till en IT-upphandling, utsätter sina kunder för fara från dag ett. Deras kunder får då lita i blindo, och kan inte veta något om till exempel externa krav, licenser och versioner. När så en stor säkerhetsbrist annonseras i någon komponent eller bibliotek, vet man inte om man som beställare behöver agera på en gång och stänga ned allt, för annars kanske systemet nästa dag blivit övertagen av en haxxor457#.
Jag säger inte att den som gör en IT-upphandling behöver kunna förstå själv vad som finns i en SBOM, men det finns det ett flertal verktyg som kan göra åt en, eller man kan anlita ett externt företag för att hjälpa till med processen (en liten investering som kan spara mycket pengar). Det borde dock vara leverantörens uppgift att förklara varför den kör en opatchad version av Log4j från 2016 och vad de ska göra åt det utan att man som beställare behöver fråga om det.
En mjukvara, som en webbsida, inbäddad applikation eller app, måste vara levande och tas om hand och uppdateras, som man vårdar och vattnar en växt. En död mjukvara blir med största säkerhet för eller senare hackad.
Alla IT-leverantörer borde lämna ifrån sig av en SBOM för sin applikation inför en upphandling, det borde till och med vara ett krav, och vid varje lansering av en ny uppdatering ska kunden få en ny SBOM om beroenden förändrats. Om uppdraget är att bygga en applikation från grunden, borde kravet vara att man löpande ger kunden tillgång till SBOM-datan. Om man bygger in ett beroende kring en känd säkerhetsbrist i utvecklingen, finns det en möjlighet att göra något åt det innan det lanseras. Med detta får man en viktig komponent i applikationens livscykel.
Vi kräver innehållsförteckning för sockerkakan som säljs i affären, det borde vara självklart att även kräva det för applikationer.
Man vill inte stå dagen efter en lansering med ”haxxor457# was here” som det enda synliga resultatet av en miljoninvestering. Säkerhet och öppenhet måste finnas med i hela processen, om en leverantör inte klarar av det, då borde den inte varit med från början.
