Wat open-source SBOM-generatoren missen

Hoe u met elke tool een SBOM genereert

Elke tool heeft één opdracht nodig voor een bronmap of containerimage, met uitvoer in CycloneDX of SPDX:

# Syft: a source directory or a container image
syft ./my-project -o cyclonedx-json=sbom.cdx.json
syft my-image:latest -o spdx-json=sbom.spdx.json

# Trivy: a filesystem or a container image
trivy fs --format cyclonedx --output sbom.cdx.json .
trivy image --format spdx-json --output sbom.spdx.json my-image:latest

# cdxgen: the current directory, optionally with a project type
cdxgen -o bom.json .
cdxgen -t js -o bom.json .

De opdrachten zijn het makkelijke deel. Wat er in het bestand terechtkomt, hangt af van wat elke tool leest, en dat is niet hetzelfde.

Wat elke tool leest

Tool	Bronmap	Containerimage	Goed om te weten
Syft	Een standaardset catalogers voor mappen, die gedeclareerde afhankelijkheden leest	Een standaardset catalogers voor images, die geïnstalleerde pakketten leest	Catalogers worden gekozen op basis van het scantype. syft cataloger list toont welke draaien, en --select-catalogers voegt ze toe of verwijdert ze.
Trivy	Lockfiles, voor Node.js package-lock.json, yarn.lock, pnpm-lock.yaml en bun.lock	Voor Node.js: package.json-bestanden onder node_modules	Laat ontwikkelafhankelijkheden weg, tenzij u --include-dev-deps meegeeft.
cdxgen	Eerst lockfiles, die ontwikkelafhankelijkheden bevatten; voor Node.js parseert het ook de code op imports	Ondersteund	Stel het projecttype in met -t om te beperken waarnaar het zoekt.

Waarom ze het op dezelfde repository oneens zijn

Richt ze alle drie op één commit en u krijgt drie verschillende lijsten. Geen van drieën is kapot. Elk volgt zijn eigen gedocumenteerde regels:

• Geen lockfile, geen afhankelijkheden. Express 5.2.1 commit geen lockfile. Op een schone checkout heeft een tool die afhankelijkheden afleidt uit lockfiles of geïnstalleerde pakketten geen van beide, dus de npm-afhankelijkheden die in package.json zijn gedeclareerd, bereiken de SBOM nooit. De tool schrijft nog steeds een geldig document met wat hij verder heeft herkend.
• Geïnstalleerd of gedeclareerd. Of u vóór de scan een installatie hebt uitgevoerd, kan meer uitmaken dan welke tool u gebruikt. Op een geïnstalleerde kopie van dezelfde repository bepaalt één cataloger-instelling van Syft of de geïnstalleerde npm-pakketten überhaupt verschijnen.
• Ontwikkelafhankelijkheden. Trivy laat ze standaard weg en cdxgen neemt ze mee, dus dezelfde lockfile geeft twee antwoorden op "wat zit er in dit project".
• Namen en versies. Tools identificeren sommige componenten onder verschillende package-URL-typen, of pinnen een GitHub Action vast op een commit-SHA waar een andere tool een tag rapporteert. Wie kwetsbaarheden opzoekt op de verkeerde identifier, krijgt een zelfverzekerd fout antwoord.
• Helemaal geen manifest. De repository anthropics/claude-code heeft geen manifest met afhankelijkheden, en het npm-pakket ervan omhult een voorgecompileerde binary. Wat elke tool teruggeeft, zegt meer over de tool dan over het project.

Wat ze allemaal missen: verborgen afhankelijkheden

De diepere beperking delen ze allemaal. Een scanner leest de lockfile of de uitvoer van de build en leidt daar achteraf uit af wat erin is gegaan. Alles wat de build buiten die bestanden om heeft opgehaald, bereikt de SBOM nooit. Dit zijn de verborgen afhankelijkheden:

• Install-hooks. npm-scripts preinstall en postinstall draaien tijdens de installatie en kunnen meer code downloaden. Zo draaide de Shai-Hulud-worm.
• Buildscripts, zoals Rust-buildscripts die tijdens de build downloaden wat ze nodig hebben.
• Base images en hun besturingssysteemlagen in een containerbuild, die in geen enkele lockfile van een programmeertaal staan.
• Pakketten die uit CI-caches worden teruggezet, die mogelijk niet overeenkomen met de huidige lockfile. Zie wat de GitHub Actions-cache verbergt.
• Buildtools die door setupstappen worden geïnstalleerd, met hun eigen afhankelijkheidsbomen.
• Transitieve versies die tijdens de build worden geresolved wanneer de lockfile ontbreekt, verouderd is of niet wordt gebruikt door een frozen install. Zie transitieve afhankelijkheden.

