De beste SBOM-verktøyene i 2026

Det korte svaret

• Gratis SBOM-er for container-images og filsystemer: Syft, eller Trivy hvis du også vil ha en skanner for sårbarheter, hemmeligheter og IaC.
• CycloneDX fra kildekode: cdxgen, fra CycloneDX-miljøet.
• SPDX for byggeutdata du allerede pakker: Microsoft SBOM Tool.
• Arbeidslaster på AWS: Amazon Inspector SBOM Generator, som mater Amazon Inspector.
• En rask SBOM av et GitHub-repositorium: eksporten fra GitHubs avhengighetsgraf.
• Et gratis, selvhostet sted å overvåke SBOM-er: OWASP Dependency-Track.
• Lisenssamsvar først: FOSSA. SBOM-er fra leverandører og for hele porteføljen: Manifest eller Cybeats. Containerflåter og policypakker for offentlig sektor: Anchore Enterprise.
• En SBOM over det dine egne bygg faktisk hentet inn, med sårbarhetsovervåking og provenance-data: CRACI, for GitHub Actions.

Hva et SBOM-verktøy gjør

En software bill of materials lister opp komponentene, bibliotekene og avhengighetene i en programvare, i et maskinlesbart format som CycloneDX eller SPDX. SBOM-verktøy finnes i to typer. Generatorer skriver SBOM-en. Håndteringsverktøy lagrer SBOM-er fra mange produkter og leverandører, matcher dem mot sårbarhetsdata, håndhever policyer og deler dem. Håndteringsverktøy er avhengige av det generatorene mater dem med.

Når SBOM-en tas, betyr like mye som hvilket verktøy som tar den. CISAs veiledning om SBOM-typer skiller mellom en source-SBOM, laget fra utviklingsmiljøet og kildefilene, en build-SBOM, generert som en del av byggingen av den utgivelsesklare artefakten, og en analyzed-SBOM, generert ved å analysere artefakter som kjørbare filer og container-images etter bygget. De fleste generatorene nedenfor produserer source- eller analyzed-SBOM-er. CRACI produserer en build-SBOM. SBOM-er fra bygget forklarer forskjellen i detalj.

Hvem dette er for

Denne siden er for team som trenger SBOM-er, for Cyber Resilience Act, et kundespørreskjema eller sitt eget sårbarhetsarbeid, og som går gjennom alternativene. Vi lager CRACI, så ta det med i vurderingen. Hver påstand om et annet verktøy kommer fra dokumentasjonen til det verktøyet, og hvert verktøy har en lengre CRACI vs X-side.

Slik velger du et SBOM-verktøy

• Trenger du å produsere SBOM-er, håndtere dem, eller begge deler? En generator gir deg en fil. Et håndteringsverktøy gir deg et sted å oppbevare filer fra mange produkter og leverandører, berike dem og handle ut fra dem.
• Er programvaren din eller kjøpt? For dine egne bygg styrer du det som går inn, så du kan registrere det. For programvare fra leverandører trenger du mottak, validering og noen ganger binæranalyse.
• Hvor sikker må du være på at listen er fullstendig? Generatorer leser filer i etterkant, og de er mer uenige enn de fleste tror (se nedenfor). En build-SBOM beskriver hva bygget brukte.
• Hvilket format ber kundene dine om? CycloneDX og SPDX er begge bredt akseptert; de fleste verktøy skriver minst ett av dem.
• Hvilken CI kjører du, og må den være selvhostet? Generatorer med åpen kildekode kjører hvor som helst. CRACI støtter GitHub Actions på Linux i dag, som en administrert tjeneste, med GitLab CI, Jenkins og kundehostede runnere på veikartet.

SBOM-generatorer

Dette sammenligner hva hver generator gjør, ikke hvor mange komponenter den returnerer.

CRACI

