Du skanner allerede avhengighetene dine. Dette kan ikke en skanner se.

Det den nåværende stacken din gjør bra

Hvis du har SCA og SBOM-generering konfigurert, har du allerede gjort det vanskelige organisatoriske arbeidet: Avhengigheter spores, advisories når utviklerne, og det finnes en fil å levere fra seg når noen spør. Behold det.

• GitHubs avhengighetsgraf og Dependabot er slått på som standard for mange team. GitHub beskriver avhengighetsgrafen som "a summary of the manifest and lock files stored in a repository and any dependencies that are submitted for the repository using the dependency submission API." Dependabot-varsler bygger på den og varsler deg når en ny advisory publiseres eller når avhengighetsgrafen din endres.
• Kommersiell SCA som Snyk genererer også SBOM-er. Kommandoen snyk sbom leser manifestfiler og tilhørende lockfiler, og skriver ut CycloneDX eller SPDX. Per september 2026 dokumenterer Snyk den som "available only to customers on Snyk Enterprise plans."
• Generatorer med åpen kildekode som Syft, Trivy og cdxgen er gratis, raske og enkle å legge til i CI. Syft beskriver seg selv som et verktøy "for generating a Software Bill of Materials (SBOM) from container images and filesystems."

Disse verktøyene er sterkest på rask tilbakemelding på en pull request, bred dekning av økosystemer og en utbedringsflyt utviklere allerede kjenner. CRACI erstatter ikke det i dag. Sårbarhetssporingen samler funn på tvers av bygg og repositorier og vurderer overvåkede SBOM-er på nytt når nye sårbarheter dukker opp. Sikkerhetsteam kan triagere funn og sende dem til riktig team. Policy gates kan blokkere et bygg; sårbarhets-webhooks står på veikartet.

Skanner kontra registrerer

Alle verktøyene over er skannere. Du peker dem mot et kildetre, en lockfile eller et container-image, og de utleder hva som gikk inn. Det fungerer når filene forteller hele historien. Det blir vanskeligere når de ikke gjør det:

• Repositoriet har ingen lockfile, så versjonene avgjøres ved installasjon.
• Bygget gjenoppretter pakker fra en CI-cache som ingen manifest nevner.
• Et byggesteg laster ned et verktøy, en OS-pakke eller en binærfil direkte.
• En npm-installasjonshook eller et Rust-byggeskript henter mer kode under installasjonen, ruten Shai-Hulud-ormen brukte.
• Et containerbygg henter et base-image og operativsystemlagene, som ingen språk-lockfile lister opp.
• Det du leverer, er en kompilert binærfil, og manifestet ved siden av den lister nesten ingenting.

CRACI er en registrerer: Det ser trafikken, og det gjør ikke skannere. Det kjører bygget på sin egen GitHub Actions-kompatible runner, og en pakkebevisst proxy observerer trafikken til pakkekilder mens jobben kjører, så disse skjulte avhengighetene havner i SBOM-en. Pakker gjenopprettet fra en cache tar dokumentasjonen sin med seg. Det finnes ingen craci scan ./dir-kommando, fordi skanning av en katalog i etterkant er det steget CRACI finnes for å unngå.

Hva en skanning avhenger av

Utdata fra skannere avhenger av verktøyet og av hva det pekes mot. Syft, Trivy, cdxgen, Microsoft SBOM Tool, eksporten av GitHubs avhengighetsgraf og Socket CLI finner hver for seg ut listen fra det de kan lese. Mønstrene nedenfor kommer fra hvordan disse verktøyene er dokumentert å fungere.

Ingen komponent blir funnet av alle verktøyene

Hver generator avgjør selv hva som teller som en komponent, og hvilke filer den skal stole på, så samme checkout gir hver av dem en annen liste. Eksporten av GitHubs avhengighetsgraf fungerer på enda en annen måte: Den bygges fra det GitHub vet om repositoriet, ikke fra filer en skanner leser, og den leser standardgrenen i stedet for en festet commit.

Ingen lockfile, ingen avhengigheter

Express 5.2.1 committer ingen lockfile. Pekt mot en ren checkout har en generator som løser avhengigheter fra lockfiler eller et installert avhengighetstre, ingen av delene foran seg, så ingen av npm-avhengighetene deklarert i package.json når dokumentet. Ingen av verktøyene her er ødelagt. Det som avgjør om SBOM-en inneholder noen avhengigheter i det hele tatt, er ikke verktøyet. Det er om noen kjørte en installasjon først.

Ett flagg endrer svaret

Syfts standard katalogskanning rapporterer hva et prosjekt deklarerer, ikke hva som er installert på disk. På en installert checkout av den samme express-utgivelsen avgjør ett cataloger-flagg om de installerte npm-pakkene i det hele tatt dukker opp i listen. Samme verktøy, samme versjon, samme kildetre.

Produktet er en binærfil

Repositoriet anthropics/claude-code på v2.1.259 har ikke noe avhengighetsmanifest eller lockfile av noe slag. Den publiserte npm-pakken deklarerer null runtime-avhengigheter og pakker inn en forhåndsbygd native binærfil gjennom åtte plattformpakker. @openai/codex 0.149.1 er bygget opp på samme måte. En manifestleser har nesten ingenting å beskrive, mens programmet som kjører, er en kompilert binærfil, så det hvert verktøy returnerer, sier mer om verktøyet enn om prosjektet.

Samme pakke, ulike versjoner

Der to verktøy finner det samme, er de ikke alltid enige om hva det er. Det ene kan feste en GitHub Action til en commit-SHA mens det andre rapporterer en utgivelsestag. Et sårbarhetsoppslag på feil versjon gir et selvsikkert, feil svar.

Hvor CRACI passer inn ved siden av SCA-verktøyet ditt

Behold SCA-verktøyet på pull requests. Det er det rette stedet å fange en sårbar versjon før den merges. Legg til CRACI der spørsmålet gjelder bygget og ikke diffen:

• Hva inneholdt denne utgivelsen faktisk? Den registrerte SBOM-en dekker kildene npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git, pluss forhåndsinnstillinger for nedlastinger, inkludert transitive avhengigheter. JFrog Artifactory-speil for npm og PyPI fungerer også.
• Kan vi stole på listen? Hver jobb og cache har en fullstendighetsstatus, så en ufullstendig registrering er synlig i stedet for å være tynn uten at noen merker det.
• Er vi berørt av en ny advisory? Overvåkede SBOM-er vurderes på nytt når nye sårbarheter publiseres, og funn samles på tvers av bygg og repositorier.

SBOM-en lastes ned som CycloneDX gjennom det offentlige REST API-et, sammen med jobbens nettverksspor og provenance, så den kan mate ethvert verktøy som leser CycloneDX, inkludert SCA-verktøyet du allerede kjører. Oppsettet er én linje i workflowen: Endre runs-on til craci. GitHub Actions er den støttede CI-en i dag; GitLab CI, Jenkins og andre CI-systemer står på veikartet.

En oversikt over hva som er rullet ut hvor

Inventarvisningen i CRACI viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter, globalt. Når en ny sårbarhet dukker opp, kan du se hvilke produkter som kjører den berørte versjonen, i stedet for å pusle det sammen fra utgivelsesnotater og regneark.

Les mer om SBOM-generering under bygget og sårbarhetssporing.