CRACI vs. GitLab CI

Lyhyt vastaus

GitLab on täydellinen DevSecOps-alusta: versionhallinta, merge requestit, suunnittelu ja CI/CD yhdessä tuotteessa, ja sen Ultimate-tasossa on laaja valikoima tietoturvaskannereita ja haavoittuvuuksien hallinta. Jos haluat yhden toimittajan koko ohjelmiston elinkaarelle, GitLab on tehty juuri siihen.

CRACI on kapeampi. Se on GitHub Actions -yhteensopiva runneri, joka tallentaa jokaisen ulkoisen riippuvuuden, jonka buildi hakee, rajaa, mihin buildi pääsee, ja muuttaa tallenteen SBOM:iksi, alkuperätiedoiksi ja CRA-näytöksi. Keskeinen ero on perinteinen CI, johon on liitetty skannereita, verrattuna CI:hin, jossa runneri itse on tietoturvan tallenne.

Yksi käytännön seikka ensin. CRACI tukee tällä hetkellä vain GitHub Actionsia; GitLab CI ja Jenkins ovat tiekartalla. Jos CI/CD-putkesi ovat GitLab CI:ssä, sinun pitäisi siirtää ne GitHub Actionsiin käyttääksesi CRACI:n runnereita tai odottaa GitLab CI -tukea, joka on tiekartalla.

Missä GitLab on hyvä

Yksi alusta. Koodi, katselmoinnit, CI/CD-putket, tietoturvalöydökset ja suunnittelu ovat samassa paikassa yhdellä käyttöoikeusmallilla. Monelle organisaatiolle jo tämä ratkaisee kysymyksen.

Tietoturvaskannaus tasoittain. Ole tarkka siitä, mitä kukin taso sisältää. GitLabin mukaan perus-SAST, salaisuuksien tunnistus ja konttiskannaus toimivat kaikissa tasoissa, myös Freessä. Free- ja Premium-tasoissa nämä skannaukset tuottavat JSON-raporttiartefakteja. Ultimate lisää niiden ympärille työnkulun: löydökset merge requesteissa, haavoittuvuusraportin, riippuvuusluettelon, tietoturvahyväksynnät ja GitLab Advanced SAST:n. Riippuvuusskannaus, jatkuva haavoittuvuusskannaus ja DAST ovat Ultimaten ominaisuuksia. Konttiskannaus voi myös tuottaa CycloneDX-muotoisen SBOM-raportin kaikissa tasoissa.

Alkuperätiedot. GitLab Runner voi tuottaa artefaktin alkuperäselvityksen SLSA 1.0 -muodossa kaikissa tasoissa. Myös allekirjoitettuja SLSA Level 3 -attestaatioita on, mutta GitLab listaa ne kokeiluksi GitLab.comissa Ultimate-tasolle, oletuksena pois päältä olevan ominaisuuslipun takana.

Runnerin valinta. GitLabin ylläpitämät runnerit kattavat Linuxin x86-64-arkkitehtuurilla (2–32 vCPU:ta) ja arm64:llä, ja Windows ja macOS ovat betavaiheessa. Voit myös ajaa omia runnereitasi missä tahansa, ja GitLabin mukaan omilla runnereilla ajettavat jobit eivät kuluta laskentaminuutteja. GitLab Dedicated tuo lisäksi datan sijainnin valitsemallasi alueella.

Missä CRACI on erilainen

SBOM tulee buildista, ei lukitustiedostosta

GitLabin SBOM-pohjainen riippuvuusskannaus tunnistaa riippuvuudet tuetuista lukitustiedostoista tai riippuvuusgraafin vienneistä. Se on hyvä lähestymistapa, kun lukitustiedosto kertoo koko totuuden. Buildit tekevät kuitenkin usein enemmän: ne ajavat asennusskriptejä, lataavat työkaluketjuja, palauttavat välimuisteja ja hakevat pohjakuvia.