De uitvoer achteraf scannen dicht dat gat niet. Bij een afgeronde binary, zeker bij gecompileerde code zoals Rust, moet de scanner raden wat erin is gegaan. Commerciële SCA-scanners werken met dezelfde soorten bestanden en delen dezelfde blinde vlekken. CRACI heeft kwetsbare pakketten gevonden die Snyk en Aikido niet rapporteerden, omdat de componenten nooit in hun scans zaten.

De tools maken ook deel uit van uw softwareketen

Een scanner draait in uw CI met toegang tot uw code en vaak ook uw secrets. In maart 2026 beschreef de advisory van Aqua Security (CVE-2026-33634) een kwaadaardige Trivy v0.69.4-release en vergiftigde trivy-action- en setup-trivy-tags die inloggegevens van CI-runners stalen. Pin scanneractions vast op volledige commit-SHA's en controleer de advisory voor de versies die u gebruikt.

Hoe u uw eigen SBOM controleert

1. Draai twee generatoren op dezelfde commit en vergelijk de package-URL's die ze rapporteren.
2. Controleer of de repository een lockfile commit, en of CI daaruit installeert met een frozen install.
3. Scan zowel na als vóór de installatiestap, en vergelijk.
4. Vergelijk de lijst met wat uw buildlog laat zien aan downloads, inclusief setupstappen en cache-restores.

Verschillen de lijsten, dan hangt de SBOM die u publiceert af van de tool die u toevallig hebt gedraaid, en niet van wat u hebt geleverd.

Leg in plaats daarvan de build vast

CRACI ziet het verkeer; scanners niet. Het is een GitHub Actions-runner die het netwerkverkeer ziet dat elke build binnenkomt, dus de SBOM legt elk pakket vast dat de job heeft binnengehaald, op elk niveau van de boom, inclusief de verborgen afhankelijkheden en pakketten die uit CI-caches zijn teruggezet. Er is geen map om op te richten en geen cataloger om te kiezen. Kon een vastlegging niet alles zien, bijvoorbeeld omdat een job niet-gemonitord verkeer toestond, dan meldt de SBOM dat met zijn volledigheidsstatus.

Vastleggen is ook van belang omdat builds zelden reproduceerbaar zijn. Bouw dezelfde commit twee keer direct na elkaar, en de pakketbeheerder kan in een andere volgorde resolven en installeren, waardoor de tweede build andere pakketten kan bevatten. Alleen de SBOM die is vastgelegd tijdens de build die een release heeft opgeleverd, bewijst wat die release bevat.

Blijf Syft of Trivy gebruiken voor images en binaries van derden die u niet zelf hebt gebouwd. Zie voor uw eigen releases build-time SBOM's of boek een demo om op een van uw repositories een vastgelegde SBOM te vergelijken met die van uw huidige tool.

Open-source SBOM-generatoren: veelgestelde vragen

Wat is beter voor SBOM's, Syft of Trivy?

Ze zijn voor verschillende taken gebouwd. Syft is een gespecialiseerde SBOM-generator met veel catalogers en ondertekende attestaties; Trivy is een beveiligingsscanner die SBOM's als een van zijn uitvoervormen schrijft. Beide lezen de bestanden die ze voor zich hebben, dus op dezelfde repository zit het grootste verschil meestal in de vraag of er een lockfile is gecommit en of de afhankelijkheden vóór de scan zijn geïnstalleerd.

Waarom toont mijn SBOM geen afhankelijkheden?

Meestal omdat de repository geen lockfile commit en er vóór de scan niets is geïnstalleerd. Een generator die lockfiles of geïnstalleerde pakketten leest, heeft dan niets te lezen, en schrijft toch een geldige SBOM. Commit de lockfile, of scan na de installatiestap.

Neemt Trivy ontwikkelafhankelijkheden op in de SBOM?

Niet standaard. Volgens de Node.js-documentatie van Trivy rapporteert het geen ontwikkelafhankelijkheden, tenzij u --include-dev-deps meegeeft. cdxgen daarentegen parseert lockfiles en neemt ontwikkelafhankelijkheden mee. Alleen al hierdoor kunnen twee tools het op hetzelfde project oneens zijn.

Kan ik een SBOM van een open-sourcegenerator vertrouwen?

Voor wat hij heeft gelezen, ja. De vraag is wat hij niet heeft gelezen: caches, buildtools, downloads, installatiescripts en binaries zonder pakketmetadata. Behandel een gescande SBOM als een beschrijving van de bestanden waarop u de tool hebt gericht, niet van de build die uw release heeft gemaakt.

Wat is de beste SBOM-tool?

Voor software die u zelf bouwt, komt de meest complete SBOM uit het vastleggen van de build in plaats van het scannen van bestanden. CRACI legt elk pakket vast dat elke GitHub Actions-job ophaalt, ook uit caches, en heeft kwetsbare pakketten gevonden die Snyk en Aikido niet rapporteerden. Voor images en binaries van derden die u niet zelf hebt gebouwd, is een scanner zoals Syft of Trivy nog steeds de praktische keuze.