CRACI vs Syft og Grype

Det korte svar

Syft er en populær open source-SBOM-generator, og Grype er den tilhørende sårbarhedsscanner. Sammen dækker de generering og matchning gratis i enhver pipeline. CRACI er en GitHub Actions-runner, der registrerer, hvad hvert build hentede, angiver, om registreringen er komplet, styrer, hvad buildet kan forbinde sig til, og bliver ved med at overvåge det, der er leveret. Forskellen på én linje: Syft rekonstruerer SBOM'en ud fra filer, og hvor meget det finder, afhænger af konfigurationen og af, hvad der ligger på disken, når det kører. CRACI observerer den og sporer sårbarhederne i det, det registrerede, så ét produkt gør begges arbejde.

Hvad Syft og Grype gør godt

Syft er "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems." Det genkender snesevis af pakkesystemer, fra Alpine, Debian og RPM til Go, Python, Java, JavaScript, Ruby, Rust, PHP og .NET. Det skriver CycloneDX, SPDX og sit eget Syft JSON, konverterer mellem formater og kan oprette signerede SBOM-attestationer efter in-toto-specifikationen.

Grype scanner container-images, filsystemer og SBOM'er for kendte sårbarheder. Det prioriterer fund med EPSS, KEV og risikoscoring, understøtter OpenVEX til filtrering af resultater, og dets flag --fail-on får en pipeline til at fejle, når det finder sårbarheder på eller over en alvorlighed, du vælger. Anchore bemærker, at Grype "runs entirely locally and doesn't send any data to external services," bortset fra at downloade sin database.

Begge er Apache-2.0 og sponsoreret af Anchore, hvis kommercielle platform, Anchore Enterprise, "builds on open source Syft and Grype." Denne side handler om open source-værktøjerne.

Syft er stærkt, når det har de rigtige filer foran sig. Peger du det mod et kildetræ, der committer sine afhængigheder, såsom ollama/ollama, resolver standardscanningen dem med versioner, package URLs og afhængighedskanterne mellem dem.

Ét flag ændrer svaret

Syft vælger sine catalogers efter scanningstype, og dokumentationen forklarer hvorfor: "files that hint at the intent to install software do not have enough information in them to determine the exact version." Catalogers har tags som declared, installed, image og directory, og flag som --select-catalogers og --override-default-catalogers ændrer sættet.

I syft cataloger list ved v1.51.1 er den JavaScript-cataloger, der læser node_modules, tagget til image- og installed-scanninger og er ikke med i standardsættet for en mappescanning. På et installeret checkout afgør ét flag altså, om npm-pakkerne i node_modules overhovedet bliver læst. Samme værktøj, samme version, samme træ.

Bagsiden betyder lige så meget. Ingen enkelt konfiguration er rigtig overalt:

• På et rent express 5.2.1-checkout, som ikke har nogen lockfile, har standardscanningen ingen npm-afhængigheder at resolve og returnerer det, den ellers genkender, såsom GitHub Actions og workflow-filer.
• Slår du installed-catalogers til og peger dem mod kildetræer, som de er committet, hvor intet er installeret endnu, har de næsten intet at læse.
• Et repository helt uden afhængighedsmanifest giver scanningen ingen afhængighedsfiler at læse, uanset konfigurationen.

Intet af dette er en fejl. Syft rapporterer det, filerne foran det understøtter, som designet. Den praktiske konsekvens er, at SBOM'en afhænger af to beslutninger, som nogen skal træffe rigtigt i hver pipeline: hvilke catalogers der kører, og om afhængigheder blev installeret før scanningen. Og Grype kan kun matche det, Syft har angivet. En komponent, der mangler i SBOM'en, når aldrig frem til sårbarhedsopslaget, så scanningen kommer tilbage ren for den.

Hvor CRACI er anderledes

CRACI har ingen catalogers at vælge, fordi det ikke læser træet bagefter. Du ændrer runs-on til craci, og en pakkebevidst proxy registrerer, hvad jobbet henter fra npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets. Pakker gendannet fra en CI-cache fører deres dokumentation med sig. Resultatet, i CycloneDX eller SPDX, inkluderer de transitive afhængigheder, buildet faktisk brugte.

• Fuldstændighed er eksplicit. Hvert job og hver cache markeres som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.
• Buildet er under kontrol. En egress-politik (default deny eller allow, 24 indbyggede presets for softwarekilder) valideres, før jobbet starter, og blokerer ved fejl (fail closed).
• Provenance-data. API'et returnerer SBOM'er, netværkstraces og provenance. CRACI signerer ikke provenance; en Syft-attestation signerer SBOM'en.
• Overvågning. Overvågede SBOM'er genvurderes løbende, og fund samles på tværs af builds og repositories.

Grype gør stadig ting, CRACI ikke gør. VEX-filtrering og scanning af images, du ikke selv har bygget, er Grypes område. CRACI's policy gates kan få buildet til at fejle; dets grænsealarmer 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 ud fra release notes og regneark.

Skift fra Syft og Grype

På CRACI er der ingen SBOM at generere og intet scanningstrin at vedligeholde. Runneren registrerer SBOM'en, mens buildet kører, og CRACI bliver ved med at tjekke den for nye sårbarheder, efter at buildet er færdigt. Syft og Grype forbliver værktøjerne til images og tredjepartssoftware, du ikke selv har bygget, og til pipelines uden for GitHub Actions.

Til Cyber Resilience Act

CRA beder producenter om at dokumentere komponenterne i hvert produkt, inklusive en SBOM, og om at håndtere sårbarheder i det. Syft og Grype kan producere og tjekke den SBOM, og dokumentationssporet fra hver release tilbage til dens SBOM er op til dig at bygge. CRACI registrerer SBOM'en pr. build og eksporterer den som CycloneDX eller SPDX. Det automatiserer en væsentlig del af den synlighed i og dokumentation for softwareforsyningskæden, som virksomheder har brug for i deres bredere CRA-compliance-proces. Se hvad CRA er og SBOM-generering under buildet.