CRACI er en registrerer, ikke en skanner. GitHub Actions-jobbene dine kjører på CRACI-runnere, og en pakkebevisst proxy registrerer hva hver jobb henter, inkludert pakker gjenopprettet fra en CI-cache. SBOM-en, i CycloneDX eller SPDX, inkluderer de transitive avhengighetene bygget brukte, og angir fullstendigheten per jobb og per cache. CRACI fortsetter deretter å vurdere overvåkede SBOM-er på nytt, så det gjør jobben til en generator og et håndteringsverktøy samlet. Passer best for programvare du bygger i GitHub Actions. Vær obs på: Det kan ikke skanne et image eller en mappe, og det kjører Linux-jobber på GitHub Actions i dag (andre CI-systemer, Windows og macOS står på veikartet). SBOM-generering i CRACI

Syft

Syft er Anchores gratis Apache-2.0-generator for container-images og filsystemer. Den gjenkjenner dusinvis av pakketyper, skriver CycloneDX, SPDX og Syft JSON og kan lage signerte in-toto SBOM-attestasjoner. Grype, søsterverktøyet, matcher SBOM-en mot sårbarheter. Passer best for images og for alle pipelines som trenger en gratis generator. Vær obs på: Katalogiserere velges etter skannetype, så på en installert express-checkout avgjør ett flagg om npm-pakker i det hele tatt dukker opp i resultatet. CRACI vs Syft og Grype

Trivy

Trivy, fra Aqua Security, er en allsidig Apache-2.0-skanner for images, filsystemer, repositorier, VM-images og Kubernetes. Den finner sårbarheter, feilkonfigurasjon i IaC, hemmeligheter og lisenser, og skriver CycloneDX eller SPDX som en bieffekt. Passer best for team som vil ha én gratis binærfil for mange sikkerhetskontroller. Vær obs på: For et repositorium leser den lockfiler, så express 5.2.1 (ingen lockfile) og claude-code (intet manifest) gir den ingenting å lese, nøyaktig som dokumentert. CRACI vs Trivy

cdxgen

cdxgen er et OWASP CycloneDX-prosjekt som lager CycloneDX BOM-er fra kildekode og container-images, under Apache-2.0. Passer best for team som har standardisert på CycloneDX og vil ha en generator fra formatets eget miljø. Vær obs på: Som de andre skannerne kan den bare rapportere det filene den har foran seg, deklarerer. CRACI vs en egen SBOM-stack

Microsoft SBOM Tool

Microsoft SBOM Tool er en MIT-lisensiert generator som skriver SPDX 2.2, eller SPDX 3.0 på forespørsel, og kan validere en SBOM mot SPDX-spesifikasjonen. Den forventer en build drop-mappe, et pakkenavn, en versjon og en leverandør på kommandolinjen, noe som gjør den til et steg etter bygget, og den kjører i GitHub Actions og Azure Pipelines. Passer best for team som vil ha SPDX for byggeutdata de allerede pakker. Vær obs på: Pekt mot repositorier slik de er committet, og ikke mot en build drop, har den nesten ingenting å beskrive. Fordi den tar en leverandør på kommandolinjen, kan den fylle ut leverandørfeltet. CRACI vs en egen SBOM-stack

Eksport fra GitHubs avhengighetsgraf

GitHubs avhengighetsgraf oppsummerer manifester og lockfiler i et repositorium, pluss alt som sendes gjennom dependency submission API, og eksporterer som SPDX fra brukergrensesnittet eller REST-API-et. Den mater Dependabot-varsler og er inkludert i alle GitHub-planer. Passer best for team som allerede er på GitHub og trenger en rask SBOM. Vær obs på: Den gjenspeiler standardgrenen og ikke en festet commit, og den bygges ut fra det GitHub vet om repositoriet, ikke fra filer en skanner leser. CRACI vs GitHub Advanced Security

Amazon Inspector SBOM Generator

Sbomgen er generatoren bak Amazon Inspectors egen skanning av images, Lambda og EC2, tilbudt som en frittstående Linux-binærfil. Den leser pakkemetadata fra container-images, mapper, arkiver, monterte volumer og kompilerte Go- og Rust-binærfiler, dekker OS-pakker (APK, DPKG, RPM) og språk som C#, Go, Java, Node.js, PHP, Python, Ruby og Rust, og skriver CycloneDX. Den kan sende SBOM-en til Amazon Inspector Scan API for sårbarhetsfunn, noe som krever en AWS-konto. Passer best for team der arbeidslastene allerede kjører på AWS. Vær obs på: Den kjører bare på Linux, og som de andre skannerne finner den det filene den leser, deklarerer.

