SPDX en CycloneDX: een SBOM-formaat kiezen
Sytance · Bijgewerkt
SPDX en CycloneDX beschrijven allebei softwarecomponenten en hun relaties. De keuze hangt af van de informatie die de ontvanger nodig heeft en de versies die de tools van de ontvanger kunnen verwerken. Een formaat afspreken betekent daarom ook overeenstemming bereiken over de versie, codering en verplichte velden.
De informatiebehoefte van de ontvanger
Voor een firmwareleverancier die een SBOM naar een fabrikant stuurt, kunnen andere eisen gelden dan voor een team dat de SBOM in een kwetsbaarhedenbeheerservice laadt. De ondersteunde versies en coderingen van de ontvanger bepalen welke bestanden kunnen worden verwerkt. Een representatief bestand helpt om die ondersteuning te bevestigen.
Leg de vereiste informatie vast, waaronder de productidentiteit, componentidentificaties, relaties, licenties en eventuele gegevens over kwetsbaarheden of herkomst. Als de ontvanger slechts een deel van het formaat ondersteunt, bepaal dan of de weggelaten velden het doel van de uitwisseling beïnvloeden.
Specificatieversies en ondersteuning door tools
SPDX 2.3 en SPDX 3.0.1 zijn afzonderlijk gepubliceerde specificaties. SPDX 3.0.1 gebruikt een model met profielen, waaronder een klasse voor software-SBOM's. Ga er niet van uit dat een gebruiker die SPDX 2.3 JSON accepteert ook een 3.x-document kan verwerken.
Het overzicht van de CycloneDX-specificatie vermeldt versie 1.7. Het objectmodel omvat componenten, services, afhankelijkheidsrelaties en kwetsbaarheidsinformatie. Een producent kan een recente specificatie ondersteunen terwijl een downstream-importeur alleen een eerdere versie ondersteunt.
| Uitwisselingsgegevens | SPDX-voorbeeld | CycloneDX-voorbeeld |
|---|---|---|
| Versie | 2.3 of 3.0.1 | 1.7 |
| Documentidentiteit | Documentschema voor een specifieke versie | Serienummer en stuklijstversie |
| Afhankelijkheden | Getypeerde relaties | Afhankelijkheidsgrafiek |
| Validatie | Regels voor de gekozen versie | Schema voor de gekozen versie |
Relaties en licentievelden
In SPDX 2.3 geeft CONTAINS insluiting aan en DEPENDS_ON een afhankelijkheid. Dat een pakket in een archief zit, is iets anders dan dat een ander pakket het nodig heeft om te bouwen of uit te voeren. Behoud bij het importeren het relatietype en de richting.
SPDX 2.3 maakt ook onderscheid tussen een gedeclareerde licentie en een vastgestelde licentie. De verklaring van een leverancier en de conclusie van een analist mogen niet ongemerkt in hetzelfde veld terechtkomen. Een ontvangende tool moet dit onderscheid behouden als het relevant is voor de beoordeling.
Controleer voor CycloneDX de afhankelijkheidsgrafiek en componentverwijzingen in de gekozen versie. Een platte componentenlijst kan na conversie leesbaar blijven, maar de paden verliezen die nodig zijn om te onderzoeken welke producten een component gebruiken.
Geconverteerde informatie controleren
Een klein testbestand kan laten zien welke informatie bij de conversie verloren gaat. Neem een product, een directe afhankelijkheid en een indirecte afhankelijkheid op. Twee versies van dezelfde component, een licentie-expressie en een veld dat expliciet als onbekend is gemarkeerd, helpen om meer te controleren dan alleen of het bestand wordt geaccepteerd.
- Valideer het oorspronkelijke bestand aan de hand van de opgegeven specificatieversie.
- Importeer het bestand in de ontvangende tool en controleer het doelproduct.
- Vergelijk componentidentiteiten, versies en de richting van relaties.
- Controleer de licentievelden en de weergave van onbekende informatie.
- Exporteer het bestand indien mogelijk opnieuw en vergelijk vervolgens de betekenis in plaats van de bestandsopmaak.
Een formaat voor levering kiezen
Als een klant SPDX 2.3 vereist, lever dan die versie met de afgesproken velden en bewaar het uitgebreidere bronrecord als bij de conversie andere gegevens verloren gaan. Als de ontvangende workflow al CycloneDX verwerkt en de benodigde grafiek behoudt, gebruik dan de ondersteunde versie van CycloneDX.
Als klanten beide formaten nodig hebben, onderhoud en test dan de veldtoewijzingen ertussen. Documenteer welke informatie bij conversie verloren gaat of naar extensies wordt verplaatst. De conversie moet de gegevens transformeren volgens de doelspecificatie.
Controleer na het importeren of de ontvanger de informatie nog steeds zoals bedoeld kan gebruiken. Voor kwetsbaarheidsanalyse betekent dit onder meer dat de ontvanger vanuit een component de producten en releases kan vinden die deze gebruiken.