CRACI vs Syft en Grype

Het korte antwoord

Syft is een populaire open-source SBOM-generator, en Grype is de bijbehorende kwetsbaarheidsscanner. Samen dekken ze genereren en matchen, gratis, in elke pipeline. CRACI is een GitHub Actions-runner die vastlegt wat elke build heeft opgehaald, vermeldt of die vastlegging volledig is, bepaalt waarmee de build verbinding mag maken en wat is geleverd blijft monitoren. Het verschil in één regel: Syft reconstrueert de SBOM uit bestanden, en hoeveel het vindt, hangt af van de configuratie en van wat er op schijf staat wanneer het draait. CRACI observeert die, en volgt de kwetsbaarheden in wat het heeft vastgelegd, zodat één product het werk van beide doet.

Waar Syft en Grype goed in zijn

Syft is "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems." Het herkent tientallen pakketsystemen, van Alpine, Debian en RPM tot Go, Python, Java, JavaScript, Ruby, Rust, PHP en .NET. Het schrijft CycloneDX, SPDX en een eigen Syft JSON, converteert tussen formaten, en kan ondertekende SBOM-attestaties maken met de in-toto-specificatie.

Grype scant containerimages, bestandssystemen en SBOM's op bekende kwetsbaarheden. Het prioriteert bevindingen met EPSS, KEV en risicoscores, ondersteunt OpenVEX om resultaten te filteren, en de vlag --fail-on laat een pipeline mislukken wanneer het kwetsbaarheden vindt op of boven een ernst die u kiest. Anchore merkt op dat Grype "runs entirely locally and doesn't send any data to external services," afgezien van het downloaden van de database.

Beide vallen onder Apache-2.0 en worden gesponsord door Anchore, waarvan het commerciële platform, Anchore Enterprise, "builds on open source Syft and Grype." Deze pagina gaat over de open-sourcetools.

Syft is sterk wanneer het de juiste bestanden voor zich heeft. Richt u het op een broncodeboom die zijn afhankelijkheden commit, zoals ollama/ollama, dan lost de standaardscan die op met versies, package-URL's en de afhankelijkheidsrelaties ertussen.

Eén vlag verandert het antwoord

Syft kiest zijn catalogers per scantype, en de documentatie legt uit waarom: "files that hint at the intent to install software do not have enough information in them to determine the exact version." Catalogers hebben tags zoals declared, installed, image en directory, en vlaggen zoals --select-catalogers en --override-default-catalogers veranderen de set.

In syft cataloger list bij v1.51.1 is de JavaScript-cataloger die node_modules leest getagd voor image- en installed-scans en zit hij niet in de standaardset voor een mapscan. Op een geïnstalleerde checkout bepaalt één vlag dus of de npm-pakketten in node_modules überhaupt worden gelezen. Dezelfde tool, dezelfde versie, dezelfde boom.

De keerzijde is net zo belangrijk. Geen enkele configuratie is overal de juiste:

• Op een schone checkout van express 5.2.1, die geen lockfile heeft, heeft de standaardscan geen npm-afhankelijkheden om op te lossen en geeft hij terug wat hij verder herkent, zoals GitHub Actions en workflowbestanden.
• Zet u de installed-catalogers aan en richt u ze op broncodebomen zoals ze zijn gecommit, waar nog niets is geïnstalleerd, dan hebben ze bijna niets om te lezen.
• Een repository zonder enig afhankelijkheidsmanifest geeft de scan geen afhankelijkheidsbestanden om te lezen, wat de configuratie ook is.

Niets hiervan is een bug. Syft rapporteert wat de bestanden voor zijn neus ondersteunen, zoals ontworpen. Het praktische gevolg is dat de SBOM afhangt van twee beslissingen die iemand in elke pipeline goed moet nemen: welke catalogers draaien, en of afhankelijkheden vóór de scan zijn geïnstalleerd. En Grype kan alleen matchen wat Syft heeft opgesomd. Een component dat in de SBOM ontbreekt, bereikt het opzoeken van kwetsbaarheden nooit, dus voor dat component komt de scan schoon terug.

Waar CRACI verschilt

CRACI heeft geen catalogers om te kiezen, omdat het de boom niet achteraf leest. U wijzigt runs-on in craci, en een proxy die pakketten herkent, legt vast wat de job ophaalt van npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk en Git-bronnen, plus downloadpresets. Pakketten die uit een CI-cache zijn teruggezet, nemen hun bewijs mee. Het resultaat, in CycloneDX of SPDX, bevat de transitieve afhankelijkheden die de build werkelijk heeft gebruikt.

• Volledigheid is expliciet. Elke job en cache wordt gemarkeerd als Complete, Complete with connections, Incomplete, Unavailable of Not recorded.
• De build staat onder controle. Een egressbeleid (standaard weigeren of toestaan, 24 ingebouwde presets voor softwarebronnen) wordt gevalideerd voordat de job start en is fail-closed.
• Herkomstgegevens. De API levert SBOM's, netwerktraces en herkomstgegevens. CRACI ondertekent herkomstgegevens niet; een Syft-attestatie ondertekent de SBOM.
• Monitoring. Gemonitorde SBOM's worden continu opnieuw beoordeeld, en bevindingen worden samengebracht over builds en repositories heen.

Grype doet nog steeds dingen die CRACI niet doet. VEX-filtering en het scannen van images die u niet zelf hebt gebouwd, zijn het terrein van Grype. De policy gates van CRACI kunnen de build laten mislukken; de drempelmeldingen 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. Duikt er een nieuwe kwetsbaarheid op, dan ziet u welke producten de getroffen versie draaien, in plaats van dat uit release notes en spreadsheets bij elkaar te moeten zoeken.

Overstappen van Syft en Grype

Op CRACI is er geen SBOM om te genereren en geen scanstap om te onderhouden. De runner legt de SBOM vast terwijl de build draait, en CRACI blijft die controleren op nieuwe kwetsbaarheden nadat de build is afgerond. Syft en Grype blijven de tools voor images en software van derden die u niet zelf hebt gebouwd, en voor pipelines buiten GitHub Actions.

Voor de Cyber Resilience Act

De CRA vraagt van fabrikanten dat ze de componenten in elk product documenteren, inclusief een SBOM, en dat ze kwetsbaarheden daarin afhandelen. Syft en Grype kunnen die SBOM maken en controleren, en het bewijsspoor van elke release terug naar de SBOM bouwt u zelf. CRACI legt de SBOM per build vast en exporteert die als CycloneDX of SPDX. Het automatiseert een aanzienlijk deel van het inzicht in de softwareketen en het bewijs dat bedrijven nodig hebben voor hun bredere CRA-nalevingsproces. Zie wat de CRA is en SBOM-generatie tijdens de build.