Safeguard

CLI-en til Safeguard kjører Syft og Grype for å produsere CycloneDX- og SPDX-SBOM-er fra repositorier, container-images og opplastede manifester, og plattformen legger til AI-skrevne pull requests med rettinger og policy gates. Passer best for team som vil ha skanning og automatiserte rettinger i ett abonnement. Vær obs på: Som de andre skannerne lister den opp det filene den leser, deklarerer. CRACI vs Safeguard

Hva en skannet SBOM avhenger av

Pek generatorene over mot samme repositorium, og de returnerer ulike lister. Dette er mønstrene verktøyenes egen dokumentasjon forutsier:

• Verktøy er uenige om hva som regnes som en komponent. Hver generator bestemmer selv hvilke filer den skal stole på og hvordan den skal navngi det den finner, så ett repositorium gir hver av dem en annen liste.
• Ingen lockfile, ingen avhengigheter. Express 5.2.1 committer ingen, så en generator som løser avhengigheter fra lockfiler, rapporterer ingen av npm-avhengighetene og returnerer det den ellers gjenkjenner.
• Ikke noe manifest i det hele tatt. Repositoriet claude-code har ikke noe manifest eller noen lockfile, så det hvert verktøy returnerer, er satt sammen fra andre filtyper og sier mer om verktøyet enn om prosjektet.
• Tynne metadata. Leverandørfeltet blir ofte tomt, fordi de fleste generatorer ikke har noen kilde for det.

Ingen av disse verktøyene er ødelagt. Hvert av dem leser filene det har foran seg, slik det er laget for. Lærdommen er at en skannet SBOM avhenger av verktøyet, innstillingene og om noen installerte avhengighetene først. Hva Syft, Trivy og cdxgen hver for seg leser, ser du i hva SBOM-generatorer med åpen kildekode går glipp av.

Verktøy for SBOM-håndtering

Anchore Enterprise

Anchore Enterprise bygger på Syft og Grype og legger til det store organisasjoner trenger: SBOM-er for containere, kildekode og filsystemer, importerte SBOM-er validert for korrekt skjema, kontinuerlig ny skanning uten den opprinnelige artefakten, og policypakker for FedRAMP, NIST, CIS, PCI DSS og CMMC. Det rulles ut på Kubernetes, Docker Compose eller air-gapped. Passer best for containerflåter på tvers av flere CI-systemer og for offentlig arbeid. Vær obs på: SBOM-ene beskriver fortsatt det en skanner fant, og prisen er på forespørsel. CRACI vs Anchore

FOSSA

FOSSA begynte med lisenssamsvar: lisensdeteksjon i fulltekst, policyer og attribusjonsmerknader. Det genererer og importerer SPDX- og CycloneDX-SBOM-er, kan legge til VDR- eller VEX-erklæringer, sjekker importer mot minimumselementene til NTIA og FDA og deler SBOM-er gjennom en portal på Enterprise. Free-planen dekker 5 prosjekter. Passer best for team der lisensrisiko er hovedbekymringen. Vær obs på: CLI-en spør byggeverktøyene dine når et fungerende bygg er tilgjengelig, og utleder fra kildekoden når det ikke er det, og binær- og snippet-skanning er tillegg. CRACI vs FOSSA

Cybeats SBOM Studio

SBOM Studio kaller seg «the SBOM system of record». Det importerer og eksporterer SPDX 2.2 til 3.0.1 og CycloneDX 1.2 til 1.7, gir SBOM-kvalitet en score før import, matcher hver komponent kontinuerlig og deler SBOM- og VEX-data med kunder, også over Transparency Exchange API. Passer best for produktsikkerhetsteam innen ICS, medisinsk utstyr, telekom og bilindustri som driver et SBOM-program. Vær obs på: Det håndterer SBOM-er i stedet for å produsere dem, og en kvalitetsscore bekrefter formatet, ikke hva generatoren gikk glipp av. CRACI vs Cybeats og Cybeats-alternativer

