SBOM och sårbarhetshantering
Från en lista över komponenter till en lista över vad som ska åtgärdas
När en allvarlig sårbarhet blir känd i ett bibliotek som många använder, som Log4j i december 2021, är den första frågan vilka av de egna systemen som innehåller det. Med en SBOM för varje system är det en sökning. Utan SBOM är det en inventering som görs under tidspress.
Arbetsflödet
1. Samla SBOM:erna
Spara en SBOM för varje version av varje produkt som används eller har levererats. Det gäller både egenutvecklad mjukvara och mjukvara från leverantörer.
2. Matcha mot sårbarhetsdata
Komponenterna i SBOM:en jämförs mot databaser över kända sårbarheter:
- NVD, den amerikanska nationella sårbarhetsdatabasen
- EUVD, EU:s sårbarhetsdatabas som drivs av Enisa
- OSV och GitHub Advisory Database, som täcker ekosystem med öppen källkod
Matchningen bygger på att komponenterna har korrekta versioner och unika identifierare. Varför är SBOM-kvalitet viktigt? beskriver vad som händer annars.
3. Prioritera
En matchning ger ofta fler träffar än vad som går att åtgärda på en gång. Tre mått används för att prioritera:
| Mått | Vad det säger |
|---|---|
| CVSS | Hur allvarlig sårbarheten är om den utnyttjas, på en skala från 0 till 10 |
| EPSS | Sannolikheten att sårbarheten utnyttjas inom 30 dagar |
| KEV | Om sårbarheten finns på en lista över sårbarheter som bevisligen utnyttjas |
En sårbarhet med medelhögt CVSS-värde som finns på en KEV-lista är oftast mer brådskande än en kritisk som ingen utnyttjar. Vad är en sårbarhet? beskriver måtten närmare.
4. Sortera bort det som inte påverkar
Alla sårbarheter i en komponent går inte att utnyttja i produkten. Leverantörens bedömning lämnas som VEX, och sårbarheter med status Not Affected kan läggas åt sidan.
5. Åtgärda och följ upp
Uppdatera komponenten, eller inför ett annat skydd om en uppdatering inte finns. En ny version av produkten får en ny SBOM, och den gamla sparas så länge den gamla versionen används.
Löpande bevakning
SBOM:en för en version ändras inte, men sårbarhetsdatabaserna gör det varje dag. Matchningen behöver därför göras fortlöpande, mot alla versioner som fortfarande används.
För tillverkare är detta också ett lagkrav. Cyber Resilience Act (CRA) kräver att aktivt utnyttjade sårbarheter anmäls inom 24 timmar.