CRACI näkee tämän toiminnan, koska se on runneri. Paketit tunnistava välityspalvelin seuraa liikennettä pakettilähteisiin jobin ajon aikana npm-, PyPI-, RubyGems-, Composer-, Cargo-, Go-, Nix-, OCI-, apt-, apk- ja Git-lähteissä sekä latausesiasetuksissa. Riippuvuustiedot kulkevat CI-välimuistien mukana, joten myös välimuistista palautettu paketti tulee kirjatuksi. Jokainen jobi tuottaa SBOM:n CycloneDX- tai SPDX-muodossa.

Kattavuus kerrotaan, sitä ei oleteta

Jokaisella SBOM:lla on kattavuustila jobia ja välimuistia kohden: Complete, Complete with connections, Incomplete, Unavailable tai Not recorded. Kun tallenteessa on aukko, näet sen.

Buildin verkkoliikenne on käytäntö

CRACI:n egress-käytännöt ovat oletuksena estäviä tai oletuksena sallivia, ja niissä on 24 valmista ohjelmistolähteiden esiasetusta sekä tyypitetyt mukautetut lähteet npm:lle, PyPI:lle, aptille, apkille, Go-proxylle, Nixille, Cargolle, OCI-rekistereille ja Gitille. Käytännöt validoidaan ennen jobin käynnistymistä, ne estävät liikenteen virhetilanteessa (fail closed) ja lähettävät hälytyksen rikkomuksesta. GitLabissa buildien verkkokontrolli on sitä, mitä itse määrität omien runneriesi ympärille.

Alkuperätiedot

API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot. CRACI ei allekirjoita alkuperätietoja eikä väitä saavuttavansa mitään SLSA-tasoa.

Toimitetun seuranta

CRACI kokoaa haavoittuvuudet yli buildien ja repositorioiden ja arvioi seurattavat SBOM:t uudelleen aina, kun uusia tietoturvatiedotteita ilmestyy.

Kumpi sopii

• Pysy GitLabissa, jos koodisi ja CI/CD-putkesi ovat GitLabissa ja haluat yhden alustan tai jos tarvitset SAST:n, DAST:n ja salaisuuksien tunnistuksen samassa tuotteessa.
• Valitse CRACI, jos koodisi on GitHubissa ja käytät GitHub Actionsia ja tarvitset näyttöä siitä, mitä kuhunkin julkaisuun meni, kontrollia siihen, mihin buildit pääsevät, ja SBOM:t, joita voit puolustaa auditoinnissa.
• Käytä molempia, jos organisaatiosi käyttää kumpaakin alustaa. GitLab kattaa edelleen omat projektinsa ja skannerinsa; CRACI ajaa GitHub Actionsin puolen ja tallentaa ne buildit.

Kyberkestävyyssäädöstä varten

EU:n kyberkestävyyssäädöksen (Cyber Resilience Act, CRA) mukaan valmistajien on tiedettävä, mitä kukin tuotejulkaisu sisältää, ja käsiteltävä sen haavoittuvuudet. Haavoittuvuuksien raportointivelvoitteet ovat voimassa syyskuusta 2026 alkaen, ja asetusta sovelletaan kokonaisuudessaan joulukuusta 2027 alkaen. GitLab Ultimate auttaa löytämään ja hallitsemaan haavoittuvuuksia projekteissasi. CRACI tallentaa, mistä kukin julkaisu on rakennettu, seuraa sitä jatkuvasti ja vie SBOM:t CycloneDX- tai SPDX-muodossa. Se automatisoi merkittävän osan siitä ohjelmistotoimitusketjun näkyvyydestä ja näytöstä, jota yritykset tarvitsevat laajempaan CRA-vaatimustenmukaisuuden prosessiinsa. Kumpikaan työkalu ei yksin tee sinusta vaatimustenmukaista.

CRACI:n käyttöönotto

GitHubissa olevalle repositoriolle asenna CRACI GitHub App organisaatioosi, kaikkiin repositorioihin tai valittuihin, ja vaihda runnerin tunniste:

runs-on: craci

Työnkulut, actionit ja GitHubin käyttöliittymä pysyvät ennallaan. CRACI korvaa runnerin, ei GitHub Actionsia. Lue lisää buildin aikaisesta SBOM-generoinnista ja CRA-näytöstä tai katso hinnoittelu.