Dette går SBOM-generatorer med åpen kildekode glipp av

Slik genererer du en SBOM med hvert verktøy

Hvert verktøy trenger én kommando for en kildekatalog eller et container-image, med utdata 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 .

Kommandoene er den enkle delen. Hva som havner i filen, avhenger av hva hvert verktøy leser, og de leser ikke de samme tingene.

Hva hvert verktøy leser

Verktøy	Kildekatalog	Container-image	Verdt å vite
Syft	Et standardsett med katalogiserere for kataloger, som leser deklarerte avhengigheter	Et standardsett med katalogiserere for images, som leser installerte pakker	Katalogiserere velges etter skannetype. syft cataloger list viser hvilke som kjører, og --select-catalogers legger til eller fjerner dem.
Trivy	Lockfiler, for Node.js package-lock.json, yarn.lock, pnpm-lock.yaml og bun.lock	For Node.js, package.json-filer under node_modules	Utelater utviklingsavhengigheter med mindre du angir --include-dev-deps.
cdxgen	Lockfiler først, som inkluderer utviklingsavhengigheter; for Node.js analyserer det også koden for importer	Støttes	Angi prosjekttypen med -t for å begrense hva det ser etter.

Hvorfor de er uenige om samme repositorium

Pek alle tre mot én commit, og du får tre forskjellige lister. Ingen av dem er ødelagt. Hvert verktøy følger sine egne dokumenterte regler:

• Ingen lockfile, ingen avhengigheter. Express 5.2.1 committer ingen lockfile. I en ren utsjekk har et verktøy som løser avhengigheter fra lockfiler eller installerte pakker, ingen av delene, så npm-avhengighetene deklarert i package.json når aldri SBOM-en. Det skriver likevel et gyldig dokument med det andre det gjenkjente.
• Installert eller deklarert. Om du kjørte en installasjon før skanningen, kan bety mer enn hvilket verktøy du bruker. På en installert kopi av samme repositorium avgjør én innstilling for Syft-katalogiserere om de installerte npm-pakkene i det hele tatt dukker opp.
• Utviklingsavhengigheter. Trivy utelater dem som standard, og cdxgen tar dem med, så den samme lockfilen gir to svar på «hva er i dette prosjektet».
• Navn og versjoner. Verktøy identifiserer noen komponenter under forskjellige package URL-typer, eller fester en GitHub Action til en commit-SHA der et annet rapporterer en tagg. Et sårbarhetsoppslag basert på feil identifikator gir et selvsikkert, feil svar.
• Ikke noe manifest i det hele tatt. Repositoriet anthropics/claude-code har ikke noe avhengighetsmanifest, og npm-pakken pakker inn en ferdigbygd binærfil. Det hvert verktøy returnerer, sier mer om verktøyet enn om prosjektet.

Dette går alle glipp av: skjulte avhengigheter

Den dypere begrensningen er felles. En skanner leser lockfilen eller utdataene fra bygget og finner ut fra det hva som gikk inn, i ettertid. Alt bygget hentet utenfor disse filene, når aldri SBOM-en. Dette er de skjulte avhengighetene:

• Installasjonshooks. npm-skriptene preinstall og postinstall kjører under installasjonen og kan laste ned mer kode. Det var slik Shai-Hulud-ormen kjørte.
• Byggeskript, for eksempel Rust-byggeskript som laster ned det de trenger under bygging.
• Base-images og operativsystemlagene deres i et containerbygg, som ingen lockfile for et programmeringsspråk lister opp.
• Pakker gjenopprettet fra CI-cacher, som kanskje ikke stemmer med den gjeldende lockfilen. Se hva GitHub Actions-cachen skjuler.
• Byggeverktøy installert av oppsettsteg, med egne avhengighetstrær.
• Transitive versjoner løst under bygget når lockfilen mangler, er utdatert eller ikke brukes av en frossen installasjon. Se transitive avhengigheter.

Å skanne utdataene etterpå tetter ikke hullet. En ferdig binærfil, særlig kompilert kode som Rust, lar skanneren gjette seg til hva som gikk inn i den. Kommersielle SCA-skannere jobber ut fra de samme typene filer og har de samme blindsonene. CRACI har funnet sårbare pakker som Snyk og Aikido ikke rapporterte, fordi komponentene aldri var med i det de skannet.

Verktøyene er også en del av leverandørkjeden din

