Bästa SBOM-verktygen 2026

Det korta svaret

• Gratis SBOM:er för containeravbilder och filsystem: Syft, eller Trivy om du också vill ha en skanner för sårbarheter, hemligheter och IaC.
• CycloneDX från källkod: cdxgen, från CycloneDX-communityn.
• SPDX för ett byggresultat du redan paketerar: Microsoft SBOM Tool.
• Arbetslaster på AWS: Amazon Inspector SBOM Generator, som matar Amazon Inspector.
• En snabb SBOM av ett GitHub-repo: GitHubs export av beroendegrafen.
• Ett gratis, självhostat ställe att bevaka SBOM:er på: OWASP Dependency-Track.
• Licensefterlevnad först: FOSSA. SBOM:er för leverantörer och portföljer: Manifest eller Cybeats. Containerflottor och policypaket för myndigheter: Anchore Enterprise.
• En SBOM över vad dina egna byggen faktiskt drog in, med sårbarhetsbevakning och proveniensdata: CRACI, för GitHub Actions.

Vad ett SBOM-verktyg gör

En software bill of materials listar komponenterna, biblioteken och beroendena i en programvara, i ett maskinläsbart format som CycloneDX eller SPDX. SBOM-verktyg finns i två sorter. Generatorer skriver SBOM:en. Hanteringsverktyg lagrar SBOM:er från många produkter och leverantörer, matchar dem mot sårbarhetsdata, tillämpar policy och delar dem. Hanteringsverktyg är beroende av vad generatorerna matar dem med.

När SBOM:en tas fram spelar lika stor roll som vilket verktyg som tar fram den. CISA:s vägledning om SBOM-typer skiljer på en source-SBOM, skapad från utvecklingsmiljön och källfiler, en build-SBOM, genererad som en del av bygget av den släppbara artefakten, och en analyzed-SBOM, genererad genom att analysera artefakter som körbara filer och containeravbilder efter bygget. De flesta generatorer nedan tar fram source- eller analyzed-SBOM:er. CRACI tar fram en build-SBOM. SBOM:er från bygget förklarar skillnaden i detalj.

Vem det här är till för

Den här sidan är till för team som behöver SBOM:er, för Cyber Resilience Act, ett kundformulär eller sitt eget sårbarhetsarbete, och som håller på att sortera bland alternativen. Vi bygger CRACI, så väg in det. Varje påstående om ett annat verktyg kommer från dess egen dokumentation, och varje verktyg har en längre sida med CRACI vs X.

Så väljer du ett SBOM-verktyg

• Behöver du ta fram SBOM:er, hantera dem eller båda? En generator ger dig en fil. Ett hanteringsverktyg ger dig ett ställe att ha filer från många produkter och leverantörer på, berika dem och agera på dem.
• Är programvaran din eller inköpt? För dina egna byggen styr du indata, så du kan registrera dem. För leverantörers programvara behöver du mottagning, validering och ibland binäranalys.
• Hur säker behöver du vara på att listan är komplett? Generatorer läser filer i efterhand, och de är oense mer än de flesta tror (se nedan). En build-SBOM beskriver vad bygget använde.
• Vilket format frågar dina kunder efter? CycloneDX och SPDX är båda brett accepterade; de flesta verktyg skriver minst ett av dem.
• Vilken CI kör du, och måste den vara självhostad? Generatorer med öppen källkod körs var som helst. CRACI har i dag stöd för GitHub Actions på Linux, som en hanterad tjänst, med GitLab CI, Jenkins och kundhostade runners på roadmapen.

SBOM-generatorer

Det här jämför vad varje generator gör, inte hur många komponenter den returnerar.

CRACI

CRACI registrerar snarare än skannar. Dina GitHub Actions-jobb körs på CRACI-runners, och en paketmedveten proxy registrerar vad varje jobb hämtar, inklusive paket som återställs från en CI-cache. SBOM:en, i CycloneDX eller SPDX, inkluderar de transitiva beroenden som bygget använde och anger sin fullständighet per jobb och per cache. CRACI fortsätter sedan att omvärdera bevakade SBOM:er, så det gör både en generators och ett hanteringsverktygs jobb. Bäst för programvara du bygger i GitHub Actions. Se upp: det kan inte skanna en avbild eller en katalog, och det kör i dag Linux-jobb på GitHub Actions (andra CI-system, Windows och macOS finns på roadmapen). SBOM-generering i CRACI

Syft

Syft är Anchores gratis generator under Apache-2.0 för containeravbilder och filsystem. Den känner igen dussintals pakettyper, skriver CycloneDX, SPDX och Syft JSON, och kan skapa signerade in-toto SBOM-attesteringar. Grype, dess följeslagare, matchar SBOM:en mot sårbarheter. Bäst för avbilder och för alla pipelines som behöver en gratis generator. Se upp: katalogiserare väljs utifrån skanningstyp, så på en installerad checkout av express avgör en enda flagga om npm-paket över huvud taget syns i resultatet. CRACI vs Syft och Grype

