SBOM best practices

SBOM's genereren

1. Genereer in CI, voor elke release

Een handmatig gemaakte SBOM is verouderd voordat iemand hem leest. Maak er een stap van in de pipeline die de release bouwt, of gebruik een runner die er een oplevert zonder dat daar een stap voor nodig is, zodat geen enkele release zonder SBOM wordt geleverd. Voor GitHub Actions, zie hoe u een SBOM genereert in GitHub Actions.

2. Beschrijf de build die is geleverd

Builds zijn standaard niet reproduceerbaar. Twee keer dezelfde commit bouwen biedt geen garantie op dezelfde afhankelijkheden, omdat versies tijdens de build worden opgelost en stappen kunnen verschillen. Een SBOM van een laptop of uit een latere scan beschrijft een vergelijkbare build, niet de build die u hebt geleverd. Alleen een SBOM uit de CI-build die de release heeft opgeleverd, bewijst wat erin zit. Zie build-time SBOM's.

3. Dek meer dan de lockfile

Een lockfile is geen record van wat er is geleverd. Installatiescripts downloaden code, Rust-buildscripts halen bestanden op en containerbuilds brengen een base image mee met eigen besturingssysteempakketten. Bepaal wat de SBOM moet dekken en test dat: zoek in uw SBOM naar een pakket uit uw base image en een buildtool.

4. Neem transitieve afhankelijkheden en relaties op

Kwetsbaarheden zitten meestal onder uw directe afhankelijkheden. Een platte lijst laat zien dat een component er is, maar niet wat u moet upgraden. Bewaar de dependency graph in de SBOM, zodat een bevinding samen komt met het pakket dat hem binnenhaalt.

5. Benoem wat u niet kon zien

De 2026 Minimum Elements vragen SBOM-auteurs om onbekende informatie expliciet aan te duiden. Een gedeeltelijke SBOM die dat zegt, is meer waard dan een gedeeltelijke SBOM die er af uitziet. Leg ook de tool, de versie ervan en de generatiecontext vast, zodat een lezer kan beoordelen wat het bestand dekt.

SBOM's bewaren

6. Bewaar één SBOM per release, gekoppeld aan het artefact

Als een klant op een oude versie vraagt of hij kwetsbaar is, hebt u de SBOM van die versie nodig en niet de nieuwste. Sla elke SBOM op bij de build en het artefact die hij beschrijft, en bepaal de bewaartermijn op basis van hoe lang u de release ondersteunt. Hashes in de SBOM helpen om hem aan het exacte artefact te koppelen.

7. Kies een formaat en een identificator, en houd u eraan

Standaardiseer op CycloneDX of SPDX, een formaatversie en package URLs als identificatoren. De meeste problemen bij het vergelijken van SBOM's ontstaan doordat tools hetzelfde anders noemen. Valideer elk bestand in de pipeline en vraag leveranciers om hetzelfde formaat.

SBOM's gebruiken

8. Monitor wat is geleverd, niet alleen wat u bouwt

Het waardevolste moment voor een SBOM is de dag nadat er een advisory verschijnt voor software die vorig jaar is uitgebracht. Een scan in een pull request helpt dan niet. Beoordeel de opgeslagen SBOM's van ondersteunde releases opnieuw aan de hand van nieuwe kwetsbaarheidsgegevens, zodat een nieuwe advisory uitmondt in een lijst van getroffen releases.

9. Stuur bevindingen naar een eigenaar en leg de beslissing vast

Een SBOM met duizend gematchte kwetsbaarheden is een lijst, geen plan. Rangschik bevindingen met een prioriteringsmethode, stuur elke bevinding naar het team dat verantwoordelijk is voor de oplossing, en leg vast waarom u de rest niet hebt aangepakt, bijvoorbeeld in een VEX-verklaring.

10. Gebruik dezelfde SBOM voor klanten en auditors

Klanten, auditors en toezichthouders stellen vergelijkbare vragen. Beantwoord ze vanuit de SBOM die uw eigen teams gebruiken, in plaats van een apart document te maken dat uit de pas gaat lopen. Als u SBOM's deelt, bepaal dan wie ze mag zien en hoe die updates krijgen, en vraag uw leveranciers hetzelfde.

Veelgemaakte fouten

Fout	Waarom het schaadt	Doe in plaats daarvan
Eén SBOM per repository	Die zegt niets over een specifieke release	Eén per release, gekoppeld aan het artefact
Alleen genereren voor een audit	Die beschrijft een build die niemand heeft geleverd	Elke release, in CI
De SBOM als afgerond beschouwen	Nieuwe advisories verschijnen na de release	Blijf hem monitoren
Alleen het aantal componenten vergelijken	Meer is niet beter als de vermeldingen niet kloppen	Controleer specifieke pakketten waarvan u weet dat ze erin zitten

Hoe CRACI dit aanpakt

CRACI dekt de best practices die van de build afhangen. Het is een GitHub Actions-runner die elk pakket vastlegt dat een job ophaalt, inclusief verborgen afhankelijkheden die in geen enkele lockfile staan, in een CycloneDX- of SPDX-SBOM met een volledigheidsstatus. CRACI bewaart elke eerdere build en de bijbehorende SBOM binnen de bewaartermijn van uw abonnement, beoordeelt gemonitorde SBOM's opnieuw zodra nieuwe kwetsbaarheden verschijnen en laat zien welke builds een kwetsbare afhankelijkheid bevatten. Securityteams beoordelen bevindingen en sturen ze naar de teams die verantwoordelijk zijn voor de oplossing. Zie SBOM-beheer voor hoe beheertools zich tot elkaar verhouden, of de beste SBOM-tools.

SBOM best practices: veelgestelde vragen

Wanneer genereert u een SBOM?

Tijdens de CI-build die de release oplevert, elke keer weer. Een SBOM die op dat moment wordt gemaakt, beschrijft wat er is geleverd, terwijl een latere SBOM een herbouw of een scan beschrijft.

Hoe lang moet u SBOM's bewaren?

Minstens zolang u de release ondersteunt, plus wat uw toezichthouders of contracten vereisen. U hebt de SBOM van een oude versie nodig om te bepalen of de gebruikers ervan door een nieuwe kwetsbaarheid worden getroffen.

Moeten SBOM's worden geautomatiseerd?

Ja. Een handmatige SBOM is bij de volgende release al verouderd. Genereer SBOM's in de pipeline, valideer ze daar en sla ze op bij de build.

Moet u uw SBOM met klanten delen?

Deel hem als een klant of toezichthouder daarom vraagt, onder voorwaarden waar u zich prettig bij voelt. Een SBOM onthult wat u gebruikt, dus veel bedrijven delen hem op verzoek in plaats van hem te publiceren.

Wat is het verschil tussen een SBOM en SBOM-beheer?

Een SBOM is één bestand. SBOM-beheer is het doorlopende werk van SBOM's per release opslaan, ze monitoren op nieuwe kwetsbaarheden en ze beschikbaar maken voor de mensen die ze nodig hebben.