CRACI vs GitLab CI

Det korta svaret

GitLab är en komplett DevSecOps-plattform: versionshantering, merge requests, planering och CI/CD i en produkt, med en bred uppsättning säkerhetsskannrar och sårbarhetshantering på Ultimate-nivån. Om du vill ha en leverantör för hela programvarans livscykel är GitLab byggt för det.

CRACI är smalare. Det är en GitHub Actions-kompatibel runner som registrerar varje externt beroende ett bygge hämtar, styr vad bygget kan nå och gör om den registreringen till SBOM:er, proveniensdata och CRA-bevis. Den grundläggande skillnaden är traditionell CI med påkopplade skannrar mot CI där runnern själv är säkerhetsregistreringen.

En praktisk sak först. CRACI har i dag stöd för enbart GitHub Actions; GitLab CI och Jenkins finns på roadmapen. Om dina pipelines finns i GitLab CI skulle du behöva flytta dem till GitHub Actions för att använda CRACI-runners, eller vänta på stöd för GitLab CI, som finns på roadmapen.

Vad GitLab gör bra

En plattform. Kod, granskningar, pipelines, säkerhetsfynd och planering finns på samma ställe, med en behörighetsmodell. För många organisationer avgör det ensamt frågan.

Säkerhetsskanning, per nivå. Var noga med vad varje nivå innehåller. Enligt GitLab körs grundläggande SAST, upptäckt av hemligheter och containerskanning på alla nivåer, även Free. I Free och Premium ger de skanningarna JSON-rapportartefakter. Ultimate lägger till arbetsflödet runt dem: fynd i merge requests, sårbarhetsrapporten, beroendelistan, säkerhetsgodkännanden och GitLab Advanced SAST. Beroendeskanning, löpande sårbarhetsskanning och DAST är Ultimate-funktioner. Containerskanning kan också ge en SBOM-rapport i CycloneDX på alla nivåer.

Proveniens. GitLab Runner kan generera ett proveniensintyg för artefakter i formatet SLSA 1.0 på alla nivåer. Signerade SLSA Level 3-attesteringar finns också, men GitLab listar dem som ett experiment på GitLab.com för Ultimate, bakom en funktionsflagga som är avstängd som standard.

Val av runner. GitLab-hostade runners täcker Linux på x86-64 (2 till 32 vCPU) och arm64, med Windows och macOS i beta. Du kan också köra egna runners var som helst, och GitLab uppger att jobb på dina egna runners inte förbrukar beräkningsminuter. GitLab Dedicated lägger till datalagring i en region du väljer.

Där CRACI skiljer sig

SBOM:en kommer från bygget, inte från lockfilen

GitLabs SBOM-baserade beroendeskanning hittar beroenden från lockfiler som stöds eller exporter av beroendegrafen. Det är ett gediget tillvägagångssätt när lockfilen berättar hela historien. Byggen gör ofta mer: de kör installationsskript, laddar ner verktygskedjor, återställer cachar och hämtar basavbilder.

CRACI ser den aktiviteten eftersom det är runnern. En paketmedveten proxy observerar trafiken till paketkällor medan jobbet körs, för npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar. Beroendebevisen följer med CI-cachar, så ett paket som återställs från en cache räknas ändå. Varje jobb tar fram en SBOM i CycloneDX eller SPDX.

Fullständigheten anges, den antas inte

Varje SBOM har en fullständighetsstatus per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. När registreringen har en lucka kan du se den.

Byggets nätverk har en policy

CRACI:s egress-policyer nekar eller tillåter som standard, med 24 inbyggda förinställningar för programvarukällor och typade egna källor för npm, PyPI, apt, apk, Go-proxyn, Nix, Cargo, OCI-register och Git. Policyer valideras innan jobbet startar, blockerar vid fel och skickar en varning vid en överträdelse. På GitLab är nätverkskontrollen för byggen det du själv konfigurerar runt dina egna runners.

Proveniens

API:t returnerar SBOM:er, nätverksspårningar och proveniens. CRACI signerar inte proveniens och gör inte anspråk på någon SLSA-nivå.

Bevakning av det som levererats

CRACI sammanställer sårbarheter över byggen och repon och fortsätter att omvärdera bevakade SBOM:er när nya säkerhetsmeddelanden dyker upp.

Vilken som passar

• Stanna kvar på GitLab om din kod och dina pipelines finns på GitLab och du vill ha en plattform, eller om du behöver SAST, DAST och upptäckt av hemligheter i samma produkt.
• Välj CRACI om din kod finns på GitHub och du kör GitHub Actions, och du behöver bevis på vad som ingick i varje release, kontroll över vad byggen kan nå och SBOM:er du kan försvara vid en revision.
• Använd båda om din organisation kör båda plattformarna. GitLab fortsätter att täcka sina projekt och skannrar; CRACI kör GitHub Actions-sidan och registrerar de byggena.

För Cyber Resilience Act

Enligt EU:s Cyber Resilience Act behöver tillverkare veta vad som finns i varje produktrelease och hantera dess sårbarheter. Skyldigheterna att rapportera sårbarheter gäller från september 2026, och förordningen gäller i sin helhet från december 2027. GitLab Ultimate hjälper till att hitta och hantera sårbarheter i dina projekt. CRACI registrerar vad varje release byggdes av, fortsätter att bevaka den och exporterar SBOM:er som CycloneDX eller SPDX. Det 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. Inget av verktygen gör dig regelefterlevande på egen hand.

Lägg till CRACI

För ett repo på GitHub installerar du CRACI:s GitHub-app i din organisation, för alla repon eller ett urval, och ändrar runner-etiketten:

runs-on: craci

Arbetsflöden, actions och GitHubs gränssnitt förblir desamma. CRACI ersätter runnern, inte GitHub Actions. Läs mer om SBOM-generering under bygget och CRA-bevis, eller se priser.