Varför är SBOM-kvalitet viktigt?
Två SBOM:ar i samma format kan vara olika användbara
Att en SBOM följer CycloneDX eller SPDX säger bara att filen har rätt struktur. Det säger inte att uppgifterna i den är fullständiga. Två verktyg kan skapa helt olika SBOM:ar för samma projekt, och båda kan vara giltiga enligt formatet.
Kvaliteten avgör vad SBOM:en går att använda till. En sårbarhetsanalys kan bara hitta sårbarheter i komponenter som finns med och som går att identifiera.
Vanliga brister
| Brist | Följd |
|---|---|
| Version saknas | Det går inte att avgöra om en sårbarhet gäller komponenten |
| Unik identifierare (purl eller CPE) saknas | Komponenten kan inte matchas säkert mot sårbarhetsdatabaser |
| Bara direkta beroenden | Sårbarheter i transitiva beroenden syns inte |
| Relationer mellan komponenter saknas | Det går inte att se varför en komponent finns med eller vad som ska uppdateras |
| Leverantör saknas | Det är oklart vem som står bakom komponenten |
| Licens saknas eller är fritext | Licenskontroll kan inte göras automatiskt |
| Ett helt ekosystem saknas | Verktyget läste till exempel npm men inte Python i samma projekt |
Vad en SBOM ska mätas mot
- SBOM Minimum Elements. Lägstanivån från NTIA: leverantör, namn, version, unik identifierare, beroenderelationer, författare och tidsstämpel.
- BSI TR-03183-2. Den tyska riktlinjen för SBOM enligt CRA, som ställer mer detaljerade krav.
- Egna krav. Till exempel att licenser ska anges som giltiga SPDX-uttryck.
Kontrollera automatiskt
Kontrollen ska göras av ett verktyg, varje gång en SBOM skapas eller tas emot. Det gäller särskilt SBOM:ar från leverantörer. Att en leverantör "har en SBOM" säger inget om vad den innehåller.
Skriv in kvalitetskraven i avtalet och kontrollera varje leverans mot dem. SBOM i offentlig upphandling ger exempel på hur krav kan formuleras.