Vad SBOM-generatorer med öppen källkod missar

Så genererar du en SBOM med varje verktyg

Varje verktyg kräver ett enda kommando för en källkodskatalog eller en containeravbild, 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 .

Kommandona är den enkla delen. Vad som hamnar i filen beror på vad varje verktyg läser, och de läser inte samma saker.

Vad varje verktyg läser

Verktyg	Källkodskatalog	Containeravbild	Bra att veta
Syft	En standarduppsättning katalogiserare för kataloger, som läser deklarerade beroenden	En standarduppsättning katalogiserare för avbilder, som läser installerade paket	Katalogiserare väljs efter skanningstyp. syft cataloger list visar vilka som körs, och --select-catalogers lägger till eller tar bort dem.
Trivy	Lockfiler, för Node.js package-lock.json, yarn.lock, pnpm-lock.yaml och bun.lock	För Node.js, package.json-filer under node_modules	Utelämnar utvecklingsberoenden om du inte anger --include-dev-deps.
cdxgen	Lockfiler i första hand, vilka inkluderar utvecklingsberoenden; för Node.js tolkar det också koden för att hitta importer	Stöds	Ange projekttypen med -t för att begränsa vad det letar efter.

Varför de är oense om samma repo

Peka alla tre mot samma commit så får du tre olika listor. Inget av verktygen är trasigt. Vart och ett följer sina egna dokumenterade regler:

• Ingen lockfile, inga beroenden. Express 5.2.1 checkar inte in någon lockfile. I en ren utcheckning har ett verktyg som löser beroenden från lockfiler eller installerade paket varken eller, så npm-beroendena som deklareras i package.json når aldrig SBOM:en. Det skriver ändå ett giltigt dokument med allt annat det kände igen.
• Installerat eller deklarerat. Om du körde en installation före skanningen kan spela större roll än vilket verktyg du använder. På en installerad kopia av samma repo avgör en enda inställning för en katalogiserare i Syft om de installerade npm-paketen över huvud taget visas.
• Utvecklingsberoenden. Trivy utelämnar dem som standard och cdxgen tar med dem, så samma lockfile ger två svar på frågan ”vad finns i det här projektet”.
• Namn och versioner. Verktyg identifierar vissa komponenter under olika typer av package URL, eller låser en GitHub Action till en commit-SHA där ett annat rapporterar en tagg. En sårbarhetsuppslagning som bygger på fel identifierare ger ett självsäkert felaktigt svar.
• Inget manifest alls. Repot anthropics/claude-code har inget beroendemanifest, och dess npm-paket omsluter en förbyggd binär. Det varje verktyg returnerar säger mer om verktyget än om projektet.

Vad alla missar: dolda beroenden

Den djupare begränsningen är gemensam. En skanner läser lockfilen eller byggets resultat och räknar utifrån det ut vad som ingick, i efterhand. Det som bygget hämtade utanför de filerna når aldrig SBOM:en. Det är de dolda beroendena:

• Installationshookar. npm-skripten preinstall och postinstall körs under installationen och kan ladda ner mer kod. Det var så Shai-Hulud-masken kördes.
• Byggskript, till exempel byggskript i Rust som laddar ner det de behöver under bygget.
• Basavbilder och deras operativsystemslager i ett containerbygge, som ingen språkspecifik lockfile listar.
• Paket som återställs från CI-cachar, som kanske inte stämmer med den aktuella lockfilen. Se vad GitHub Actions-cachen döljer.
• Byggverktyg som installeras av setup-steg, med egna beroendeträd.
• Transitiva versioner som löses under bygget när lockfilen saknas, är inaktuell eller inte används av en frusen installation. Se transitiva beroenden.

Att skanna resultatet i efterhand täpper inte till luckan. En färdig binär, särskilt kompilerad kod som Rust, tvingar skannern att gissa vad som ingick. Kommersiella SCA-skannrar arbetar utifrån samma slags filer och delar samma blinda fläckar. CRACI har hittat sårbara paket som Snyk och Aikido inte rapporterade, eftersom komponenterna aldrig fanns i det de skannade.

