Varför behöver vi SBOM?
Det mesta i en applikation är kod som någon annan har skrivit
De flesta applikationer byggs i dag till stor del av komponenter från tredje part, ofta öppen källkod. Det sparar tid, men det innebär också att en sårbarhet eller en olämplig licens i en enda komponent följer med in i produkten.
Log4Shell
Log4j är ett loggningsbibliotek för Java som används i ett mycket stort antal applikationer. I december 2021 upptäcktes sårbarheten Log4Shell, som gjorde det möjligt för en angripare att köra egen kod på system som använde biblioteket.
Det som tog tid för de flesta organisationer var inte att uppdatera biblioteket, utan att ta reda på var det fanns. Log4j följde ofta med som ett beroende till andra bibliotek, och i inköpta produkter syntes det inte alls utifrån. Den som hade en SBOM för sina system kunde söka efter komponenten och få svar direkt.
Fler exempel
- Heartbleed (2014). En sårbarhet i krypteringsbiblioteket OpenSSL som gjorde att känslig information kunde läcka från servrar.
- Apache Struts (2017). En sårbarhet i webbramverket Struts utnyttjades i intrånget hos kreditupplysningsföretaget Equifax, där uppgifter om över hundra miljoner personer exponerades.
- Spring4Shell (2022). En sårbarhet i Spring Framework som gjorde det möjligt att köra kod på servrar.
Gemensamt för exemplen är att sårbarheten fanns i en komponent som många använde utan att ha den förtecknad någonstans.
Vad en SBOM ändrar
Med en SBOM för varje version av varje produkt går frågan "är vi drabbade?" att besvara genom en sökning. Det gäller både mjukvara man bygger själv och mjukvara man köper, förutsatt att leverantören lämnar en SBOM.
Samma förteckning används för att kontrollera licenser och för att uppfylla krav i regelverk som Cyber Resilience Act (CRA).