CRACI vs Aikido

Konsolidace versus důkazy

Týmy se obvykle dívají po Aikidu, protože chtějí méně bezpečnostních nástrojů. Aikido pokrývá open source závislosti, vlastní kód, tajné klíče, infrastrukturu jako kód, kontejnery, stav zabezpečení cloudu, dynamické testování a ochranu za běhu v jednom produktu, s jediným místem pro triáž nálezů. Pro malý tým, který rychle potřebuje široké pokrytí, je to silná nabídka.

Po CRACI se týmy dívají z užšího důvodu. Potřebují vědět, co jejich buildy skutečně dělaly, mít pod kontrolou, kam build dosáhne, a vytvářet ke každému vydání důkazy, které obstojí před zákazníkem nebo auditorem. CRACI to dělá tak, že je přímo CI runnerem.

V čem je Aikido dobré

Hlavním tahákem je šíře. Každý plán Aikido uvádí SCA, SAST, detekci tajných klíčů, IaC, stav zabezpečení cloudu, skenování kontejnerů, DAST, skenování licencí a generování SBOM. Jeho SCA používá analýzu dosažitelnosti na úrovni funkcí ke snížení šumu a AutoFix otevírá pull requesty s opravenými verzemi. V CI umí blokovat pull requesty s kritickými riziky a funguje s GitHubem, GitLabem, Jenkinsem, Bitbucketem, CircleCI a dalšími. CRACI dnes podporuje pouze GitHub Actions, GitLab CI a Jenkins jsou v plánu vývoje.

Aikido nabízí také Safe Chain, bezplatný nástroj, který před správci balíčků npm a PyPI spouští lokální proxy a blokuje balíčky se známým malwarem dřív, než se nainstalují, lokálně i v CI. CRACI dnes jednotlivé balíčky neblokuje. Blokování balíčků v celé organizaci je v plánu vývoje CRACI, nikoli v produktu.

Pokud jde o soulad s předpisy, vyšší plány Aikido zahrnují reporty pro soulad se SOC 2 a ISO 27001 a synchronizaci s platformami pro compliance, jako jsou Drata a Vanta. Pokud je vaším hlavním cílem zásobovat program SOC 2 nálezy z bezpečnosti aplikací, Aikido je pro to stavěné.

Čím se CRACI liší

CRACI je běhové prostředí CI

Ochrana za běhu v Aikidu chrání běžící aplikace. CRACI působí v jiném běhovém prostředí: v jobu buildu. Vaše joby GitHub Actions běží na CRACI v izolovaných virtuálních strojích, na runnerech s 1 až 32 výpočetními jednotkami, na x86-64 nebo ARM64. Nastavení spočívá ve změně runs-on na craci. Vaše workflow zůstávají stejná a běhy se dál zobrazují v rozhraní GitHubu.

Protože CRACI job spouští, může během jeho běhu vynucovat egress policy. Politiky jsou ve výchozím stavu zakazující nebo povolující, s 24 vestavěnými předvolbami softwarových zdrojů a typovanými vlastními zdroji pro npm, PyPI, apt, apk, Go proxy, Nix, Cargo, registry OCI a Git. Ověřují se před spuštěním jobu a jsou fail-closed. Skener vám řekne, že rizikový balíček existuje. Síťová politika zabrání buildu dostat se tam, kam nemá.

Deterministické důkazy z buildu

Aikido sestavuje svůj pohled na závislosti z manifestů a lockfilů a přidává nad něj analýzu, včetně kontrol zneužitelnosti řízených AI. To je rozumný způsob, jak určovat priority práce.

SBOM od CRACI není odvozená. Proxy, která rozumí balíčkům, zaznamenává, co job stáhl ze zdrojů balíčků, a důkazy o závislostech putují spolu s cache CI, takže se započítají i balíčky obnovené z cache. Každá SBOM uvádí svou úplnost pro každý job a každou cache: Complete, Complete with connections, Incomplete, Unavailable nebo Not recorded. Je to záznam toho, co se stalo, nikoli odhad, a říká vám, kde má mezery.

Na tom záleží, protože statické nástroje SBOM se mezi sebou rozcházejí víc, než většina lidí čeká, a důvod je strukturální. Každý čte jinou sadu souborů a vyhodnocuje je jinak, takže to, co repozitář údajně obsahuje, závisí na tom, kterého nástroje jste se zeptali a jak byl nakonfigurován. Projekt, který necommituje žádný lockfile, jako express 5.2.1, nedává čtečce lockfilů vůbec nic k vyhodnocení. CRACI nelze srovnávat za těchto podmínek, protože zaznamenává buildy, místo aby skenoval adresáře, a právě o to jde: záznam buildu nezávisí na tom, které soubory zrovna existují.

Data o původu přes API

CRACI generuje SBOM uvnitř vlastního runneru z toho, co job stáhl. API vrací SBOM, síťové záznamy a údaje o původu.

Výsledky v oblasti souladu postavené na tomto záznamu

U evropského Cyber Resilience Act je nejtěžší doložit, co šlo do každého vydání a jak v čase sledujete jeho zranitelnosti. CRACI agreguje zranitelnosti napříč buildy a repozitáři a průběžně znovu vyhodnocuje monitorované SBOM. SBOM se exportují jako CycloneDX nebo SPDX včetně zranitelností a API vrací SBOM, síťové záznamy a údaje o původu. Automatizuje významnou část přehledu o softwarovém dodavatelském řetězci a důkazů, které firmy potřebují pro svůj širší proces souladu s CRA. Viz soulad s CRA a důkazy pro CRA.

Inventář toho, co je kde nasazeno

Pohled inventáře v CRACI přesně ukazuje, které verze softwaru jsou nasazeny ve kterých produktech, globálně. Když se objeví nová zranitelnost, vidíte, které produkty používají zasaženou verzi, místo abyste to skládali dohromady z poznámek k vydání a tabulek.

Kam které řešení patří

• Zvolte Aikido, když chcete jeden nástroj pro kód, závislosti, cloud i běžící aplikace, dnes používáte jiné systémy CI než GitHub Actions nebo se v oblasti souladu zaměřujete na reporty SOC 2 či ISO 27001 z nálezů bezpečnosti aplikací.
• Zvolte CRACI, když stavíte na GitHub Actions a potřebujete přesně vědět, co každý build stáhl, mít pod kontrolou síťový přístup buildu a uchovávat důkazy o vydáních pro CRA a zákaznické audity.
• Používejte obojí, když chcete skenování a blokování pull requestů od Aikida spolu s kontrolami běhového prostředí buildu a důkazy od CRACI. CI checky a Safe Chain od Aikida běží jako kroky ve vašem workflow a tyto kroky mohou běžet na runneru CRACI jako jakékoli jiné.