Du scanner allerede dine afhængigheder. Her er, hvad en scanner ikke kan se.

Det, din nuværende stak gør godt

Har du SCA og SBOM-generering sat op, har du allerede gjort det svære organisatoriske arbejde: Afhængigheder spores, advisories når ud til udviklerne, og der er en fil at aflevere, når nogen spørger. Behold det.

• GitHubs afhængighedsgraf og Dependabot er slået til som standard for mange teams. GitHub beskriver afhængighedsgrafen 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-alarmer bygger på den og giver dig besked, når en ny advisory offentliggøres, eller når din afhængighedsgraf ændrer sig.
• Kommerciel SCA som Snyk genererer også SBOM'er. Kommandoen snyk sbom læser manifestfiler og deres lockfiles og udsender CycloneDX eller SPDX. Pr. september 2026 dokumenterer Snyk den som "available only to customers on Snyk Enterprise plans."
• Open source-generatorer som Syft, Trivy og cdxgen er gratis, hurtige og nemme at føje til CI. Syft beskriver sig selv som et værktøj "for generating a Software Bill of Materials (SBOM) from container images and filesystems."

Disse værktøjer er stærkest til hurtig feedback på en pull request, bred dækning af økosystemer og et afhjælpningsworkflow, udviklerne allerede kender. Det erstatter CRACI ikke i dag. Dets sårbarhedssporing samler fund på tværs af builds og repositories og genvurderer overvågede SBOM'er, når nye sårbarheder dukker op. Sikkerhedsteams kan triagere fund og sende dem til det rigtige team. Policy gates kan blokere et build; sårbarheds-webhooks er på roadmappen.

Scanner kontra registrator

Alle værktøjerne ovenfor er scannere. Du peger dem på et kildetræ, en lockfile eller et container-image, og de udleder, hvad der gik ind. Det virker, når filerne fortæller hele historien. Det bliver sværere, når de ikke gør det:

• Repositoriet har ingen lockfile, så versioner afgøres ved installationen.
• Buildet gendanner pakker fra en CI-cache, som intet manifest nævner.
• Et build-trin downloader et værktøj, en OS-pakke eller en binærfil direkte.
• Et npm install-hook eller et Rust-build-script henter mere kode under installationen, den vej, Shai-Hulud-ormen brugte.
• Et container-build henter et base-image og dets styresystemlag, som ingen sprogspecifik lockfile angiver.
• Det, du leverer, er en kompileret binærfil, og manifestet ved siden af den angiver næsten ingenting.

CRACI er en registrator: Det ser trafikken, og det gør scannere ikke. Det kører buildet på sin egen GitHub Actions-kompatible runner, og en pakkebevidst proxy observerer trafikken til pakkekilder, mens jobbet kører, så disse skjulte afhængigheder havner i SBOM'en. Pakker gendannet fra en cache fører deres dokumentation med sig. Der findes ingen craci scan ./dir-kommando, fordi det at scanne en mappe bagefter er det trin, CRACI findes for at undgå.

Hvad en scanning afhænger af

Scanneroutput afhænger af værktøjet og af, hvad det peges på. Syft, Trivy, cdxgen, Microsoft SBOM Tool, eksporten af GitHubs afhængighedsgraf og Socket CLI finder hver især frem til listen ud fra det, de kan læse. Mønstrene nedenfor bygger på, hvordan disse værktøjer ifølge deres dokumentation virker.

Ingen komponent findes af alle værktøjer

Hver generator afgør selv, hvad der tæller som en komponent, og hvilke filer den stoler på, så det samme checkout giver dem hver en forskellig liste. Eksporten af GitHubs afhængighedsgraf virker igen anderledes: Den bygger på det, GitHub ved om repositoriet, snarere end på filer, en scanner læser, og den læser default-branchen snarere end et fastlåst commit.

Ingen lockfile, ingen afhængigheder

Express 5.2.1 committer ingen lockfile. Sættes en generator, der resolver afhængigheder ud fra lockfiles eller et installeret træ, til at scanne et rent checkout, har den ingen af delene foran sig, så ingen af de npm-afhængigheder, der er deklareret i package.json, når frem til dokumentet. Intet værktøj her er i stykker. Det, der afgør, om SBOM'en overhovedet indeholder afhængigheder, er ikke værktøjet. Det er, om nogen kørte en installation først.

Ét flag ændrer svaret

Syfts standardscanning af mapper rapporterer, hvad et projekt deklarerer, ikke hvad der er installeret på disken. På et installeret checkout af samme express-release afgør ét cataloger-flag, om de installerede npm-pakker overhovedet optræder på listen. Samme værktøj, samme version, samme træ.

Produktet er en binærfil

Repositoriet anthropics/claude-code ved v2.1.259 har hverken afhængighedsmanifest eller lockfile af nogen art. Dets udgivne npm-pakke deklarerer nul runtime-afhængigheder og pakker en forudbygget native binærfil ind via otte platformpakker. @openai/codex 0.149.1 er opbygget på samme måde. En manifestlæser har næsten intet at beskrive, mens det program, der kører, er en kompileret binærfil, så det, hvert værktøj returnerer, siger mere om værktøjet end om projektet.

Samme pakke, forskellige versioner

Hvor to værktøjer finder det samme, er de ikke altid enige om, hvad det er. Ét kan fastlåse en GitHub Action på en commit-SHA, mens et andet rapporterer et release-tag. Et sårbarhedsopslag på den forkerte version giver et selvsikkert forkert svar.

Hvor CRACI passer ind ved siden af din SCA

Behold din SCA på pull requests. Det er det rigtige sted at fange en sårbar version, før den bliver merget. Tilføj CRACI, hvor spørgsmålet handler om buildet snarere end diffen:

• Hvad indeholdt denne release faktisk? Den registrerede SBOM dækker npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets, inklusive transitive afhængigheder. JFrog Artifactory-mirrors til npm og PyPI virker også.
• Kan vi stole på listen? Hvert job og hver cache har en fuldstændighedsstatus, så en ufuldstændig registrering er synlig i stedet for ubemærket at være for tynd.
• Er vi ramt af en ny advisory? Overvågede SBOM'er genvurderes, når nye sårbarheder offentliggøres, og fund samles på tværs af builds og repositories.

SBOM'en downloades som CycloneDX via det offentlige REST API sammen med jobbets netværkstrace og provenance, så den kan sendes videre til ethvert værktøj, der læser CycloneDX, inklusive den SCA, du allerede kører. Opsætningen er én linje i workflowet: Ændr runs-on til craci. GitHub Actions er det understøttede CI i dag; GitLab CI, Jenkins og andre CI-systemer er på roadmappen.

Et overblik over, hvad der er udrullet hvor

CRACI's inventaroversigt viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter, globalt. Når en ny sårbarhed dukker op, kan du se, hvilke produkter der kører den berørte version, i stedet for at stykke det sammen fra release notes og regneark.

Læs mere om SBOM-generering under buildet og sårbarhedssporing.