Manifest

Manifest samler inn, beriker og deler SBOM-er på tvers av produktene dine, leverandørene dine og AI-modellene dine. Leverandører laster opp gjennom en sikker portal, og når de ikke leverer noen, kan Manifest analysere binærfilen og generere en. Det støtter SPDX, CycloneDX og VEX og er kartlagt mot FDA-veiledning, NIST 800-218 og UNECE R155. Passer best for organisasjoner der hovedeksponeringen er programvare de kjøper. Vær obs på: GitHub Action-en genererer førsteparts-SBOM-er med Syft som standard. CRACI vs Manifest

OWASP Dependency-Track

Dependency-Track er en Apache 2.0-plattform som sporer komponenter på tvers av hver versjon av hver applikasjon, henter sårbarhetsdata fra kilder som NVD og GitHub Advisories, håndhever policyer for sikkerhet, lisenser og drift, og både leser og produserer CycloneDX VEX. Pipelines laster opp SBOM-er gjennom API-et. Passer best for team som vil ha en transparent, selvhostet analyseplattform. Vær obs på: Den genererer ikke SBOM-er, og du kjører den selv (API-serveren trenger minst 2 GB RAM og 2 CPU-kjerner). CRACI for brukere av Dependency-Track

CycloneDX eller SPDX

Begge formatene er åpne standarder, og de fleste verktøyene på denne siden skriver minst ett av dem. CycloneDX er et OWASP-prosjekt, standardisert av Ecma International som ECMA-424, og inneholder sårbarhets- og VEX-data sammen med komponentlisten. SPDX er et Linux Foundation-prosjekt og en internasjonal standard, ISO/IEC 5962:2021. Cyber Resilience Act ber om «a commonly used and machine-readable format» uten å nevne noe, så velg formatet kundene dine og verktøyene dine nedstrøms leser. Se SBOM-eksempler for begge side om side, og beste praksis for SBOM for hvordan du jobber med dem. Om lagring og overvåking av SBOM-er i stor skala, se SBOM-håndtering.

Hvor CRACI passer inn

CRACI er verken en skanner eller et håndteringsverktøy. Det er en registrerer. GitHub Actions-jobbene dine kjører på CRACI-runnere (endre runs-on til craci), og en pakkebevisst proxy registrerer hva hver jobb henter fra kildene npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git, pluss forhåndsinnstillinger for nedlastinger. Pakker gjenopprettet fra en CI-cache tar med seg dokumentasjonen sin videre. SBOM-en, i CycloneDX eller SPDX, inkluderer de transitive avhengighetene bygget brukte, og angir fullstendigheten per jobb og per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Inventarvisningen i CRACI viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter, globalt.

Etter bygget fortsetter CRACI å vurdere overvåkede SBOM-er på nytt, samler sårbarheter på tvers av bygg og repositorier, støtter VEX, returnerer SBOM-er, nettverksspor og provenance gjennom API-et og eksporterer SBOM-er som CycloneDX- eller SPDX-filer. Leverandørers SBOM-er kan legges til, så innkjøpte komponenter overvåkes sammen med dine egne bygg. Det automatiserer en betydelig del av innsynet i programvareleverandørkjeden og dokumentasjonen som bedrifter trenger for sin bredere CRA-samsvarsprosess. Se SBOM-generering i CRACI for hele funksjonaliteten.

CRACI gjør altså jobben til en generator og et håndteringsverktøy samlet, for programvaren du bygger. Det er ikke det riktige valget når:

• du trenger SBOM-er for images eller programvare du ikke har bygget (bruk en generator som Syft eller Trivy),
• du trenger en moden policymotor med mange regeltyper på tvers av en portefølje av produkter og leverandører (bruk et håndteringsverktøy),
• pipelinene dine kjører utenfor GitHub Actions, på Windows eller macOS, eller må være selvhostet (alt dette står på veikartet til CRACI).

