CRACI vs. Aikido

Konsolidering kontra dokumentation

Teams kigger som regel på Aikido, fordi de vil have færre sikkerhedsværktøjer. Aikido dækker open source-afhængigheder, egen kode, secrets, infrastructure as code, containere, cloud posture, dynamisk test og runtime-beskyttelse i ét produkt, med ét sted at triagere fund. For et lille team, der hurtigt har brug for bred dækning, er det et stærkt tilbud.

Teams kigger på CRACI af en snævrere grund. De har brug for at vide, hvad deres builds faktisk gjorde, styre, hvad buildet kan nå, og producere dokumentation for hver release, der holder over for en kunde eller en revisor. Det gør CRACI ved selv at være CI-runneren.

Hvad Aikido gør godt

Bredden er hovedpointen. Hver Aikido-plan omfatter SCA, SAST, detektion af secrets, IaC, cloud posture, container-scanning, DAST, licensscanning og SBOM-generering. Dets SCA bruger reachability på funktionsniveau til at reducere støj, og AutoFix åbner pull requests med patchede versioner. I CI kan Aikido blokere pull requests med kritiske risici, og det fungerer med GitHub, GitLab, Jenkins, Bitbucket, CircleCI og andre. CRACI understøtter i dag kun GitHub Actions, med GitLab CI og Jenkins på roadmappen.

Aikido leverer også Safe Chain, et gratis værktøj, der kører en lokal proxy foran pakkehåndteringerne til npm og PyPI og blokerer pakker med kendt malware, før de installeres, lokalt og i CI. CRACI blokerer ikke enkelte pakker i dag. Blokeringslister for pakker på tværs af organisationen er på CRACI's roadmap, ikke i produktet.

På compliance-siden omfatter Aikidos højere planer compliance-rapporter til SOC 2 og ISO 27001 og synkronisering med compliance-platforme som Drata og Vanta. Er dit hovedmål at forsyne et SOC 2-program med fund fra applikationssikkerhed, er Aikido bygget til det.

Hvor CRACI er anderledes

CRACI er CI-runtimen

Aikidos runtime-beskyttelse beskytter kørende applikationer. CRACI arbejder i en anden runtime: build-jobbet. Dine GitHub Actions-jobs kører på CRACI i isolerede virtuelle maskiner, på runnere fra 1 til 32 compute units, på x86-64 eller ARM64. Opsætningen består i at ændre runs-on til craci. Dine workflows forbliver de samme, og kørslerne vises stadig i GitHubs brugerflade.

Fordi CRACI kører jobbet, kan det håndhæve en egress-politik, mens jobbet kører. 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. De valideres, før jobbet starter, og blokerer ved fejl (fail closed). En scanner kan fortælle dig, at en risikabel pakke findes. En netværkspolitik forhindrer buildet i at nå steder, det ikke bør.

Deterministisk build-dokumentation

Aikido bygger sit billede af afhængighederne ud fra manifester og lockfiles og lægger analyse ovenpå, herunder AI-drevne tjek af udnyttelighed. Det er en fornuftig måde at prioritere arbejdet på.

CRACI's SBOM er ikke udledt. En pakkebevidst proxy registrerer, hvad jobbet hentede fra pakkekilderne, og dokumentationen for afhængighederne følger med CI-caches, så pakker gendannet fra en cache stadig tælles med. Hver SBOM angiver sin egen fuldstændighed pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Det er en registrering af, hvad der skete, snarere end et skøn, og den fortæller dig, hvor den har huller.

Det betyder noget, fordi statiske SBOM-værktøjer er mere uenige, end de fleste forventer, og årsagen er strukturel. Hvert værktøj læser et andet sæt filer og tolker dem forskelligt, så hvad et repository siges at indeholde, afhænger af, hvilket værktøj du spurgte, og hvordan det var konfigureret. Et projekt, der ikke committer en lockfile, som express 5.2.1 ikke gør, giver en lockfile-læser slet intet at læse. CRACI kan ikke sammenlignes på de præmisser, fordi det registrerer builds i stedet for at scanne mapper, og det er netop pointen: En build-registrering afhænger ikke af, hvilke filer der tilfældigvis er til stede.

Provenance-data via API'et

CRACI genererer SBOM'en i sin egen runner ud fra det, jobbet hentede. API'et returnerer SBOM'er, netværkstraces og provenance.

Compliance-resultater bygget på den registrering

Under EU's Cyber Resilience Act er det svære at vise, hvad der gik ind i hver release, og hvordan du følger dens sårbarheder over tid. CRACI samler sårbarheder på tværs af builds og repositories og genvurderer løbende overvågede SBOM'er. SBOM'er eksporteres som CycloneDX eller SPDX, inklusive sårbarheder, og API'et returnerer SBOM'er, netværkstraces og provenance. Det automatiserer en væsentlig del af den indsigt i og dokumentation for softwareforsyningskæden, som virksomheder har brug for i deres bredere proces for CRA-compliance. Se CRA-compliance og CRA-dokumentation.

Et overblik over, hvad der er udrullet hvor

CRACI's inventaroversigt viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter, globalt. Når en ny sårbarhed lander, kan du se, hvilke produkter der kører den berørte version, i stedet for at stykke det sammen fra release notes og regneark.

Hvor hvert værktøj passer

• Vælg Aikido, når du vil have ét værktøj, der dækker kode, afhængigheder, cloud og kørende apps, du i dag bruger andre CI-systemer end GitHub Actions, eller dit compliance-fokus er SOC 2- eller ISO 27001-rapportering ud fra fund fra applikationssikkerhed.
• Vælg CRACI, når du bygger på GitHub Actions og har brug for at vide præcis, hvad hvert build hentede, styre buildets netværksadgang og opbevare release-dokumentation til CRA og kunderevisioner.
• Brug begge, når du vil have Aikidos scanning og blokering af pull requests plus CRACI's kontrol af build-runtimen og dokumentation. Aikidos CI-tjek og Safe Chain kører som trin i dit workflow, og de trin kan køre på en CRACI-runner som alle andre.