CRACI och Chainguard

Det korta svaret

Chainguard bygger programvara med öppen källkod från källkoden och levererar den härdad: minimala containeravbilder med få eller inga kända sårbarheter, ombyggda språkbibliotek, VM-avbilder och härdade GitHub Actions, var och en med en signerad SBOM och proveniens. Om ditt problem är att basavbilderna och paketen du utgår från bär på för många CVE:er går Chainguard rakt på det.

CRACI är en CI-runner för GitHub Actions. Dina jobb körs på den, och medan de körs registrerar den varje externt beroende de hämtar och upprätthåller en egress-policy. Chainguard säkrar indata. CRACI säkrar och registrerar bygget. Överlappet är mycket litet, och de två passar naturligt ihop.

I korthet

Vad Chainguard gör bra

Chainguard Containers är, med Chainguards egna ord, en katalog med containeravbilder utan CVE:er, byggda från källkod. Varje avbild levereras med en signerad SBOM-attestering i SPDX-format och en SLSA 1.0-proveniensattestering som beskriver byggmiljön, allt verifierbart med cosign. Kunder kan också få CycloneDX-SBOM:er för nyare byggen.

CVE-policyn är konkret. För kunder med en beställning åtar sig Chainguard att åtgärda kritiska CVE:er inom 7 kalenderdagar och höga, medelhöga och låga CVE:er inom 14 kalenderdagar från att en kvalificerande patch blivit offentligt tillgänglig, för de versionsspår av avbilderna som stöds.

Chainguard Libraries tillämpar samma angreppssätt på språkpaket. Det är en katalog med beroenden för Java, Python och JavaScript som byggts om från verifierad källkod i stället för att laddas ner som förkompilerade artefakter, levererad som en uppströmskälla till JFrog Artifactory, Sonatype Nexus Repository eller Cloudsmith. Varje paket har Sigstore-signaturer, en signerad SBOM och SLSA Level 3-proveniens. Chainguard Actions erbjuder härdade versioner av populära GitHub Actions, byggda från källkod och skannade löpande, och Chainguard VMs tillämpar modellen på avbilder för virtuella maskiner.

CRACI tar inte fram härdade avbilder eller bibliotek och lovar ingenting om antalet CVE:er i det du hämtar. Det är Chainguards jobb.

Där CRACI skiljer sig

Den bevakar ditt bygge, inte Chainguards

Chainguards SBOM:er och proveniens beskriver Chainguards artefakter, byggda i Chainguards fabrik. Ditt bygge körs fortfarande någonstans, och det drar in mer än en basavbild: dina egna beroenden, verktygskedjor, verktyg som installationsskript hämtar och allt som ett arbetsflödessteg laddar ner. Det registrerar CRACI. En paketmedveten proxy på runnern observerar trafiken till paketkällor för npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor. Bevisen följer med CI-cachar, och varje SBOM anger sin fullständighet per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

Den begränsar vad bygget kan nå

Härdade indata hjälper bara om bygget faktiskt använder dem. CRACI:s egress-policy nekar eller tillåter som standard, med 24 inbyggda förinställningar för programvarukällor och typade egna källor för register, inklusive OCI-register och Git. Policyer valideras innan jobbet startar och blockerar vid fel. En policy som tillåter ditt Chainguard-register och ditt artefaktförråd, och inte mycket mer, förvandlar "vi använder Chainguard" från en konvention till något som runnern upprätthåller.

Den fortsätter bevaka det du levererade

API:t returnerar SBOM:er, nätverksspårningar och proveniens. CRACI fortsätter att omvärdera bevakade SBOM:er mot nya sårbarheter. SBOM:er exporteras i CycloneDX eller SPDX, inklusive sårbarheter.

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 ser du vilka produkter som kör den berörda versionen i stället för att pussla ihop det från release notes och kalkylblad.

Att använda dem tillsammans

En typisk uppsättning:

• Chainguard levererar basavbilder och, via ditt artefaktförråd, ombyggda bibliotek.
• CRACI kör GitHub Actions-jobben som bygger på dem, med en egress-policy som tillåter dina godkända källor, och registrerar vad varje jobb hämtade.

OCI är ett av de ekosystem som CRACI känner igen, och CRACI fungerar med JFrog Artifactory-speglar för npm och PyPI, så avbilder och Python- eller JavaScript-paket som kommer den vägen ingår i byggets registrering. Stöd för Maven, som täcker Chainguard Libraries för Java, finns på roadmapen.

Vilken som passar

• Skannrar flaggar hela tiden CVE:er i dina basavbilder: Chainguard ersätter de avbilderna med härdade avbilder.
• Du behöver bevis på vad som ingick i varje release: CRACI registrerar det från bygget.
• Du vill ha byggen som bara kan nå godkända källor: CRACI:s egress-policy upprätthåller det i runnern.
• Du vill ha både rena indata och ett registrerat bygge: använd dem tillsammans, som ovan.

För Cyber Resilience Act

Att utgå från komponenter med få kända sårbarheter, en dokumenterad SLA för åtgärder och signerade SBOM:er gör en tillverkares sårbarhetshantering enklare. Där hjälper Chainguard. CRACI 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: vad som ingick i varje release och löpande sårbarhetsbevakning. Ingen av dem gör en produkt regelefterlevande på egen hand. Se vad CRA är och CRA-efterlevnad.

Lägga till CRACI i en Chainguard-uppsättning

Installera CRACI GitHub App och ändra sedan runs-on till craci i de arbetsflöden du vill registrera. Dina Dockerfiles och din paketkonfiguration förblir som de är. CRACI har i dag stöd för GitHub Actions; GitLab CI, Jenkins och andra CI-system finns på roadmapen. Läs mer om SBOM-generering under bygget och CI/CD-integration.