123% fler rapporterade CVE:er per dag 2026 än förra året.

Jämförelse

CRACI vs Syft och Grype

Syft och Grype är Anchores gratisverktyg för att generera SBOM:er och hitta sårbarheterna i dem. De är bara så kompletta som det Syft hittar på disk. CRACI registrerar komponentlistan medan bygget körs.

Uppdaterad

Det korta svaret

Syft är en populär SBOM-generator med öppen källkod, och Grype är sårbarhetsskannern som hör till den. Tillsammans täcker de generering och matchning gratis, i valfri pipeline. CRACI är en GitHub Actions-runner som registrerar vad varje bygge hämtade, anger om registreringen är komplett, styr vart bygget kan ansluta och fortsätter att bevaka det som levererats. Skillnaden på en rad: Syft rekonstruerar SBOM:en från filer, och hur mycket det hittar beror på dess konfiguration och på vad som finns på disk när det körs. CRACI observerar den och spårar sårbarheterna i det som registrerats, så en enda produkt gör bådas jobb.

Funktion CRACI Syft och Grype
Kör dina byggen Jobb körs på CRACI-runners CLI-steg i valfri pipeline
Beroenden registrerade från bygget Observerade hämtningar, inklusive cachade paket Cataloger läser filer i efterhand
SBOM:ens fullständighet Anges per jobb och per cache Beror på vilka cataloger som kördes och vad som fanns på disk
Egress-policy på runnern Nekar eller tillåter som standard, blockerar vid fel Utanför deras område
Signerade bevis Ingen signerad proveniens Syft skapar signerade SBOM-attesteringar enligt in-toto
Sårbarhetsmatchning Samlad över byggen och repon Grype, med EPSS, KEV och riskpoäng
Bevakning av levererade SBOM:er Bevakade SBOM:er omvärderas löpande Skanna om SBOM:er med Grype enligt ditt schema
Låt CI misslyckas vid en allvarlighetströskel Policykontroller blockerar byggen på grund av fynd; trösklar anges inte grype --fail-on
Skanna avbilder och kataloger du inte har byggt Registrerar de byggen det kör Avbilder, kataloger, arkiv och SBOM:er
Utöver GitHub Actions GitHub Actions i dag; GitLab CI och Jenkins på roadmapen Valfri CI eller lokalt CLI
Pris $0.002 per vCPU-minut ($0.004 för 2 vCPU), mäts per sekund; ingen månadsavgift och ingen avgift per SBOM Gratis och öppen källkod under Apache-2.0. Anchore Enterprise är en separat betald produkt.
  • Ingår
  • Delvis
  • Ingår inte
  • På roadmapen

Vad Syft och Grype gör bra

Webbplatsen för Syft and Grype
anchore.com

Syft är "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems." Det känner igen dussintals paketsystem, från Alpine, Debian och RPM till Go, Python, Java, JavaScript, Ruby, Rust, PHP och .NET. Det skriver CycloneDX, SPDX och sitt eget Syft JSON, konverterar mellan format och kan skapa signerade SBOM-attesteringar med in-toto-specifikationen.

Grype skannar containeravbilder, filsystem och SBOM:er efter kända sårbarheter. Det prioriterar fynd med EPSS, KEV och riskpoäng, har stöd för OpenVEX för att filtrera resultat, och dess flagga --fail-on får en pipeline att misslyckas när det hittar sårbarheter på eller över en allvarlighetsgrad du väljer. Anchore påpekar att Grype "runs entirely locally and doesn't send any data to external services", bortsett från nedladdningen av dess databas.

Båda har licensen Apache-2.0 och sponsras av Anchore, vars kommersiella plattform, Anchore Enterprise, "builds on open source Syft and Grype." Den här sidan handlar om verktygen med öppen källkod.

Syft är starkt när det har rätt filer framför sig. Pekat mot ett källkodsträd som checkar in sina beroenden, som ollama/ollama, löser standardskanningen upp dem med versioner, paket-URL:er och beroendekanterna mellan dem.

En flagga ändrar svaret

