De behoefte aan SBOM — Deel 2
Interlynk
Het schrijven van software of softwarecomponenten vanaf het begin is zeldzaam in de moderne softwareontwikkeling. Bestaande bibliotheken en frameworks bieden de basis voor het ontwikkelen van nieuwe functies en functionaliteiten, en dit nieuwe product kan de basis worden voor een ander product.
Echter, deze laagstructuur van software en componenten kan blinde vlekken creëren voor de ontwikkelaar en consumenten. In Deel-1 hebben we besproken hoe lagen een uitdaging creëren bij het identificeren van zero-day kwetsbaarheden (wereldwijd ervaren met log4shell).
Andere risico's zijn verbonden aan software van onbekende samenstelling, waaronder:
het risico van het opnemen van componenten met een beperkende licentie
componenten die het einde van hun levenscyclus hebben bereikt, of
componenten die worden beïnvloed door statenacteurs.
De productie heeft met soortgelijke zorgen in supply chain en voorraadbeheer te maken gehad door het opstellen van een Bill of Materials (BOM), Obsolescentiebeheer, Productwijzigingsmeldingen (PCN), en beheer van het einde van de levenscyclus (EOL).
SBOM brengt die lessen en praktijken naar de softwareontwikkeling.
Software Bill of Materials (SBOM)
In wezen is SBOM een document dat de componenten van de software, hun leveranciers en de relaties tussen de componenten (lagen) beschrijft, samen met enige metadata om het geheel te begrijpen.
Conceptuele SBOM — Bron: Kader voor Transparantie van Softwarecomponenten
CISA raadt aan om SBOM te bouwen volgens bestaande specificaties:
Deze specificaties zijn zeer flexibel, en daarom heeft CISA ook aanbevolen minimale elementen voor een SBOM om ervoor te zorgen dat de gegenereerde SBOM kan worden gebruikt om de bovengenoemde risico's aan te pakken.
SBOM-gevalstudies
Een complete SBOM kan helpen bij het oplossen van de volgende problemen:
1. Componenten Inventaris Een complete SBOM omvat alle componenten, inclusief de geneste componenten, en kan daarom een componenteninventaris voor het product opbouwen.
2. Licentie Inventaris Een complete SBOM omvat alle licenties die aan elke component zijn gekoppeld en kan daarom worden gebruikt om een licentie-inventaris op te bouwen en te monitoren. Dit is een cruciaal onderdeel van het beheren van risico's die verband houden met open-source licenties.
3. Kwetsbaarheid Beheer Een goed beschreven component in een SBOM volgt veelgebruikte naamgevingsconventies voor componenten, zoals CPE, PURL of SWID-tag. Een exacte componentnaam kan worden gebruikt voor kwetsbaarheidzoekopdrachten uit databases zoals NVD en OSV. Omdat SBOM geneste relaties (en veel meer soorten relaties) ondersteunt, lost dit het probleem van kwetsbaarheidzoekopdrachten op, zoals beschreven in Deel-1.
4. Veroudering en Einde-van-Leven Beheer Naarmate het product veroudert, stelt het opbouwen van een componenteninventaris SBOM in staat om verouderde of EOL-componenten bij te houden.
5. Kwetsbaarheid Exploitabiliteit Openbaarmaking SBOM kan worden gecombineerd met VEX om de status van kwetsbaarheden die aan het product zijn verbonden te communiceren. Dit helpt om ruis te verminderen in gevallen waar software samenstellingsanalyse tools een product scannen. Een introductie tot kwetsbaarheid exploitabiliteit openbaarmaking is hier.
SBOM-uitdagingen
Het potentieel van SBOM is duidelijk voor organisaties die ze bouwen. Echter, verschillende gebruiksgevallen die hierboven zijn beschreven bevatten zinnen zoals: volledige SBOM, goed beschreven component en precisiecomponentnaam.
Het bouwen van een volledige SBOM of het gebruiken van een exacte naam voor een component is een echte uitdaging. Deze uitdagingen kunnen vroege gebruikers frustreren of ongegronde tegenstand tegen SBOM creëren.
In Deel 3 – Hoe SBOM-uitdagingen kansen zijn en geen risico's.