Trivy

Trivy, från Aqua Security, är en mångsidig skanner under Apache-2.0 för avbilder, filsystem, repon, VM-avbilder och Kubernetes. Den hittar sårbarheter, felkonfigurationer i IaC, hemligheter och licenser, och skriver CycloneDX eller SPDX som en bieffekt. Bäst för team som vill ha en enda gratis binär för många säkerhetskontroller. Se upp: för ett repo läser den lockfiler, så express 5.2.1 (ingen lockfile) och claude-code (inget manifest) ger den inget att läsa, precis som dokumenterat. CRACI vs Trivy

cdxgen

cdxgen är ett OWASP CycloneDX-projekt som skapar CycloneDX-BOM:er från källkod och containeravbilder, under Apache-2.0. Bäst för team som standardiserat på CycloneDX och vill ha en generator från formatets egen community. Se upp: som de andra skannrarna kan den bara rapportera vad filerna den har framför sig deklarerar. CRACI vs en egenbyggd SBOM-stack

Microsoft SBOM Tool

Microsoft SBOM Tool är en MIT-licensierad generator som skriver SPDX 2.2, eller SPDX 3.0 på begäran, och kan validera en SBOM mot SPDX-specifikationen. Den förväntar sig en build drop-mapp, ett paketnamn, en version och en leverantör på kommandoraden, vilket gör den till ett steg efter bygget, och den körs i GitHub Actions och Azure Pipelines. Bäst för team som vill ha SPDX för ett byggresultat de redan paketerar. Se upp: pekad mot repon som de är incheckade, snarare än mot en build drop, har den nästan inget att beskriva. Eftersom den tar en leverantör på kommandoraden kan den fylla i leverantörsfältet. CRACI vs en egenbyggd SBOM-stack

GitHubs export av beroendegrafen

GitHubs beroendegraf sammanfattar ett repos manifest och lockfiler, plus allt som skickas via dependency submission API, och exporteras som SPDX från gränssnittet eller REST API:t. Den matar Dependabot-varningar och ingår i alla GitHub-planer. Bäst för team som redan är på GitHub och behöver en snabb SBOM. Se upp: den speglar standardgrenen snarare än en låst commit, och den byggs utifrån vad GitHub vet om repot snarare än från filer som en skanner läser. CRACI vs GitHub Advanced Security

Amazon Inspector SBOM Generator

Sbomgen är generatorn bakom Amazon Inspectors egen skanning av avbilder, Lambda och EC2, och erbjuds som en fristående Linux-binär. Den läser paketmetadata från containeravbilder, kataloger, arkiv, monterade volymer och kompilerade Go- och Rust-binärer, täcker OS-paket (APK, DPKG, RPM) och språk som C#, Go, Java, Node.js, PHP, Python, Ruby och Rust, och skriver CycloneDX. Den kan skicka SBOM:en till Amazon Inspector Scan API för sårbarhetsfynd, vilket kräver ett AWS-konto. Bäst för team vars arbetslaster redan körs på AWS. Se upp: den körs bara på Linux, och som de andra skannrarna hittar den vad filerna den läser deklarerar.

Safeguard

Safeguards CLI kör Syft och Grype för att ta fram SBOM:er i CycloneDX och SPDX från repon, containeravbilder och uppladdade manifest, och dess plattform lägger till AI-skrivna pull requests med åtgärder och policykontroller. Bäst för team som vill ha skanning och automatiska åtgärder i ett abonnemang. Se upp: som de andra skannrarna listar den vad filerna den läser deklarerar. CRACI vs Safeguard

Vad en skannad SBOM beror på

Peka generatorerna ovan mot samma repo så returnerar de olika listor. Det här är de mönster som verktygens egen dokumentation förutsäger:

• Verktygen är oense om vad som räknas som en komponent. Varje generator avgör själv vilka filer den ska lita på och hur det den hittar ska namnges, så ett och samma repo ger var och en av dem en annan lista.
• Ingen lockfile, inga beroenden. Express 5.2.1 checkar inte in någon, så en generator som löser beroenden från lockfiler rapporterar inga av dess npm-beroenden och returnerar det annat den känner igen.
• Inget manifest alls. Repot claude-code har inget manifest eller lockfile, så det varje verktyg returnerar sätts ihop från andra filtyper och säger mer om verktyget än om projektet.
• Tunn metadata. Leverantörsfältet blir ofta tomt, eftersom de flesta generatorer inte har någon källa för det.

Inget av de här verktygen är trasigt. Vart och ett läser filerna det har framför sig, som det är tänkt. Lärdomen är att en skannad SBOM beror på verktyget, dess inställningar och om någon installerade beroenden först. För vad Syft, Trivy och cdxgen läser, se vad SBOM-generatorer med öppen källkod missar.

