Hvad open source-generatorer af SBOM'er overser

Sådan genererer du en SBOM med hvert værktøj

Hvert værktøj er én kommando for en kildemappe eller et container-image, med output i CycloneDX eller 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 .

Kommandoerne er den lette del. Hvad der ender i filen, afhænger af, hvad hvert værktøj læser, og de læser ikke de samme ting.

Hvad hvert værktøj læser

Værktøj	Kildemappe	Container-image	Værd at vide
Syft	Et sæt standard-catalogers til mapper, der læser deklarerede afhængigheder	Et sæt standard-catalogers til images, der læser installerede pakker	Catalogers vælges efter scanningstype. syft cataloger list viser, hvilke der kører, og --select-catalogers tilføjer eller fjerner dem.
Trivy	Lockfiles, for Node.js package-lock.json, yarn.lock, pnpm-lock.yaml og bun.lock	For Node.js package.json-filer under node_modules	Udelader udviklingsafhængigheder, medmindre du angiver --include-dev-deps.
cdxgen	Først lockfiles, som omfatter udviklingsafhængigheder; for Node.js parser det også koden for imports	Understøttet	Angiv projekttypen med -t for at begrænse, hvad det leder efter.

Derfor er de uenige om det samme repository

Peg alle tre på ét commit, og du får tre forskellige lister. Ingen af dem er i stykker. Hver følger sine egne dokumenterede regler:

• Ingen lockfile, ingen afhængigheder. Express 5.2.1 committer ingen lockfile. På en ren checkout har et værktøj, der resolver afhængigheder ud fra lockfiles eller installerede pakker, ingen af delene, så de npm-afhængigheder, der er deklareret i package.json, når aldrig SBOM'en. Det skriver stadig et gyldigt dokument med det, det ellers genkendte.
• Installeret eller deklareret. Om du kørte en installation før scanningen, kan betyde mere end, hvilket værktøj du bruger. På en installeret kopi af det samme repository afgør én Syft-cataloger-indstilling, om de installerede npm-pakker overhovedet kommer med.
• Udviklingsafhængigheder. Trivy udelader dem som standard, og cdxgen medtager dem, så den samme lockfile giver to svar på "hvad er der i dette projekt".
• Navne og versioner. Værktøjer identificerer nogle komponenter under forskellige package URL-typer eller fastlåser en GitHub Action på en commit-SHA, hvor et andet rapporterer et tag. Et sårbarhedsopslag på den forkerte identifikator giver et selvsikkert forkert svar.
• Slet intet manifest. Repositoriet anthropics/claude-code har intet afhængighedsmanifest, og dets npm-pakke pakker en færdigbygget binærfil ind. Det, hvert værktøj returnerer, siger mere om værktøjet end om projektet.

Hvad de alle overser: skjulte afhængigheder

Den dybere begrænsning er fælles. En scanner læser lockfilen eller buildets output og udleder ud fra det, hvad der gik ind, bagefter. Det, buildet hentede uden for de filer, når aldrig SBOM'en. Det er de skjulte afhængigheder:

• Install-hooks. npm-scripts som preinstall og postinstall kører under installationen og kan downloade mere kode. Det er sådan, Shai-Hulud-ormen kørte.
• Build-scripts, for eksempel Rust-build-scripts, der downloader det, de har brug for, under buildet.
• Base-images og deres styresystemlag i et container-build, som ingen sprogspecifik lockfile angiver.
• Pakker gendannet fra CI-caches, som måske ikke matcher den aktuelle lockfile. Se hvad GitHub Actions-cachen skjuler.
• Build-værktøjer installeret af setup-trin, med deres egne afhængighedstræer.
• Transitive versioner resolvet under buildet, når lockfilen mangler, er forældet eller ikke bruges af en frosset installation. Se transitive afhængigheder.

At scanne outputtet bagefter lukker ikke hullet. En færdig binærfil, især kompileret kode som Rust, lader scanneren gætte på, hvad der gik ind i den. Kommercielle SCA-scannere arbejder ud fra de samme slags filer og har de samme blinde vinkler. CRACI har fundet sårbare pakker, som Snyk og Aikido ikke rapporterede, fordi komponenterne aldrig var i det, de scannede.

Værktøjerne er også en del af din forsyningskæde

