Under de senaste åren har cybersäkerhet blivit allt viktigare, inte minst när man ser till att skydda hela mjukvaruförsörjningskedjan. I juli 2021 presenterade USA:s National Telecommunications and Information Administration (NTIA) ett antal minimikrav för en Software Bill of Materials (SBOM).

Dessa krav, som härstammar från en exekutiv order (EO 14028), ska göra det möjligt för företag som säljer till myndigheter att visa exakt vilka mjukvarukomponenter som ingår i deras produkter.

Som en del i detta arbete har man även tagit fram en detaljerad uppsättning minimikrav för SBOM, vilket kallas för SBOM Minimum Elements.

Genom att tydligt specificera vilka datafält, format och processer som behövs, skapas en bättre förutsättning för att snabbt kunna identifiera och hantera sårbarheter.

Syftet med SBOM Minimum Elements

Idén med minimikraven för SBOM är att ge alla inblandade – oavsett om man är myndighet eller företag – en klar och lättförståelig översikt över mjukvarans sammansättning. Med en komplett lista över komponenterna kan man:

• Stödja automatisering: Genom att använda standardiserade datafält och processer kan SBOM:ar genereras och distribueras automatiskt – vilket sparar tid och förenklar integrationen med andra säkerhetsverktyg.
• Öka insynen: En fullständig översikt gör det enklare att se vilka delar som ingår och vilka risker som kan finnas kopplade till licenser och säkerhet.
• Underlätta sårbarhetshantering: När man vet exakt vilka komponenter som används blir det lättare att snabbt spåra upp och åtgärda eventuella säkerhetsbrister.

Denna metod bidrar inte bara till ökad transparens utan gör det även lättare för alla parter att agera snabbt vid säkerhetsincidenter.

Fält som ingår i miminikraven

För att en SBOM ska vara riktigt användbar måste den innehålla vissa centrala datafält. Enligt riktlinjerna bör följande uppgifter finnas med:

• Supplier Name: Namnet på den part som levererar mjukvarukomponenten.
• Component Name: Namnet på själva mjukvarukomponenten.
• Version: Specificering av vilken version eller revision som gäller.
• Unique Identifiers: Identifierare, exempelvis Package URLs (PURL) eller Common Platform Enumeration (CPE), som hjälper till att spåra komponenten.
• Dependency Relationship: Information om hur komponenterna är beroende av varandra, både direkt och indirekt.
• SBOM Data Author: Den part som har sammanställt informationen.
• Timestamp: Datum och tidpunkt då SBOM:en skapades.

Automatisering och format

För att SBOM-informationen ska vara praktisk i vardagen är det viktigt att den både är maskin- och människoläsbar. Därför används standardiserade format vid genereringen. De vanligaste formaten är:

• CycloneDX: Ett flexibelt format som kan uttryckas i flera olika filtyper, såsom XML och JSON.
• SPDX: Ett väletablerat format som fångar upp viktiga uppgifter om ursprung, licenser och säkerhet.

Att använda dessa format gör det enklare att integrera SBOM:ar med olika säkerhets- och analysverktyg, vilket i sin tur underlättar hanteringen av hela den digitala leveranskedjan.

Metoder och processer vid generering av SBOM

Det räcker inte med att bara ha en komplett lista – det är också viktigt att tänka på hur SBOM:en skapas och delas. Här är några praktiska punkter att tänka på:

• Uppdateringsfrekvens: Varje gång en ny version av mjukvaran släpps, eller om viktiga ändringar sker, bör SBOM:en uppdateras och lagras.
• Fullständighet: Det är avgörande att dokumentera både huvudkomponenterna och alla beroenden som kan påverka systemets säkerhet. Om hela kedjan inte kan specificeras, bör det tydligt anges vilka delar som saknas.
• Distribution och åtkomst: SBOM:en bör göras tillgänglig på ett snabbt och säkert sätt, med klara riktlinjer för vem som har rätt att ta del av informationen.

SBOM Minimum Elements bidrar inte bara till ökad insyn och transparens, utan även till en säkrare och mer effektiv hantering av dagens digitala miljö med hjälp av automation.