SBOM-hanteringsverktyg

Anchore Enterprise

Anchore Enterprise bygger på Syft och Grype och lägger till det stora organisationer behöver: SBOM:er för containrar, källkod och filsystem, importerade SBOM:er som valideras för schemakorrekthet, löpande omskanning utan den ursprungliga artefakten och policypaket för FedRAMP, NIST, CIS, PCI DSS och CMMC. Det driftsätts på Kubernetes, Docker Compose eller air-gapped. Bäst för containerflottor över flera CI-system och för myndighetsarbete. Se upp: dess SBOM:er beskriver ändå vad en skanner hittade, och prissättningen sker via offert. CRACI vs Anchore

FOSSA

FOSSA började med licensefterlevnad: licensdetektering i fulltext, policyer och attributionsmeddelanden. Det genererar och importerar SBOM:er i SPDX och CycloneDX, kan lägga till VDR- eller VEX-uttalanden, kontrollerar importer mot NTIA:s och FDA:s minimielement och delar SBOM:er via en portal på Enterprise. Free-planen omfattar 5 projekt. Bäst för team vars främsta oro är licensrisk. Se upp: dess CLI frågar dina byggverktyg när ett fungerande bygge finns tillgängligt och drar slutsatser från källkoden när det inte gör det, och binär- och snippet-skanning är tillägg. CRACI vs FOSSA

Cybeats SBOM Studio

SBOM Studio kallar sig "the SBOM system of record." Det importerar och exporterar SPDX 2.2 till 3.0.1 och CycloneDX 1.2 till 1.7, poängsätter SBOM-kvalitet före import, matchar varje komponent löpande och delar SBOM- och VEX-data med kunder, även via Transparency Exchange API. Bäst för produktsäkerhetsteam inom ICS, medicintekniska produkter, telekom och fordonsindustri som driver ett SBOM-program. Se upp: det hanterar SBOM:er snarare än tar fram dem, och en kvalitetspoäng bekräftar formatet, inte vad generatorn missade. CRACI vs Cybeats och Alternativ till Cybeats

Manifest

Manifest samlar in, berikar och delar SBOM:er över dina produkter, dina leverantörer och dina AI-modeller. Leverantörer laddar upp via en säker portal, och när de inte lämnar någon kan Manifest analysera binären och generera en. Det har stöd för SPDX, CycloneDX och VEX och mappar mot FDA:s vägledning, NIST 800-218 och UNECE R155. Bäst för organisationer vars främsta exponering är programvara de köper. Se upp: dess GitHub Action genererar förstaparts-SBOM:er med Syft som standard. CRACI vs Manifest

OWASP Dependency-Track

Dependency-Track är en plattform under Apache 2.0 som spårar komponenter över varje version av varje applikation, hämtar sårbarhetsdata från källor som NVD och GitHub Advisories, tillämpar policyer för säkerhet, licenser och drift, och både konsumerar och producerar CycloneDX VEX. Pipelines laddar upp SBOM:er via dess API. Bäst för team som vill ha en transparent, självhostad analysplattform. Se upp: den genererar inte SBOM:er, och du driver den själv (API-servern behöver minst 2 GB RAM och 2 CPU-kärnor). CRACI för Dependency-Track-användare

CycloneDX eller SPDX

Båda formaten är öppna standarder, och de flesta verktyg på den här sidan skriver minst ett av dem. CycloneDX är ett OWASP-projekt, standardiserat av Ecma International som ECMA-424, och bär sårbarhets- och VEX-data tillsammans med komponentlistan. SPDX är ett Linux Foundation-projekt och en internationell standard, ISO/IEC 5962:2021. Cyber Resilience Act kräver "a commonly used and machine-readable format" utan att nämna något, så välj det format som dina kunder och nedströmsverktyg läser. Se SBOM-exempel för båda sida vid sida, och bästa praxis för SBOM:er för hur du kör dem. För att lagra och bevaka SBOM:er i stor skala, se SBOM-hantering.

Där CRACI passar in

CRACI är varken en skanner eller ett hanteringsverktyg. Det registrerar. Dina GitHub Actions-jobb körs på CRACI-runners (ändra runs-on till craci), och en paketmedveten proxy registrerar vad varje jobb hämtar från npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar. Paket som återställs från en CI-cache tar med sig sina bevis. SBOM:en, i CycloneDX eller SPDX, inkluderar de transitiva beroenden som bygget använde, och anger sin fullständighet per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. CRACI:s inventeringsvy visar exakt vilka programvaruversioner som är driftsatta i vilka produkter, globalt.

