U scant uw afhankelijkheden al. Dit is wat een scanner niet kan zien.

Wat uw huidige stack goed doet

Hebt u SCA en SBOM-generatie geconfigureerd, dan hebt u het moeilijke organisatorische werk al gedaan: afhankelijkheden worden gevolgd, advisories bereiken ontwikkelaars, en er is een bestand om te overhandigen als iemand erom vraagt. Houd dat zo.

• De dependency graph en Dependabot van GitHub staan bij veel teams standaard aan. GitHub beschrijft de dependency graph als "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-meldingen bouwen daarop voort en waarschuwen u wanneer een nieuwe advisory wordt gepubliceerd of wanneer uw dependency graph verandert.
• Commerciële SCA zoals Snyk genereert ook SBOM's. De opdracht snyk sbom leest manifestbestanden en hun lockfiles, en levert CycloneDX of SPDX. Per september 2026 documenteert Snyk dit als "available only to customers on Snyk Enterprise plans."
• Open-sourcegeneratoren zoals Syft, Trivy en cdxgen zijn gratis, snel en eenvoudig aan CI toe te voegen. Syft omschrijft zichzelf als een tool "for generating a Software Bill of Materials (SBOM) from container images and filesystems."

Deze tools zijn het sterkst in snelle feedback op een pull request, brede ecosysteemdekking en een remediatieworkflow die ontwikkelaars al kennen. CRACI vervangt dat vandaag niet. De kwetsbaarheidstracking bundelt bevindingen over builds en repositories heen en beoordeelt gemonitorde SBOM's opnieuw wanneer nieuwe kwetsbaarheden verschijnen. Securityteams kunnen bevindingen triëren en naar het juiste team sturen. Policy gates kunnen een build blokkeren; kwetsbaarheidswebhooks staan op de roadmap.

Scanner versus recorder

Elke tool hierboven is een scanner. U richt hem op een broncodeboom, een lockfile of een containerimage, en hij leidt af wat erin is gegaan. Dat werkt wanneer de bestanden het hele verhaal vertellen. Het wordt lastiger wanneer dat niet zo is:

• De repository heeft geen lockfile, dus versies worden bij de installatie bepaald.
• De build zet pakketten terug uit een CI-cache die in geen enkel manifest wordt genoemd.
• Een buildstap downloadt rechtstreeks een tool, een OS-pakket of een binary.
• Een npm-installatiehook of een Rust-buildscript haalt tijdens de installatie meer code op, de route die de Shai-Hulud-worm gebruikte.
• Een containerbuild haalt een base image en de lagen van het besturingssysteem op, die in geen enkele taal-lockfile staan.
• Wat u levert, is een gecompileerde binary, en het manifest ernaast vermeldt bijna niets.

CRACI is een recorder: het ziet het verkeer, en scanners niet. Het draait de build op zijn eigen runner die compatibel is met GitHub Actions, en een proxy die pakketten herkent, observeert het verkeer naar pakketbronnen terwijl de job draait, zodat deze verborgen afhankelijkheden in de SBOM terechtkomen. Pakketten die uit een cache zijn teruggezet, nemen hun bewijs mee. Er is geen opdracht craci scan ./dir, omdat het achteraf scannen van een map precies de stap is die CRACI wil vermijden.

Waar een scan van afhangt

De uitvoer van een scanner hangt af van de tool en van waarop hij wordt gericht. Syft, Trivy, cdxgen, de Microsoft SBOM Tool, de dependency graph-export van GitHub en de Socket CLI stellen de lijst elk samen uit wat ze kunnen lezen. De patronen hieronder komen uit de manier waarop deze tools volgens hun documentatie werken.

Geen enkel component wordt door elke tool gevonden

Elke generator bepaalt zelf wat als component telt en welke bestanden hij vertrouwt, dus dezelfde checkout levert elk van hen een andere lijst op. De dependency graph-export van GitHub werkt weer anders: die wordt opgebouwd uit wat GitHub over de repository weet in plaats van uit bestanden die een scanner leest, en leest de standaardbranch in plaats van een vastgepinde commit.

Geen lockfile, geen afhankelijkheden

Express 5.2.1 heeft geen gecommitte lockfile. Gericht op een schone checkout heeft een generator die afhankelijkheden oplost uit lockfiles of een geïnstalleerde boom geen van beide voor zich, dus geen van de npm-afhankelijkheden die in package.json zijn gedeclareerd, komt in het document terecht. Geen enkele tool hier is kapot. Wat bepaalt of de SBOM überhaupt afhankelijkheden bevat, is niet de tool. Het is of iemand eerst een installatie heeft gedraaid.

Eén vlag verandert het antwoord

De standaard mapscan van Syft rapporteert wat een project declareert, niet wat op schijf is geïnstalleerd. Op een geïnstalleerde checkout van dezelfde express-release bepaalt één catalogervlag of de geïnstalleerde npm-pakketten überhaupt in de lijst verschijnen. Dezelfde tool, dezelfde versie, dezelfde boom.

Het product is een binary

De repository anthropics/claude-code op v2.1.259 heeft geen enkel afhankelijkheidsmanifest of lockfile. Het gepubliceerde npm-pakket declareert nul runtime-afhankelijkheden en verpakt een vooraf gebouwde native binary via acht platformpakketten. @openai/codex 0.149.1 heeft dezelfde vorm. Een manifestlezer heeft bijna niets te beschrijven, terwijl het programma dat draait een gecompileerde binary is, dus wat elke tool teruggeeft, zegt meer over de tool dan over het project.

Hetzelfde pakket, verschillende versies

Waar twee tools hetzelfde vinden, zijn ze het niet altijd eens over wat het is. De een pint een GitHub Action misschien vast op een commit-SHA, terwijl de ander een release-tag rapporteert. Een kwetsbaarheidsopzoeking op basis van de verkeerde versie geeft een zelfverzekerd fout antwoord.

Waar CRACI past naast uw SCA

Houd uw SCA op pull requests. Dat is de juiste plek om een kwetsbare versie te vangen voordat die wordt gemerged. Voeg CRACI toe waar de vraag over de build gaat in plaats van over de diff:

• Wat zat er werkelijk in deze release? De vastgelegde SBOM dekt npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk en Git-bronnen, plus downloadpresets, inclusief transitieve afhankelijkheden. JFrog Artifactory-mirrors voor npm en PyPI werken ook.
• Kunnen we de lijst vertrouwen? Elke job en cache heeft een volledigheidsstatus, zodat een onvolledige vastlegging zichtbaar is en niet ongemerkt onvolledig blijft.
• Worden we geraakt door een nieuwe advisory? Gemonitorde SBOM's worden opnieuw beoordeeld wanneer nieuwe kwetsbaarheden worden gepubliceerd, en bevindingen worden over builds en repositories heen gebundeld.

De SBOM is als CycloneDX te downloaden via de openbare REST API, samen met de netwerktrace en herkomstgegevens van de job, zodat hij elke tool kan voeden die CycloneDX leest, inclusief de SCA die u al draait. De installatie is één regel in de workflow: wijzig runs-on in craci. GitHub Actions is vandaag de ondersteunde CI; GitLab CI, Jenkins en andere CI-systemen staan op de roadmap.

Een inventaris van wat waar is uitgerold

De inventarisweergave van CRACI toont precies welke softwareversies in welke producten zijn uitgerold, wereldwijd. Wanneer een nieuwe kwetsbaarheid opduikt, ziet u welke producten de getroffen versie draaien, in plaats van dat u het moet samenstellen uit release notes en spreadsheets.

Lees meer over SBOM-generatie tijdens de build en kwetsbaarheidstracking.