SBOM: componentinformatie, formaten en onderhoud
Sytance · Bijgewerkt
Een software bill of materials (SBOM) beschrijft de softwarecomponenten waaruit een toepassing of systeem bestaat en de relaties ertussen. De SBOM biedt een startpunt voor een componentenoverzicht, licentiecontrole en onderzoek naar kwetsbaarheden. De waarde ervan hangt af van hoe nauwkeurig deze de daadwerkelijk geleverde software beschrijft.
Het product dat door een SBOM wordt beschreven
Een SBOM beschrijft een specifieke productversie, build of artefact, zoals een firmware-image of installatiepakket. Componentvermeldingen identificeren de bibliotheken en andere software binnen die scope. Versies, producenten, identificaties en relaties helpen duidelijk maken wat is opgenomen.
Bij een fictieve industriële gateway is de firmwareversie het doelproduct. De beheerapplicatie en ingebedde bibliotheken zijn componenten. Een externe telemetriedienst is een externe afhankelijkheid; beschrijving ervan betekent niet dat de serverpakketten in de firmware zijn opgenomen.
Het openbare voorbeeld gebruikt verzonnen componenten om de structuur leesbaar te maken. Het is geen componenteninventaris van Sytance of een geleverde gateway.
Componentidentificaties
Twee pakketten met vergelijkbare namen kunnen bij verschillende pakketecosystemen horen. Een Package URL (purl) identificeert een pakket met velden zoals type, namespace, naam en versie. Een bestandshash helpt een exact bestand te identificeren als het hashalgoritme en het bestand waarop de hash is berekend bekend zijn.
Gebruik pakketmetadata of leveranciersinformatie om identificaties vast te stellen. Een purl die is samengesteld op basis van een veronderstelde leverancier kan naar het verkeerde pakket verwijzen. Bewaar de oorspronkelijke versiereeks, omdat een downstream build een eigen patchrevisie kan bevatten.
SPDX en CycloneDX geven beide informatie over softwarecomponenten en hun relaties weer. De beschikbare velden en hun exacte betekenis hangen af van de formaatversie. Kies een versie die de producerende en ontvangende tools kunnen verwerken.
Nauwkeurigheid en dekking van de inventaris
Een bestand kan geldige JSON zijn en toch de verkeerde release beschrijven. Vergelijk de SBOM met de buildinvoer en het geleverde artefact en onderzoek vervolgens afwijkingen. Een lijst met broncodeafhankelijkheden kan ontwikkeltools bevatten die nooit zijn geleverd en bibliotheken missen die in de image zijn gekopieerd.
- Doel: product, versie en artefact komen overeen met de release.
- Identiteit: componentversies en identificaties zijn te herleiden tot bewijs.
- Relaties: afhankelijkheidspaden zijn aanwezig en betekenisvol.
- Dekking: ontbrekende leveranciersgegevens en niet-geanalyseerde onderdelen zijn zichtbaar.
- Uitwisseling: een ontvangende tool behoudt de velden die nodig zijn voor het beoogde gebruik.
De minimale SBOM-elementen van 2026
De minimale SBOM-elementen van 2026, gezamenlijk gepubliceerd door CISA en partnerinstanties, werken de NTIA-richtsnoeren uit 2021 bij. Ze behandelen documentmetadata, componentgegevens en praktijken voor het onderhouden en delen van SBOM’s. De publicatie bevat richtsnoeren en vermeldt dat zij geen nieuwe vereisten invoert.
Vermeld bij een levering de overeengekomen specificatie, de formaatversie en aanvullende klantvereisten. Een geslaagde schemavalidatie bewijst op zichzelf niet dat de door de klant gevraagde informatie volledig is.
Kwetsbaarheidsmatches en productimpact
Een kwetsbaarheidsmatch koppelt een gemeld probleem aan de identiteit of versie van een component. Vervolgens moet worden bepaald of de getroffen code in dit product aanwezig en uitbuitbaar is. Controleer buildopties, aanpassingen, uitvoeringspaden en de voorwaarden die in het advies zijn beschreven.
Vulnerability Exploitability eXchange (VEX) communiceert de beoordeling van een specifieke kwetsbaarheid voor geïdentificeerde producten. Koppel die beoordeling aan de release en de onderliggende analyse. Een ontbrekende match kan wijzen op beperkte dekking of onvolledige identificaties.
Registraties voor ondersteunde releases
Archiveer de oorspronkelijke inventaris bij de release. Als nieuwe informatie de SBOM corrigeert zonder de software te wijzigen, geef dan een traceerbare documentrevisie uit. Als de software verandert, maak dan een registratie voor de nieuwe release.
Als een nieuw advies een kwetsbaarheid in een component identificeert, doorzoek dan de inventarissen van alle ondersteunde releases. Klanten kunnen nog een oudere release gebruiken met andere componenten dan het huidige product.