En skanner kjører i CI-en din med tilgang til koden din og ofte hemmelighetene dine. I mars 2026 beskrev en advisory fra Aqua Security (CVE-2026-33634) en ondsinnet Trivy v0.69.4-utgivelse og forgiftede trivy-action- og setup-trivy-tagger som stjal påloggingsinformasjon fra CI-runnere. Fest skanner-actions til fullstendige commit-SHA-er, og sjekk advisoryen for versjonene du kjører.

Slik sjekker du din egen SBOM

1. Kjør to generatorer på samme commit og sammenlign package URL-ene de rapporterer.
2. Sjekk om repositoriet committer en lockfile, og om CI installerer fra den med en frossen installasjon.
3. Skann etter installasjonssteget i tillegg til før det, og sammenlign.
4. Sammenlign listen med det byggeloggen viser blir lastet ned, inkludert oppsettsteg og gjenoppretting av cacher.

Hvis listene er forskjellige, avhenger SBOM-en du publiserer, av hvilket verktøy du tilfeldigvis kjørte, ikke av hva du leverte.

Registrer bygget i stedet

CRACI ser trafikken; det gjør ikke skannere. Det er en GitHub Actions-runner som ser nettverkstrafikken som kommer inn i hvert bygg, så SBOM-en registrerer hver pakke jobben hentet inn, på alle nivåer i treet, inkludert de skjulte avhengighetene og pakker gjenopprettet fra CI-cacher. Det er ingen katalog å peke mot og ingen katalogiserer å velge. Når en registrering ikke kunne se alt, for eksempel fordi en jobb tillot uovervåket trafikk, sier SBOM-en fra med fullstendighetsstatusen sin.

Registrering er også viktig fordi bygg sjelden er reproduserbare. Bygg samme commit to ganger rett etter hverandre, og pakkebehandleren kan løse og installere i en annen rekkefølge, så det andre bygget kan inneholde andre pakker. Bare SBOM-en registrert under bygget som produserte en utgivelse, beviser hva den utgivelsen inneholder.

Behold Syft eller Trivy for images og binærfiler fra tredjeparter som du ikke har bygget selv. For dine egne utgivelser, se SBOM-er fra bygget eller book en demo for å sammenligne en registrert SBOM med den fra det nåværende verktøyet ditt på et av repositoriene dine.

SBOM-generatorer med åpen kildekode: ofte stilte spørsmål

Hva er best for SBOM-er, Syft eller Trivy?

De er laget for forskjellige oppgaver. Syft er en dedikert SBOM-generator med mange katalogiserere og signerte attestasjoner; Trivy er en sikkerhetsskanner som skriver SBOM-er som ett av utdataformatene sine. Begge leser filene de har foran seg, så på samme repositorium er den største forskjellen som regel om en lockfile er committet, og om avhengighetene ble installert før skanningen.

Hvorfor viser SBOM-en min ingen avhengigheter?

Som oftest fordi repositoriet ikke har committet noen lockfile og ingenting ble installert før skanningen. En generator som leser lockfiler eller installerte pakker, har da ingenting å lese, og den skriver likevel en gyldig SBOM. Commit lockfilen, eller skann etter installasjonssteget.

Tar Trivy med utviklingsavhengigheter i SBOM-en?

Ikke som standard. Trivys dokumentasjon for Node.js sier at det ikke rapporterer utviklingsavhengigheter med mindre du angir --include-dev-deps. cdxgen analyserer derimot lockfiler og tar med utviklingsavhengigheter. To verktøy kan være uenige om samme prosjekt bare av den grunnen.

Kan jeg stole på en SBOM fra en generator med åpen kildekode?

For det den leste, ja. Spørsmålet er hva den ikke leste: cacher, byggeverktøy, nedlastinger, installasjonsskript og binærfiler uten pakkemetadata. Behandle en skannet SBOM som en beskrivelse av filene du pekte verktøyet mot, ikke av bygget som laget utgivelsen din.

Hva er det beste SBOM-verktøyet?

For programvare du bygger selv, kommer den mest fullstendige SBOM-en fra å registrere bygget i stedet for å skanne filer. CRACI registrerer hver pakke hver GitHub Actions-jobb henter, også fra cacher, og har funnet sårbare pakker som Snyk og Aikido ikke rapporterte. For images og binærfiler fra tredjeparter som du ikke har bygget selv, er en skanner som Syft eller Trivy fortsatt det praktiske valget.