CRACI vs GitLab CI

Det korte svar

GitLab er en komplet DevSecOps-platform: versionsstyring, merge requests, planlægning og CI/CD i ét produkt, med et bredt udvalg af sikkerhedsscannere og sårbarhedsstyring på Ultimate-niveauet. Vil du have én leverandør til hele softwarens livscyklus, er GitLab bygget til det.

CRACI er smallere. Det er en GitHub Actions-kompatibel runner, der registrerer hver ekstern afhængighed, et build henter, styrer, hvad buildet kan nå, og omsætter registreringen til SBOM'er, provenance-data og CRA-dokumentation. Kerneforskellen er traditionel CI med scannere koblet på over for CI, hvor runneren selv er sikkerhedsregistreringen.

Én praktisk ting kommer først. CRACI understøtter kun GitHub Actions i dag; GitLab CI og Jenkins er på roadmappen. Ligger dine pipelines i GitLab CI, skal du flytte dem til GitHub Actions for at bruge CRACI-runnere eller vente på understøttelse af GitLab CI, som er på roadmappen.

Hvad GitLab gør godt

Én platform. Kode, reviews, pipelines, sikkerhedsfund og planlægning ligger samme sted, med én rettighedsmodel. For mange organisationer afgør det alene spørgsmålet.

Sikkerhedsscanning efter niveau. Vær præcis med, hvad hvert niveau indeholder. Ifølge GitLab kører basis-SAST, opdagelse af secrets og containerscanning på alle niveauer, inklusive Free. I Free og Premium producerer disse scanninger artefakter med JSON-rapporter. Ultimate tilføjer arbejdsgangen omkring dem: fund i merge requests, sårbarhedsrapporten, afhængighedslisten, sikkerhedsgodkendelser og GitLab Advanced SAST. Dependency scanning, løbende sårbarhedsscanning og DAST er Ultimate-funktioner. Containerscanning kan også producere en CycloneDX-SBOM-rapport på alle niveauer.

Provenance. GitLab Runner kan generere en provenance-erklæring for artefakter i SLSA 1.0-formatet på alle niveauer. Signerede SLSA Level 3-attestationer findes også, men GitLab angiver dem som et eksperiment på GitLab.com for Ultimate, bag et feature flag, der som standard er slået fra.

Valg af runner. GitLab-hostede runnere dækker Linux på x86-64 (2 til 32 vCPU) og arm64, med Windows og macOS i beta. Du kan også køre dine egne runnere hvor som helst, og GitLab oplyser, at jobs på dine egne runnere ikke bruger compute-minutter. GitLab Dedicated tilføjer dataopbevaring i en region efter eget valg.

Hvor CRACI er anderledes

SBOM'en kommer fra buildet, ikke fra lockfilen

GitLabs SBOM-baserede dependency scanning finder afhængigheder ud fra understøttede lockfiles eller eksporter af afhængighedsgrafer. Det er en solid tilgang, når lockfilen fortæller hele historien. Builds gør ofte mere: De kører install-scripts, downloader toolchains, gendanner caches og henter base-images.

CRACI ser den aktivitet, fordi det er runneren. En pakkebevidst proxy observerer trafik til pakkekilder, mens jobbet kører, på tværs af npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets. Dokumentationen for afhængighederne følger med CI-caches, så en pakke gendannet fra en cache stadig tælles med. Hvert job producerer en SBOM i CycloneDX eller SPDX.

Fuldstændighed angives, den antages ikke

Hver SBOM har en fuldstændighedsstatus pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Når registreringen har et hul, kan du se det.

Buildets netværk er en politik

CRACI's egress-politikker er default deny eller default allow, med 24 indbyggede presets for softwarekilder og typede brugerdefinerede kilder til npm, PyPI, apt, apk, Go-proxyen, Nix, Cargo, OCI-registries og Git. Politikker valideres, før jobbet starter, blokerer ved fejl (fail closed) og sender en advarsel ved en overtrædelse. På GitLab er netværkskontrol for builds det, du selv konfigurerer omkring dine egne runnere.

Provenance

API'et returnerer SBOM'er, netværkstraces og provenance. CRACI signerer ikke provenance og gør ikke krav på noget SLSA-niveau.

Overvågning af det leverede

CRACI samler sårbarheder på tværs af builds og repositories og genvurderer løbende overvågede SBOM'er, efterhånden som nye advisories dukker op.

Hvilken passer bedst

• Bliv på GitLab, hvis din kode og dine pipelines ligger på GitLab, og du vil have én platform, eller hvis du har brug for SAST, DAST og opdagelse af secrets i samme produkt.
• Vælg CRACI, hvis din kode ligger på GitHub, og du kører GitHub Actions, og du har brug for dokumentation for, hvad der gik ind i hver release, kontrol over, hvad builds kan nå, og SBOM'er, du kan forsvare i en audit.
• Brug begge, hvis din organisation kører begge platforme. GitLab bliver ved med at dække sine projekter og scannere; CRACI kører GitHub Actions-siden og registrerer de builds.

Til Cyber Resilience Act

Under EU's Cyber Resilience Act skal producenter vide, hvad der er i hver produktrelease, og håndtere sårbarhederne i den. Forpligtelser til at rapportere sårbarheder gælder fra september 2026, og forordningen gælder fuldt ud fra december 2027. GitLab Ultimate hjælper med at finde og håndtere sårbarheder på tværs af dine projekter. CRACI registrerer, hvad hver release blev bygget af, bliver ved med at overvåge den og eksporterer SBOM'er som CycloneDX eller SPDX. Det 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. Ingen af værktøjerne gør dig compliant alene.

Tilføj CRACI

For et repository på GitHub installerer du CRACI GitHub App i din organisation, til alle repositories eller et udvalg, og ændrer runner-labelen:

runs-on: craci

Workflows, actions og GitHubs brugerflade forbliver de samme. CRACI erstatter runneren, ikke GitHub Actions. Læs mere om SBOM-generering under buildet og CRA-dokumentation, eller se priser.