CRACI og Chainguard

Det korte svar

Chainguard bygger open source-software fra kildekoden og leverer den hærdet: minimale container-images med få eller ingen kendte sårbarheder, genopbyggede sprogbiblioteker, VM-images og hærdede GitHub Actions, hver med en signeret SBOM og provenance. Er dit problem, at de base-images og pakker, du starter fra, har for mange CVE'er, går Chainguard direkte efter det.

CRACI er en CI-runner til GitHub Actions. Dine jobs kører på den, og mens de kører, registrerer den hver ekstern afhængighed, de henter, og håndhæver en egress-politik. Chainguard sikrer inputtet. CRACI sikrer og registrerer buildet. Overlappet er meget lille, og de to passer naturligt sammen.

Overblik

Hvad Chainguard gør godt

Chainguard Containers er med Chainguards egne ord et katalog af zero-CVE-container-images bygget fra kildekode. Hvert image leveres med en signeret SBOM-attestation i SPDX-format og en SLSA 1.0-provenance-attestation, der beskriver build-miljøet, og alt kan verificeres med cosign. Kunder kan også få CycloneDX-SBOM'er på nyere builds.

CVE-politikken er konkret. For kunder med en ordre forpligter Chainguard sig til at afhjælpe kritiske CVE'er inden for 7 kalenderdage og høje, mellemstore og lave CVE'er inden for 14 kalenderdage, efter at en kvalificerende patch er blevet offentligt tilgængelig, for de understøttede versionsstrømme af dets images.

Chainguard Libraries anvender samme tilgang på sprogpakker. Det er et katalog af Java-, Python- og JavaScript-afhængigheder, der er genopbygget fra verificeret kildekode i stedet for at blive downloadet som færdigbyggede artefakter, og som leveres som upstream til JFrog Artifactory, Sonatype Nexus Repository eller Cloudsmith. Hver pakke har Sigstore-signaturer, en signeret SBOM og SLSA Level 3-provenance. Chainguard Actions tilbyder hærdede versioner af populære GitHub Actions, bygget fra kildekode og løbende scannet, og Chainguard VMs anvender modellen på images til virtuelle maskiner.

CRACI producerer ikke hærdede images eller biblioteker og lover intet om antallet af CVE'er i noget, du henter. Det er Chainguards opgave.

Hvor CRACI er anderledes

Det overvåger dit build, ikke Chainguards

Chainguards SBOM'er og provenance beskriver Chainguards artefakter, bygget i Chainguards fabrik. Dit build kører stadig et sted, og det trækker mere ind end et base-image: dine egne afhængigheder, toolchains, værktøjer hentet af install-scripts og hvad end et workflow-trin downloader. Det registrerer CRACI. En pakkebevidst proxy på runneren observerer trafik til pakkekilder på tværs af npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder. Dokumentationen følger med CI-caches, og hver SBOM angiver sin fuldstændighed pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

Det begrænser, hvad buildet kan nå

Hærdede input hjælper kun, hvis buildet faktisk bruger dem. CRACI's egress-politik er default deny eller default allow, med 24 indbyggede presets for softwarekilder og typede brugerdefinerede kilder til registries, herunder OCI-registries og Git. Politikker valideres, før jobbet starter, og blokerer ved fejl (fail closed). En politik, der tillader dit Chainguard-registry og dit artefakt-repository og ikke meget andet, gør "vi bruger Chainguard" fra en konvention til noget, runneren håndhæver.

Det bliver ved med at overvåge det, du har leveret

API'et returnerer SBOM'er, netværkstraces og provenance. CRACI genvurderer løbende overvågede SBOM'er for nye sårbarheder. SBOM'er eksporteres i CycloneDX eller SPDX, inklusive sårbarheder.

Et inventar 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.

Brug dem sammen

Et typisk setup:

• Chainguard leverer base-images og, via dit artefakt-repository, genopbyggede biblioteker.
• CRACI kører de GitHub Actions-jobs, der bygger på dem, med en egress-politik, der tillader dine godkendte kilder, og registrerer, hvad hvert job hentede.

OCI er blandt de økosystemer, CRACI registrerer, og CRACI fungerer med JFrog Artifactory-spejle til npm og PyPI, så images og Python- eller JavaScript-pakker, der kommer den vej, er en del af build-registreringen. Understøttelse af Maven, som dækker Chainguard Libraries til Java, er på roadmappen.

Hvilken passer bedst

• Scannere bliver ved med at markere CVE'er i dine base-images: Chainguard erstatter de images med hærdede images.
• Du har brug for dokumentation for, hvad der gik ind i hver release: CRACI registrerer det fra buildet.
• Du vil have builds, der kun kan nå godkendte kilder: CRACI's egress-politik håndhæver det på runneren.
• Du vil have både rene input og et registreret build: Brug dem sammen som beskrevet ovenfor.

Til Cyber Resilience Act

At starte fra komponenter med få kendte sårbarheder, en dokumenteret SLA for afhjælpning og signerede SBOM'er gør en producents sårbarhedshåndtering lettere. Der hjælper Chainguard. CRACI 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: hvad der gik ind i hver release, og løbende sårbarhedssporing. Ingen af dem gør et produkt compliant alene. Læs, hvad CRA er, og se CRA-compliance.

Tilføj CRACI til et Chainguard-setup

Installér CRACI's GitHub App, og ændr derefter runs-on til craci i de workflows, du vil have registreret. Dine Dockerfiles og pakkekonfigurationen forbliver, som de er. CRACI understøtter GitHub Actions i dag; GitLab CI, Jenkins og andre CI-systemer er på roadmappen. Læs mere om SBOM-generering under buildet og CI/CD-integration.