CRACI vs. Aikido

Konsolidering kontra dokumentasjon

Team ser vanligvis på Aikido fordi de vil ha færre sikkerhetsverktøy. Aikido dekker avhengigheter med åpen kildekode, egen kode, hemmeligheter, infrastruktur som kode, containere, skysikkerhet, dynamisk testing og beskyttelse i kjøretid i ett produkt, med ett sted å prioritere funn. For et lite team som raskt trenger bred dekning, er det et sterkt tilbud.

Team ser på CRACI av en snevrere grunn. De må vite hva byggene deres faktisk gjorde, kontrollere hva bygget kan nå, og lage dokumentasjon om hver utgivelse som holder overfor en kunde eller en revisor. CRACI gjør det ved selv å være CI-runneren.

Hva Aikido gjør bra

Bredden er hovedpoenget. Hver Aikido-plan omfatter SCA, SAST, oppdagelse av hemmeligheter, IaC, skysikkerhet, containerskanning, DAST, lisensskanning og SBOM-generering. SCA-delen bruker reachability på funksjonsnivå for å redusere støy, og AutoFix åpner pull requests med patchede versjoner. I CI kan Aikido blokkere pull requests med kritisk risiko, og plattformen fungerer med GitHub, GitLab, Jenkins, Bitbucket, CircleCI og andre. CRACI støtter i dag bare GitHub Actions, med GitLab CI og Jenkins på veikartet.

Aikido leverer også Safe Chain, et gratis verktøy som kjører en lokal proxy foran pakkebehandlerne for npm og PyPI og blokkerer pakker med kjent skadevare før de installeres, lokalt og i CI. CRACI blokkerer ikke enkeltpakker i dag. Blokkering av pakker for hele organisasjonen står på CRACIs veikart, men er ikke i produktet.

Når det gjelder compliance, omfatter Aikidos høyere planer compliance-rapporter for SOC 2 og ISO 27001 og synkronisering til compliance-plattformer som Drata og Vanta. Er hovedmålet ditt å mate et SOC 2-program med funn fra applikasjonssikkerhet, er Aikido laget for det.

Der CRACI skiller seg ut

CRACI er CI-kjøremiljøet

Aikidos beskyttelse i kjøretid vokter applikasjoner som kjører. CRACI jobber i et annet kjøremiljø: byggejobben. GitHub Actions-jobbene dine kjører på CRACI i isolerte virtuelle maskiner, på runnere fra 1 til 32 compute units, på x86-64 eller ARM64. Oppsettet er å endre runs-on til craci. Workflowene dine forblir de samme, og kjøringene vises fortsatt i GitHub-grensesnittet.

Fordi CRACI kjører jobben, kan det håndheve en egress-policy mens jobben kjører. 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. De valideres før jobben starter, og blokkerer ved feil. En skanner kan fortelle deg at en risikabel pakke finnes. En nettverkspolicy hindrer bygget i å nå steder det ikke skal.

Deterministisk byggdokumentasjon

Aikido bygger avhengighetsbildet sitt ut fra manifester og lockfiler og legger analyse på toppen, blant annet AI-drevne sjekker av utnyttbarhet. Det er en fornuftig måte å prioritere arbeid på.

CRACIs SBOM er ikke utledet. En pakkebevisst proxy registrerer hva jobben hentet fra pakkekildene, og dokumentasjonen for avhengighetene følger med CI-cacher, så pakker gjenopprettet fra en cache telles fortsatt med. Hver SBOM angir sin egen fullstendighet per jobb og per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Den er en registrering av hva som skjedde, ikke et anslag, og den forteller deg hvor den har hull.

Dette betyr noe fordi statiske SBOM-verktøy er mer uenige enn de fleste tror, og årsaken er strukturell. Hvert verktøy leser et annet sett med filer og tolker dem ulikt, så hva et repositorium sies å inneholde, avhenger av hvilket verktøy du spurte og hvordan det var konfigurert. Et prosjekt som ikke har noen lockfile, slik express 5.2.1 ikke har, gir en lockfile-leser ingenting å tolke i det hele tatt. CRACI kan ikke sammenlignes på de premissene, fordi det registrerer bygg i stedet for å skanne kataloger, og det er nettopp poenget: En byggregistrering avhenger ikke av hvilke filer som tilfeldigvis finnes.

Provenance-data via API-et

CRACI genererer SBOM-en i sin egen runner, ut fra det jobben hentet. API-et returnerer SBOM-er, nettverksspor og provenance.

Compliance-resultater bygget på den registreringen

For EUs Cyber Resilience Act er det vanskelige å vise hva som gikk inn i hver utgivelse, og hvordan du følger sårbarhetene i den over tid. CRACI samler sårbarheter på tvers av bygg og repositorier og vurderer overvåkede SBOM-er kontinuerlig på nytt. SBOM-er eksporteres som CycloneDX eller SPDX, sårbarheter inkludert, og API-et returnerer SBOM-er, nettverksspor og provenance. Det automatiserer en betydelig del av innsikten i og dokumentasjonen for programvareleverandørkjeden som selskaper trenger i sin bredere CRA-samsvarsprosess. Se CRA-compliance og CRA-dokumentasjon.

En oversikt over hva som er utrullet hvor

CRACIs inventaroversikt viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter, globalt. Når en ny sårbarhet dukker opp, ser du hvilke produkter som kjører den berørte versjonen, i stedet for å stykke det sammen fra utgivelsesnotater og regneark.

Hvor hvert verktøy passer

• Velg Aikido når du vil ha ett verktøy som dekker kode, avhengigheter, sky og applikasjoner i drift, du bruker andre CI-systemer enn GitHub Actions i dag, eller compliance-fokuset ditt er SOC 2- eller ISO 27001-rapportering basert på funn fra applikasjonssikkerhet.
• Velg CRACI når du bygger på GitHub Actions og må vite nøyaktig hva hvert bygg hentet, kontrollere byggets nettverkstilgang og ta vare på utgivelsesdokumentasjon for CRA og revisjoner fra kunder.
• Bruk begge når du vil ha Aikidos skanning og blokkering av pull requests pluss CRACIs kontroller og dokumentasjon i byggekjøremiljøet. Aikidos CI-sjekker og Safe Chain kjører som steg i workflowen din, og de stegene kan kjøre på en CRACI-runner som alle andre steg.