En scanner kører i dit CI med adgang til din kode og ofte dine secrets. I marts 2026 beskrev Aqua Securitys advisory (CVE-2026-33634) en ondsindet Trivy v0.69.4-release og forgiftede trivy-action- og setup-trivy-tags, der stjal legitimationsoplysninger fra CI-runnere. Fastlås scanner-actions på fulde commit-SHA'er, og tjek advisoryen for de versioner, du kører.

Sådan tjekker du din egen SBOM

1. Kør to generatorer på det samme commit, og sammenlign de package URL'er, de rapporterer.
2. Tjek, om repositoriet committer en lockfile, og om CI installerer fra den med en frosset installation.
3. Scan efter installationstrinnet såvel som før det, og sammenlign.
4. Sammenlign listen med det, din build-log viser bliver downloadet, inklusive setup-trin og gendannelser af caches.

Hvis listerne er forskellige, afhænger den SBOM, du udgiver, af, hvilket værktøj du tilfældigvis kørte, ikke af, hvad du leverede.

Registrér buildet i stedet

CRACI ser trafikken; det gør scannere ikke. Det er en GitHub Actions-runner, der ser netværkstrafikken ind i hvert build, så dets SBOM registrerer hver pakke, jobbet trak ind, i alle lag af træet, inklusive de skjulte afhængigheder og pakker gendannet fra CI-caches. Der er ingen mappe at pege på og ingen cataloger at vælge. Når en registrering ikke kunne se alt, for eksempel fordi et job tillod uovervåget trafik, siger SBOM'en det med sin fuldstændighedsstatus.

Registrering er også vigtig, fordi builds sjældent er reproducerbare. Byg det samme commit to gange lige efter hinanden, og pakkehåndteringen kan resolve og installere i en anden rækkefølge, så det andet build kan indeholde andre pakker. Kun den SBOM, der er registreret under det build, der producerede en release, beviser, hvad den release indeholder.

Behold Syft eller Trivy til tredjeparts-images og binærfiler, du ikke selv har bygget. For dine egne releases, se SBOM'er fra buildet, eller book en demo for at sammenligne en registreret SBOM med dit nuværende værktøjs på et af dine repositories.

Open source-generatorer af SBOM'er: ofte stillede spørgsmål

Hvad er bedst til SBOM'er, Syft eller Trivy?

De er bygget til forskellige opgaver. Syft er en dedikeret SBOM-generator med mange catalogers og signerede attestationer; Trivy er en sikkerhedsscanner, der skriver SBOM'er som et af sine output. Begge læser de filer, de har foran sig, så på det samme repository er den største forskel som regel, om der er committet en lockfile, og om afhængighederne blev installeret før scanningen.

Hvorfor viser min SBOM ingen afhængigheder?

Oftest fordi repositoriet ikke committer en lockfile, og intet blev installeret før scanningen. En generator, der læser lockfiles eller installerede pakker, har så intet at læse, og den skriver stadig en gyldig SBOM. Commit lockfilen, eller scan efter installationstrinnet.

Medtager Trivy udviklingsafhængigheder i SBOM'en?

Ikke som standard. Trivys Node.js-dokumentation siger, at det ikke rapporterer udviklingsafhængigheder, medmindre du angiver --include-dev-deps. cdxgen parser derimod lockfiles og medtager udviklingsafhængigheder. To værktøjer kan være uenige om det samme projekt alene af den grund.

Kan jeg stole på en SBOM fra en open source-generator?

For det, den læste, ja. Spørgsmålet er, hvad den ikke læste: caches, build-værktøjer, downloads, install-scripts og binærfiler uden pakkemetadata. Betragt en scannet SBOM som en beskrivelse af de filer, du pegede værktøjet på, ikke af det build, der lavede din release.

Hvad er det bedste SBOM-værktøj?

For software, du selv bygger, kommer den mest komplette SBOM fra at registrere buildet i stedet for at scanne filer. CRACI registrerer hver pakke, hvert GitHub Actions-job henter, også fra caches, og har fundet sårbare pakker, som Snyk og Aikido ikke rapporterede. For tredjeparts-images og binærfiler, du ikke selv har bygget, er en scanner som Syft eller Trivy stadig det praktiske valg.