Syft väljer sina cataloger efter skanningstyp, och dess dokumentation förklarar varför: "files that hint at the intent to install software do not have enough information in them to determine the exact version." Cataloger har taggar som declared, installed, image och directory, och flaggor som --select-catalogers och --override-default-catalogers ändrar uppsättningen.

I syft cataloger list vid v1.51.1 är JavaScript-catalogern som läser node_modules taggad för skanningar av avbilder och installerade paket och ingår inte i standarduppsättningen för en katalogskanning. Så på en installerad utcheckning avgör en enda flagga om npm-paketen i node_modules läses över huvud taget. Samma verktyg, samma version, samma träd.

Baksidan spelar lika stor roll. Ingen enskild konfiguration är rätt överallt:

  • På en ren utcheckning av express 5.2.1, som saknar lockfile, har standardskanningen inga npm-beroenden att lösa och returnerar det den annars känner igen, som GitHub Actions och arbetsflödesfiler.
  • Slå på catalogerna för installerade paket och peka dem mot källkodsträd som de är incheckade, där inget har installerats ännu, så har de nästan inget att läsa.
  • Ett repo utan något beroendemanifest alls ger skanningen inga beroendefiler att läsa, oavsett konfiguration.

Inget av detta är en bugg. Syft rapporterar det som filerna framför det ger stöd för, precis som det är utformat. Den praktiska följden är att SBOM:en beror på två beslut som någon måste fatta rätt i varje pipeline: vilka cataloger som körs och om beroenden installerades före skanningen. Och Grype kan bara matcha det Syft listade. En komponent som saknas i SBOM:en når aldrig sårbarhetskontrollen, så skanningen ser ren ut för den.

Där CRACI skiljer sig

CRACI har inga cataloger att välja, eftersom det inte läser trädet i efterhand. Du ändrar runs-on till craci, och en paketmedveten proxy registrerar vad jobbet hämtar från npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar. Paket som återställs från en CI-cache tar med sig sina bevis. Resultatet, i CycloneDX eller SPDX, innehåller de transitiva beroenden som bygget faktiskt använde.

  • Fullständigheten är explicit. Varje jobb och cache markeras som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.
  • Bygget styrs. En egress-policy (neka eller tillåt som standard, 24 inbyggda förinställningar för programvarukällor) valideras innan jobbet startar och blockerar vid fel.
  • Proveniensdata. API:t returnerar SBOM:er, nätverksspårningar och proveniens. CRACI signerar inte proveniens; en Syft-attestering signerar SBOM:en.
  • Bevakning. Bevakade SBOM:er omvärderas löpande, och fynd samlas över byggen och repon.

Grype gör fortfarande saker som CRACI inte gör. VEX-filtrering och skanning av avbilder du inte har byggt är Grypes område. CRACI:s policykontroller kan stoppa bygget; dess tröskelvarningar 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.

Flytta från Syft och Grype

På CRACI finns det ingen SBOM att generera och inget skanningssteg att underhålla. Runnern registrerar SBOM:en medan bygget körs, och CRACI fortsätter att kontrollera den mot nya sårbarheter efter att bygget är klart. Syft och Grype är fortfarande verktygen för avbilder och tredjepartsprogramvara du inte har byggt, och för pipelines utanför GitHub Actions.

För Cyber Resilience Act

CRA kräver att tillverkare dokumenterar komponenterna i varje produkt, inklusive en SBOM, och att de hanterar sårbarheter i den. Syft och Grype kan ta fram och kontrollera den SBOM:en, och beviskedjan från varje release tillbaka till dess SBOM får du bygga själv. CRACI registrerar SBOM:en per bygge och exporterar den som CycloneDX eller SPDX. Det automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som företag behöver för sitt bredare arbete med CRA-efterlevnad. Se vad CRA är och SBOM-generering under bygget.

Jämför en registrerad SBOM med ditt Syft-resultat

Boka en demo så kör vi ett av dina GitHub Actions-arbetsflöden på CRACI och jämför dess SBOM med vad Syft hittar för samma commit.

Boka en demo