Den raskeste måten å vurdere på er side om side: book en demo, kjør en av workflowene dine på CRACI, og legg SBOM-en ved siden av den verktøyet ditt produserer i dag.

Se også SCA-verktøy sammenlignet, AI-genererte SBOM-er vs SBOM-er fra bygget og hvorfor SBOM-er fra bygget skiller seg fra skannede.

SBOM-verktøy: ofte stilte spørsmål

Hva er et SBOM-verktøy?

Et SBOM-verktøy produserer eller håndterer en software bill of materials: en maskinlesbar liste over komponentene, bibliotekene og avhengighetene i en programvare. Generatorer som Syft, Trivy og cdxgen skriver SBOM-en ved å lese filer. Håndteringsverktøy som Dependency-Track, FOSSA og Anchore Enterprise lagrer SBOM-er, matcher dem mot sårbarhetsdata og deler dem. CRACI registrerer SBOM-en under selve bygget og overvåker den etterpå.

Hva er det beste gratis SBOM-verktøyet?

Det avhenger av hva du peker det mot. Syft og Trivy er gratis Apache-2.0-generatorer for container-images og filsystemer. cdxgen skriver CycloneDX fra kildekode og images. Microsoft SBOM Tool skriver SPDX for en mappe med byggeutdata. OWASP Dependency-Track er et gratis, selvhostet håndteringsverktøy for SBOM-ene disse verktøyene produserer.

Bør jeg bruke Syft eller Trivy?

Syft er fokusert på SBOM-generering og fungerer sammen med Grype for sårbarhetsmatching. Trivy er en bredere skanner som også finner feilkonfigurasjon i IaC, hemmeligheter og lisenser, og skriver CycloneDX eller SPDX underveis. Begge leser filene de har foran seg, så begge er avhengige av at lockfiler eller installerte pakker finnes.

CycloneDX eller SPDX: hvilket SBOM-format bør jeg bruke?

Begge er åpne, bredt støttede standarder. CycloneDX er et OWASP-prosjekt, standardisert av Ecma International som ECMA-424, og inneholder også sårbarhets- og VEX-data. SPDX er et Linux Foundation-prosjekt og en internasjonal standard, ISO/IEC 5962:2021. Bruk det kundene dine og verktøyene dine nedstrøms ber om; de fleste generatorer skriver begge.

Hvorfor gir SBOM-verktøy ulike resultater for samme prosjekt?

Hver generator bestemmer selv hvilke filer den stoler på, og hva som regnes som en komponent. Noen leser lockfiler, noen leser installerte pakker, noen leser binærfiler, og et repositorium uten lockfile gir en lockfile-leser ingenting å jobbe med. En skannet SBOM avhenger av verktøyet, innstillingene og om avhengigheter ble installert før skanningen. En SBOM fra bygget unngår dette ved å registrere hva bygget faktisk hentet.

Krever Cyber Resilience Act et bestemt SBOM-verktøy eller -format?

Nei. Annex I, Part II i CRA ber produsenter utarbeide en software bill of materials i et alminnelig brukt og maskinlesbart format som minst dekker produktenes avhengigheter på øverste nivå. CycloneDX og SPDX oppfyller begge dette. Forordningen nevner ikke noe verktøy.

Kan CRACI generere en SBOM for programvare jeg ikke har bygget?

Nei. CRACI registrerer byggene som kjører på runnerne, så SBOM-ene beskriver programvare du bygger. For programvare du kjøper, kan du legge til leverandørens SBOM i CRACI og overvåke den sammen med dine egne bygg. For et container-image fra en tredjepart som du ikke har bygget, er en skanner som Syft eller Trivy det praktiske valget.

Hvilke CI-systemer støtter CRACI?

GitHub Actions i dag, på Linux-runnere for x86-64 og ARM64. Du endrer runs-on til craci, og kjøringene vises fortsatt i GitHub. Andre CI-systemer, først GitLab CI og Jenkins, står på veikartet.