Du skannar redan dina beroenden. Här är vad en skanner inte kan se.

Det din nuvarande stack gör bra

Om du har SCA och SBOM-generering konfigurerade har du redan gjort det svåra organisatoriska arbetet: beroenden spåras, säkerhetsmeddelanden når utvecklarna och det finns en fil att lämna över när någon frågar. Behåll det.

• GitHubs beroendegraf och Dependabot är påslagna som standard för många team. GitHub beskriver beroendegrafen som en sammanfattning av manifest- och lockfilerna i ett repo och av de beroenden som skickas in för repot via dependency submission API. Dependabot-varningar bygger på den och meddelar dig när ett nytt säkerhetsmeddelande publiceras eller när din beroendegraf ändras.
• Kommersiell SCA som Snyk genererar också SBOM:er. Dess kommando snyk sbom läser manifestfiler och deras lockfiler och skriver CycloneDX eller SPDX. I september 2026 anger Snyks dokumentation att det bara är tillgängligt för kunder på Snyk Enterprise-planer.
• Generatorer med öppen källkod som Syft, Trivy och cdxgen är gratis, snabba och lätta att lägga till i CI. Syft beskriver sig som ett verktyg för att generera en Software Bill of Materials (SBOM) från containeravbilder och filsystem.

De här verktygen är starkast på snabb återkoppling på en pull request, bred täckning av ekosystem och ett åtgärdsflöde som utvecklare redan kan. CRACI ersätter inte det i dag. Dess sårbarhetsspårning samlar fynd över byggen och repon och omvärderar bevakade SBOM:er när nya sårbarheter dyker upp. Säkerhetsteam kan triagera fynd och skicka dem till rätt team. Policyspärrar kan blockera ett bygge; webhooks för sårbarheter finns på roadmapen.

Skanner kontra registrering

Alla verktygen ovan är skannrar. Du pekar dem mot ett källkodsträd, en lockfile eller en containeravbild, och de räknar ut vad som ingick. Det fungerar när filerna berättar hela historien. Det blir svårare när de inte gör det:

• Repot har ingen lockfile, så versionerna avgörs vid installationen.
• Bygget återställer paket från en CI-cache som inget manifest nämner.
• Ett byggsteg laddar ner ett verktyg, ett OS-paket eller en binär direkt.
• En npm-installationshook eller ett byggskript i Rust hämtar mer kod under installationen, den väg som Shai-Hulud-masken använde.
• Ett containerbygge hämtar en basavbild och dess operativsystemlager, som ingen lockfile för ett språk listar.
• Det du levererar är en kompilerad binär, och manifestet bredvid den listar nästan ingenting.

CRACI registrerar: det ser trafiken, och det gör inte skannrar. Det kör bygget på sin egen runner som är kompatibel med GitHub Actions, och en paketmedveten proxy observerar trafiken till paketkällor medan jobbet körs, så dessa dolda beroenden hamnar i SBOM:en. Paket som återställs från en cache tar med sig sina bevis. Det finns inget kommando craci scan ./dir, eftersom skanning av en katalog i efterhand är det steg som CRACI finns till för att undvika.

Vad en skanning beror på

Vad en skanner ger beror på verktyget och på vad det pekas mot. Syft, Trivy, cdxgen, Microsoft SBOM Tool, GitHubs export av beroendegrafen och Socket CLI räknar alla ut listan utifrån det de kan läsa. Mönstren nedan kommer från hur de här verktygen fungerar enligt sin dokumentation.

Ingen komponent hittas av alla verktyg

Varje generator avgör själv vad som räknas som en komponent och vilka filer den ska lita på, så samma utcheckning ger var och en av dem en annan lista. GitHubs export av beroendegrafen fungerar annorlunda igen: den bygger på vad GitHub vet om repot snarare än på filer som en skanner läser, och den läser standardgrenen snarare än en låst commit.

Ingen lockfile, inga beroenden

Express 5.2.1 har ingen lockfile i repot. Pekad mot en ren utcheckning har en generator som löser beroenden från lockfiler eller ett installerat träd inget av dem framför sig, så inget av npm-beroendena som deklareras i package.json når dokumentet. Inget verktyg här är trasigt. Det som avgör om SBOM:en innehåller några beroenden alls är inte verktyget. Det är om någon först körde en installation.

En flagga ändrar svaret

Syfts standardskanning av en katalog rapporterar vad ett projekt deklarerar, inte vad som är installerat på disk. På en installerad utcheckning av samma express-release avgör en cataloger-flagga om de installerade npm-paketen alls syns i listan. Samma verktyg, samma version, samma träd.

Produkten är en binär

Repot anthropics/claude-code vid v2.1.259 har inget beroendemanifest eller någon lockfile av något slag. Dess publicerade npm-paket deklarerar noll runtime-beroenden och paketerar en förbyggd native-binär genom åtta plattformspaket. @openai/codex 0.149.1 har samma upplägg. En manifestläsare har nästan ingenting att beskriva, medan programmet som körs är en kompilerad binär, så det varje verktyg returnerar säger mer om verktyget än om projektet.

Samma paket, olika versioner

När två verktyg faktiskt hittar samma sak är de inte alltid överens om vad det är. Ett kan låsa en GitHub Action till en commit-SHA medan ett annat rapporterar en release-tagg. En sårbarhetsuppslagning på fel version ger ett självsäkert felaktigt svar.

Där CRACI passar in bredvid din SCA

Behåll din SCA på pull requests. Det är rätt ställe att fånga en sårbar version innan den mergas. Lägg till CRACI där frågan gäller bygget snarare än diffen:

• Vad innehöll den här releasen egentligen? Den registrerade SBOM:en täcker npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar, inklusive transitiva beroenden. JFrog Artifactory-speglar för npm och PyPI fungerar också.
• Kan vi lita på listan? Varje jobb och cache har en fullständighetsstatus, så en ofullständig registrering är synlig i stället för att i det tysta vara bristfällig.
• Berörs vi av ett nytt säkerhetsmeddelande? Bevakade SBOM:er omvärderas när nya sårbarheter publiceras, och fynd samlas över byggen och repon.

SBOM:en laddas ner som CycloneDX via det publika REST-API:t, tillsammans med jobbets nätverksspårning och proveniens, så den kan mata alla verktyg som läser CycloneDX, inklusive den SCA du redan kör. Installationen är en rad i arbetsflödet: ändra runs-on till craci. GitHub Actions är det CI-system som stöds i dag; GitLab CI, Jenkins och andra CI-system finns på roadmapen.

En inventering av vad som är driftsatt var

CRACI:s inventeringsvy visar exakt vilka programvaruversioner som är driftsatta i vilka produkter, globalt. När en ny sårbarhet dyker upp kan du se vilka produkter som kör den berörda versionen i stället för att pussla ihop det från release notes och kalkylblad.

Läs mer om SBOM-generering under bygget och sårbarhetsspårning.