Verktygen är också en del av din leveranskedja

En skanner körs i din CI med åtkomst till din kod och ofta dina hemligheter. I mars 2026 beskrev Aqua Securitys säkerhetsmeddelande (CVE-2026-33634) en skadlig release av Trivy v0.69.4 och förgiftade taggar för trivy-action och setup-trivy som stal inloggningsuppgifter från CI-runners. Lås skanner-actions till fullständiga commit-SHA:er och kontrollera säkerhetsmeddelandet för de versioner du kör.

Så kontrollerar du din egen SBOM

1. Kör två generatorer på samma commit och jämför package URL:erna de rapporterar.
2. Kontrollera om repot checkar in en lockfile, och om CI installerar från den med en frusen installation.
3. Skanna efter installationssteget såväl som före det, och jämför.
4. Jämför listan med det som din bygglogg visar laddas ner, inklusive setup-steg och cacheåterställningar.

Om listorna skiljer sig åt beror SBOM:en du publicerar på vilket verktyg du råkade köra, inte på vad du levererade.

Registrera bygget i stället

CRACI ser trafiken; det gör inte skannrar. Det är en GitHub Actions-runner som ser nätverkstrafiken som kommer in i varje bygge, så dess SBOM registrerar varje paket som jobbet drog in, i alla led av trädet, inklusive de dolda beroendena och paket som återställs från CI-cachar. Det finns ingen katalog att peka på och ingen katalogiserare att välja. När en registrering inte kunde se allt, till exempel för att ett jobb tillät obevakad trafik, säger SBOM:en det med sin fullständighetsstatus.

Registrering spelar också roll eftersom byggen sällan är reproducerbara. Bygg samma commit två gånger i rad, och pakethanteraren kan lösa och installera i en annan ordning, så att det andra bygget kan innehålla andra paket. Bara SBOM:en som registrerades under bygget som producerade en release bevisar vad den releasen innehåller.

Behåll Syft eller Trivy för tredjepartsavbilder och binärer som du inte har byggt. För dina egna releaser, se SBOM:er från bygget eller boka en demo för att jämföra en registrerad SBOM med ditt nuvarande verktygs på ett av dina repon.

SBOM-generatorer med öppen källkod: vanliga frågor

Vilket är bäst för SBOM:er, Syft eller Trivy?

De är byggda för olika uppgifter. Syft är en dedikerad SBOM-generator med många katalogiserare och signerade attesteringar; Trivy är en säkerhetsskanner som skriver SBOM:er som ett av sina utdataformat. Båda läser filerna framför dem, så på samma repo är den större skillnaden oftast om en lockfile är incheckad och om beroenden installerades före skanningen.

Varför visar min SBOM inga beroenden?

Oftast för att repot inte har någon incheckad lockfile och inget installerades före skanningen. En generator som läser lockfiler eller installerade paket har då inget att läsa, och den skriver ändå en giltig SBOM. Checka in lockfilen, eller skanna efter installationssteget.

Tar Trivy med utvecklingsberoenden i SBOM:en?

Inte som standard. Trivys dokumentation för Node.js säger att verktyget inte rapporterar utvecklingsberoenden om du inte anger --include-dev-deps. cdxgen tolkar däremot lockfiler och tar med utvecklingsberoenden. Två verktyg kan vara oense om samma projekt bara av det skälet.

Kan jag lita på en SBOM från en generator med öppen källkod?

För det den läste, ja. Frågan är vad den inte läste: cachar, byggverktyg, nedladdningar, installationsskript och binärer utan paketmetadata. Behandla en skannad SBOM som en beskrivning av filerna du pekade verktyget mot, inte av bygget som skapade din release.

Vilket är det bästa SBOM-verktyget?

För programvara du bygger själv kommer den mest kompletta SBOM:en från att registrera bygget i stället för att skanna filer. CRACI registrerar varje paket som varje GitHub Actions-jobb hämtar, även från cachar, och har hittat sårbara paket som Snyk och Aikido inte rapporterade. För tredjepartsavbilder och binärer som du inte har byggt är en skanner som Syft eller Trivy fortfarande det praktiska valet.