CRACI vs Aikido

Konsolidering kontra bevis

Team tittar oftast på Aikido för att de vill ha färre säkerhetsverktyg. Aikido täcker beroenden med öppen källkod, egen kod, hemligheter, infrastruktur som kod, containrar, molnsäkerhetsläge, dynamisk testning och skydd i drift i en enda produkt, med ett ställe att triagera fynd på. För ett litet team som snabbt behöver bred täckning är det ett starkt erbjudande.

Team tittar på CRACI av ett snävare skäl. De behöver veta vad deras byggen faktiskt gjorde, styra vad bygget kan nå och ta fram bevis om varje release som håller inför en kund eller en revisor. CRACI gör det genom att självt vara CI-runnern.

Vad Aikido gör bra

Bredden är huvudsaken. Varje Aikido-plan listar SCA, SAST, upptäckt av hemligheter, IaC, molnsäkerhetsläge, containerskanning, DAST, licensskanning och SBOM-generering. SCA:n använder nåbarhet på funktionsnivå för att minska bruset, och AutoFix öppnar pull requests med patchade versioner. I CI kan Aikido blockera pull requests med kritiska risker, och plattformen fungerar med GitHub, GitLab, Jenkins, Bitbucket, CircleCI med flera. CRACI har i dag stöd för enbart GitHub Actions, med GitLab CI och Jenkins på roadmapen.

Aikido levererar också Safe Chain, ett gratis verktyg som kör en lokal proxy framför pakethanterarna för npm och PyPI och blockerar paket med känd skadlig kod innan de installeras, lokalt och i CI. CRACI blockerar inte enskilda paket i dag. Blocklistning av paket för hela organisationen finns på CRACI:s roadmap, inte i produkten.

När det gäller efterlevnad inkluderar Aikidos högre planer efterlevnadsrapporter för SOC 2 och ISO 27001 och synkronisering till efterlevnadsplattformar som Drata och Vanta. Om ditt huvudmål är att mata ett SOC 2-program med fynd från applikationssäkerheten är Aikido byggt för det.

Där CRACI skiljer sig

CRACI är CI-körmiljön

Aikidos skydd i drift vaktar applikationer som körs. CRACI arbetar i en annan körmiljö: byggjobbet. Dina GitHub Actions-jobb körs på CRACI i isolerade virtuella maskiner, på runners från 1 till 32 beräkningsenheter, på x86-64 eller ARM64. Installationen består i att ändra runs-on till craci. Dina arbetsflöden förblir desamma, och körningarna syns fortfarande i GitHubs gränssnitt.

Eftersom CRACI kör jobbet kan det upprätthålla en egress-policy medan jobbet körs. Policyerna 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. De valideras innan jobbet startar och blockerar vid fel. En skanner kan berätta att ett riskabelt paket finns. En nätverkspolicy hindrar bygget från att nå ställen det inte ska nå.

Deterministiska bevis från bygget

Aikido bygger sin bild av beroendena från manifest och lockfiler och lägger till analys ovanpå, bland annat AI-drivna kontroller av exploaterbarhet. Det är ett förnuftigt sätt att prioritera arbetet.

CRACI:s SBOM är inte härledd. En paketmedveten proxy registrerar vad jobbet hämtade från paketkällorna, och beroendebevisen följer med CI-cachar, så paket som återställs från en cache räknas ändå. Varje SBOM anger sin egen fullständighet per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Den är en registrering av vad som hände snarare än en uppskattning, och den visar var den har luckor.

Det spelar roll eftersom statiska SBOM-verktyg är mer oense än de flesta tror, och orsaken är strukturell. Vart och ett läser en annan uppsättning filer och tolkar dem på olika sätt, så vad ett repository sägs innehålla beror på vilket verktyg du frågade och hur det var konfigurerat. Ett projekt som inte checkar in någon lockfile, som express 5.2.1, ger en lockfile-läsare ingenting alls att utgå från. CRACI kan inte jämföras på de villkoren, eftersom det registrerar byggen i stället för att skanna kataloger, och det är just poängen: en registrering av bygget beror inte på vilka filer som råkar finnas.

Proveniensdata via API:t

CRACI genererar SBOM:en i sin egen runner, utifrån vad jobbet hämtade. API:t returnerar SBOM:er, nätverksspårningar och proveniens.

Efterlevnad byggd på den registreringen

För EU:s Cyber Resilience Act är det svåra att visa vad som ingick i varje release och hur du följer dess sårbarheter över tid. CRACI sammanställer sårbarheter över byggen och repon och omvärderar bevakade SBOM:er löpande. SBOM:er exporteras i CycloneDX eller SPDX, sårbarheter inräknade, och API:t returnerar SBOM:er, nätverksspårningar och proveniens. Det automatiserar en betydande del av den insyn i leveranskedjan för programvara och de bevis som företag behöver i sitt bredare arbete med CRA-efterlevnad. Se CRA-efterlevnad och CRA-bevis.

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.

Var de passar

• Välj Aikido när du vill ha ett verktyg som täcker kod, beroenden, moln och applikationer i drift, du använder andra CI-system än GitHub Actions i dag, eller ditt efterlevnadsfokus är rapportering för SOC 2 eller ISO 27001 utifrån fynd från applikationssäkerheten.
• Välj CRACI när du bygger på GitHub Actions och behöver veta exakt vad varje bygge hämtade, styra byggets nätverksåtkomst och spara bevis om varje release för CRA och kundrevisioner.
• Använd båda när du vill ha Aikidos skanning och spärrar för pull requests plus CRACI:s kontroller och bevis i byggkörmiljön. Aikidos CI-kontroller och Safe Chain körs som steg i ditt arbetsflöde, och de stegen kan köras på en CRACI-runner precis som alla andra.