CRACI vs. GitLab CI

Det korte svaret

GitLab er en komplett DevSecOps-plattform: kildekontroll, merge requests, planlegging og CI/CD i ett produkt, med et bredt sett sikkerhetsskannere og sårbarhetshåndtering i Ultimate-nivået. Vil du ha én leverandør for hele programvarens livssyklus, er GitLab bygget for det.

CRACI er smalere. Det er en GitHub Actions-kompatibel runner som registrerer hver ekstern avhengighet et bygg henter, kontrollerer hva bygget kan nå, og gjør den registreringen om til SBOM-er, provenance-data og CRA-dokumentasjon. Kjerneforskjellen er tradisjonell CI med påkoblede skannere mot CI der selve runneren er sikkerhetsregistreringen.

Ett praktisk poeng kommer først. CRACI støtter bare GitHub Actions i dag; GitLab CI og Jenkins står på veikartet. Hvis pipelinene dine ligger i GitLab CI, må du flytte dem til GitHub Actions for å bruke CRACI-runnere, eller vente på støtte for GitLab CI, som står på veikartet.

Hva GitLab gjør bra

Én plattform. Kode, gjennomganger, pipelines, sikkerhetsfunn og planlegging bor på samme sted, med én tilgangsmodell. For mange organisasjoner avgjør det spørsmålet alene.

Sikkerhetsskanning, etter nivå. Vær presis med hva hvert nivå inkluderer. Ifølge GitLab kjører grunnleggende SAST, oppdagelse av hemmeligheter og containerskanning på alle nivåer, også Free. I Free og Premium produserer disse skanningene JSON-rapportartefakter. Ultimate legger til arbeidsflyten rundt dem: funn i merge requests, sårbarhetsrapporten, avhengighetslisten, sikkerhetsgodkjenninger og GitLab Advanced SAST. Dependency scanning, kontinuerlig sårbarhetsskanning og DAST er Ultimate-funksjoner. Containerskanning kan også produsere en CycloneDX-SBOM-rapport på alle nivåer.

Provenance. GitLab Runner kan generere en provenance-erklæring for artefakter i SLSA 1.0-formatet på alle nivåer. Signerte attestasjoner på SLSA Level 3 finnes også, men GitLab oppgir dem som et eksperiment på GitLab.com for Ultimate, bak et funksjonsflagg som er slått av som standard.

Valg av runner. GitLab-hostede runnere dekker Linux på x86-64 (2 til 32 vCPU-er) og arm64, med Windows og macOS i beta. Du kan også kjøre egne runnere hvor som helst, og GitLab oppgir at jobber på egne runnere ikke bruker beregningsminutter. GitLab Dedicated legger til datalagring i en region du velger.

Der CRACI skiller seg ut

SBOM-en kommer fra bygget, ikke fra lockfilen

GitLabs SBOM-baserte dependency scanning oppdager avhengigheter fra støttede lockfiler eller eksporter av avhengighetsgrafen. Det er en solid tilnærming når lockfilen forteller hele historien. Bygg gjør ofte mer: De kjører installasjonsskript, laster ned verktøykjeder, gjenoppretter cacher og henter base-images.

CRACI ser denne aktiviteten fordi det er runneren. En pakkebevisst proxy observerer trafikk til pakkekilder mens jobben kjører, på tvers av npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder, pluss forhåndsinnstillinger for nedlastinger. Dokumentasjonen av avhengigheter følger med CI-cacher, så en pakke gjenopprettet fra en cache likevel blir regnet med. Hver jobb produserer en SBOM i CycloneDX eller SPDX.

Fullstendighet angis, den antas ikke

Hver SBOM har en fullstendighetsstatus per jobb og per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Når registreringen har et hull, kan du se det.

Byggenettverket er en policy

CRACI-egress-policyer er default deny eller default allow, med 24 innebygde forhåndsinnstillinger for programvarekilder og typede egendefinerte kilder for npm, PyPI, apt, apk, Go-proxyen, Nix, Cargo, OCI-registre og Git. Policyer valideres før jobben starter, blokkerer ved feil (fail closed) og sender et varsel ved brudd. På GitLab er nettverkskontrollen for bygg det du selv konfigurerer rundt egne runnere.

Provenance

API-et returnerer SBOM-er, nettverksspor og provenance. CRACI signerer ikke provenance og hevder ikke noe SLSA-nivå.

Overvåking av det som ble levert

CRACI samler sårbarheter på tvers av bygg og repositorier og fortsetter å vurdere overvåkede SBOM-er på nytt når nye advisories dukker opp.

Hva som passer

• Bli på GitLab hvis koden og pipelinene dine er på GitLab og du vil ha én plattform, eller hvis du trenger SAST, DAST og oppdagelse av hemmeligheter i samme produkt.
• Velg CRACI hvis koden din er på GitHub og du kjører GitHub Actions, og du trenger dokumentasjon på hva som gikk inn i hver utgivelse, kontroll over hva bygg kan nå, og SBOM-er du kan stå inne for i en revisjon.
• Bruk begge hvis organisasjonen din kjører begge plattformene. GitLab fortsetter å dekke prosjektene og skannerne sine; CRACI kjører GitHub Actions-siden og registrerer de byggene.

For Cyber Resilience Act

Under EUs Cyber Resilience Act må produsenter vite hva som er i hver produktutgivelse, og håndtere sårbarheter i den. Rapporteringspliktene for sårbarheter gjelder fra september 2026, og forordningen gjelder fullt ut fra desember 2027. GitLab Ultimate hjelper med å finne og håndtere sårbarheter på tvers av prosjektene dine. CRACI registrerer hva hver utgivelse ble bygget av, fortsetter å overvåke den og eksporterer SBOM-er som CycloneDX eller SPDX. Det automatiserer en betydelig del av innsynet i programvareleverandørkjeden og dokumentasjonen som bedrifter trenger for sin bredere CRA-samsvarsprosess. Ingen av verktøyene gjør deg samsvarende på egen hånd.

Slik legger du til CRACI

For et repository på GitHub installerer du CRACI GitHub App i organisasjonen din, for alle repositorier eller et utvalg, og endrer runner-etiketten:

runs-on: craci

Workflows, actions og GitHub-grensesnittet forblir de samme. CRACI erstatter runneren, ikke GitHub Actions. Les mer om SBOM-generering under bygget og CRA-dokumentasjon, eller se priser.