CRACI vs Aikido

Consolidamento contro evidenze

Di solito i team valutano Aikido perché vogliono meno strumenti di sicurezza. Aikido copre dipendenze open source, codice proprietario, secret, infrastructure as code, container, postura del cloud, test dinamici e protezione a runtime in un unico prodotto, con un solo punto in cui fare il triage dei risultati. Per un team piccolo che ha bisogno di un'ampia copertura in tempi rapidi, è un'offerta solida.

I team valutano CRACI per un motivo più specifico. Hanno bisogno di sapere che cosa hanno effettivamente fatto le loro build, di controllare che cosa la build può raggiungere e di produrre per ogni release evidenze che reggano davanti a un cliente o a un auditor. CRACI lo fa essendo esso stesso il runner CI.

Che cosa fa bene Aikido

Il punto di forza è l'ampiezza. Ogni piano Aikido include SCA, SAST, rilevamento dei secret, IaC, postura del cloud, scansione dei container, DAST, scansione delle licenze e generazione di SBOM. La sua SCA usa la raggiungibilità a livello di funzione per ridurre il rumore, e AutoFix apre pull request con versioni corrette. In CI Aikido può bloccare le pull request con rischi critici, e funziona con GitHub, GitLab, Jenkins, Bitbucket, CircleCI e altri. Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap.

Aikido offre anche Safe Chain, uno strumento gratuito che esegue un proxy locale davanti ai package manager npm e PyPI e blocca i pacchetti con malware noto prima che vengano installati, in locale e in CI. Oggi CRACI non blocca i singoli pacchetti. Il blocco dei pacchetti tramite blocklist a livello di organizzazione è nella roadmap di CRACI, non nel prodotto.

Sul fronte della conformità, i piani superiori di Aikido includono report di conformità SOC 2 e ISO 27001 e la sincronizzazione con piattaforme di compliance come Drata e Vanta. Se il Suo obiettivo principale è alimentare un programma SOC 2 con i risultati della sicurezza applicativa, Aikido è progettato per questo.

In che cosa CRACI è diverso

CRACI è il runtime della CI

La protezione a runtime di Aikido difende le applicazioni in esecuzione. CRACI lavora su un runtime diverso: il job di build. I Suoi job GitHub Actions vengono eseguiti su CRACI in macchine virtuali isolate, su runner da 1 a 32 unità di calcolo, su x86-64 o ARM64. La configurazione consiste nel cambiare runs-on in craci. I Suoi workflow restano invariati e le esecuzioni continuano a comparire nell'interfaccia di GitHub.

Poiché è CRACI a eseguire il job, può applicare una policy di egress durante l'esecuzione. Le policy sono a negazione predefinita o ad autorizzazione predefinita, con 24 preset integrati di sorgenti software e sorgenti personalizzate tipizzate per npm, PyPI, apt, apk, il proxy Go, Nix, Cargo, registry OCI e Git. Vengono convalidate prima dell'avvio del job e operano in modalità fail closed. Uno scanner può dirLe che esiste un pacchetto rischioso. Una policy di rete impedisce alla build di raggiungere luoghi che non dovrebbe raggiungere.

Evidenze di build deterministiche

Aikido costruisce la propria vista delle dipendenze a partire da manifest e lockfile e vi aggiunge un'analisi, compresi controlli di sfruttabilità basati sull'IA. È un modo sensato per stabilire le priorità del lavoro.

La SBOM di CRACI non è dedotta. Un proxy che riconosce i pacchetti registra ciò che il job ha scaricato dalle sorgenti dei pacchetti, e le evidenze sulle dipendenze viaggiano con le cache CI, così anche i pacchetti ripristinati da una cache vengono conteggiati. Ogni SBOM dichiara la propria completezza per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. È un record di ciò che è accaduto anziché una stima, e Le dice dove presenta lacune.

Questo conta perché gli strumenti SBOM statici divergono più di quanto la maggior parte delle persone si aspetti, e il motivo è strutturale. Ognuno legge un insieme diverso di file e li risolve in modo diverso, quindi ciò che si dice contenga un repository dipende da quale strumento si è interrogato e da come era configurato. Un progetto che non include alcun lockfile, come express 5.2.1, non dà a un lettore di lockfile proprio nulla da risolvere. CRACI non può essere confrontato in questi termini, perché registra le build anziché scansionare directory, ed è proprio questo il punto: un record di build non dipende da quali file si trovino a essere presenti.

Dati di provenance tramite l'API

CRACI genera la SBOM all'interno del proprio runner, da ciò che il job ha scaricato. L'API restituisce SBOM, tracce di rete e provenance.

Risultati di conformità costruiti su quel record

Per il Cyber Resilience Act dell'UE, la parte difficile è dimostrare che cosa è entrato in ogni release e come ne monitora le vulnerabilità nel tempo. CRACI aggrega le vulnerabilità di tutte le build e di tutti i repository e rivaluta continuamente le SBOM monitorate. Le SBOM si esportano in CycloneDX o SPDX, vulnerabilità incluse, e l'API restituisce SBOM, tracce di rete e provenance. CRACI automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui le aziende hanno bisogno nel loro più ampio processo di conformità al CRA. Veda Conformità al CRA ed Evidenze per il CRA.

Un inventario di che cosa è distribuito e dove

La vista inventario di CRACI mostra con precisione quali versioni del software sono distribuite in quali prodotti, a livello globale. Quando arriva una nuova vulnerabilità, Lei vede quali prodotti eseguono la versione interessata invece di ricostruirlo da note di rilascio e fogli di calcolo.

Dove si colloca ciascuno

• Scelga Aikido se desidera un unico strumento che copra codice, dipendenze, cloud e applicazioni in esecuzione, se oggi usa sistemi CI diversi da GitHub Actions o se la Sua priorità di conformità è la reportistica SOC 2 o ISO 27001 a partire dai risultati della sicurezza applicativa.
• Scelga CRACI se compila su GitHub Actions e ha bisogno di sapere con precisione che cosa ha scaricato ogni build, di controllare l'accesso alla rete delle build e di conservare evidenze sulle release per il CRA e per gli audit dei clienti.
• Usi entrambi se desidera la scansione e il gating delle pull request di Aikido insieme ai controlli sul runtime di build e alle evidenze di CRACI. I controlli CI e Safe Chain di Aikido vengono eseguiti come step nel Suo workflow, e questi step possono girare su un runner CRACI come qualsiasi altro.