Efter bygget fortsätter CRACI att omvärdera bevakade SBOM:er, sammanställer sårbarheter över byggen och repon, har stöd för VEX, returnerar SBOM:er, nätverksspårningar och proveniens via sitt API och exporterar SBOM:er som CycloneDX- eller SPDX-filer. Leverantörers SBOM:er kan läggas till, så att inköpta komponenter bevakas tillsammans med dina egna byggen. CRACI automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som företag behöver för sitt bredare arbete med CRA-efterlevnad. Se SBOM-generering i CRACI för hela funktionen.

CRACI gör alltså både en generators och ett hanteringsverktygs jobb, för programvaran du bygger. Det är inte rätt val när:

• du behöver SBOM:er för avbilder eller programvara du inte har byggt (använd en generator som Syft eller Trivy),
• du behöver en mogen policymotor med många regeltyper över en portfölj av produkter och leverantörer (använd ett hanteringsverktyg),
• dina pipelines körs utanför GitHub Actions, på Windows eller macOS, eller måste vara självhostade (allt finns på CRACI:s roadmap).

Det snabbaste sättet att avgöra är sida vid sida: boka en demo, kör ett av dina arbetsflöden på CRACI och ställ dess SBOM bredvid den som ditt nuvarande verktyg tar fram.

Se även SCA-verktyg i jämförelse, AI-genererade SBOM:er vs SBOM:er från bygget och varför SBOM:er från bygget skiljer sig från skannade.

SBOM-verktyg: vanliga frågor

Vad är ett SBOM-verktyg?

Ett SBOM-verktyg tar fram eller hanterar en software bill of materials: en maskinläsbar lista över komponenterna, biblioteken och beroendena i en programvara. Generatorer som Syft, Trivy och cdxgen skriver SBOM:en genom att läsa filer. Hanteringsverktyg som Dependency-Track, FOSSA och Anchore Enterprise lagrar SBOM:er, matchar dem mot sårbarhetsdata och delar dem. CRACI registrerar SBOM:en under själva bygget och bevakar den efteråt.

Vilket är det bästa gratis SBOM-verktyget?

Det beror på vad du pekar det mot. Syft och Trivy är gratis generatorer under Apache-2.0 för containeravbilder och filsystem. cdxgen skriver CycloneDX från källkod och avbilder. Microsoft SBOM Tool skriver SPDX för en mapp med byggresultat. OWASP Dependency-Track är ett gratis, självhostat hanteringsverktyg för de SBOM:er som dessa verktyg tar fram.

Ska jag använda Syft eller Trivy?

Syft är inriktat på SBOM-generering och fungerar ihop med Grype för sårbarhetsmatchning. Trivy är en bredare skanner som också hittar felkonfigurationer i IaC, hemligheter och licenser, och skriver CycloneDX eller SPDX på vägen. Båda läser filerna de har framför sig, så båda är beroende av att lockfiler eller installerade paket finns på plats.

CycloneDX eller SPDX: vilket SBOM-format ska jag använda?

Båda är öppna, brett stödda standarder. CycloneDX är ett OWASP-projekt, standardiserat av Ecma International som ECMA-424, och bär också sårbarhets- och VEX-data. SPDX är ett Linux Foundation-projekt och en internationell standard, ISO/IEC 5962:2021. Använd den som dina kunder och nedströmsverktyg frågar efter; de flesta generatorer skriver båda.

Varför ger SBOM-verktyg olika resultat för samma projekt?

Varje generator avgör vilka filer den ska lita på och vad som räknas som en komponent. Vissa läser lockfiler, vissa läser installerade paket, vissa läser binärer, och ett repo utan lockfile ger en lockfile-läsare inget att arbeta med. En skannad SBOM beror på verktyget, dess inställningar och om beroenden installerades före skanningen. En SBOM från bygget undviker det genom att registrera vad bygget faktiskt hämtade.

Kräver Cyber Resilience Act ett särskilt SBOM-verktyg eller format?

Nej. Bilaga I, del II i CRA kräver att tillverkare tar fram en software bill of materials i ett allmänt använt och maskinläsbart format som åtminstone omfattar produkternas beroenden på toppnivå. CycloneDX och SPDX uppfyller båda det. Förordningen nämner inget verktyg.

Kan CRACI generera en SBOM för programvara jag inte har byggt?

Nej. CRACI registrerar de byggen som körs på dess runners, så dess SBOM:er beskriver programvara som du bygger. För programvara du köper kan du lägga till leverantörens SBOM i CRACI och bevaka den tillsammans med dina egna byggen. För en tredjeparts containeravbild som du inte har byggt är en skanner som Syft eller Trivy det praktiska valet.

Vilka CI-system har CRACI stöd för?

GitHub Actions i dag, på Linux-runners för x86-64 och ARM64. Du ändrar runs-on till craci och körningarna syns fortfarande i GitHub. Andra CI-system, med GitLab CI och Jenkins först, finns på roadmapen.