CRACI vs Aikido

Consolidação versus evidências

As equipas costumam olhar para o Aikido porque querem menos ferramentas de segurança. O Aikido cobre dependências open source, código próprio, segredos, infraestrutura como código, contentores, postura de cloud, testes dinâmicos e proteção em runtime num único produto, com um só lugar para fazer a triagem das conclusões. Para uma equipa pequena que precisa rapidamente de uma cobertura ampla, é uma oferta forte.

As equipas olham para o CRACI por uma razão mais específica. Precisam de saber o que os seus builds efetivamente fizeram, controlar o que o build pode alcançar e produzir evidências sobre cada versão que resistam perante um cliente ou um auditor. O CRACI faz isso sendo ele próprio o runner de CI.

O que o Aikido faz bem

A amplitude é o destaque. Todos os planos do Aikido incluem SCA, SAST, deteção de segredos, IaC, postura de cloud, análise de contentores, DAST, análise de licenças e geração de SBOM. A SCA do Aikido usa alcançabilidade ao nível da função para reduzir o ruído, e o AutoFix abre pull requests com versões corrigidas. Na CI, o Aikido pode bloquear pull requests com riscos críticos, e funciona com GitHub, GitLab, Jenkins, Bitbucket, CircleCI e outros. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap.

O Aikido disponibiliza também o Safe Chain, uma ferramenta gratuita que executa um proxy local à frente dos gestores de pacotes npm e PyPI e bloqueia pacotes com malware conhecido antes de serem instalados, localmente e na CI. O CRACI não bloqueia hoje pacotes individuais. A lista de bloqueio de pacotes ao nível da organização está no roadmap do CRACI, não no produto.

Em matéria de conformidade, os planos superiores do Aikido incluem relatórios de conformidade SOC 2 e ISO 27001 e sincronização com plataformas de conformidade como o Drata e o Vanta. Se o seu objetivo principal é alimentar um programa SOC 2 com conclusões de segurança aplicacional, o Aikido foi feito para isso.

Onde o CRACI é diferente

O CRACI é o runtime de CI

A proteção em runtime do Aikido protege aplicações em execução. O CRACI trabalha num runtime diferente: o job de build. Os seus jobs de GitHub Actions são executados no CRACI em máquinas virtuais isoladas, em runners de 1 a 32 unidades de computação, em x86-64 ou ARM64. A configuração consiste em alterar runs-on para craci. Os seus workflows mantêm-se iguais e as execuções continuam a aparecer na interface do GitHub.

Como o CRACI executa o job, pode aplicar uma política de egress durante a execução. As políticas são de negação por defeito ou de permissão por defeito, com 24 predefinições integradas de fontes de software e fontes personalizadas tipadas para npm, PyPI, apt, apk, o proxy Go, Nix, Cargo, registos OCI e Git. São validadas antes de o job arrancar e falham em modo fechado. Um scanner pode dizer-lhe que existe um pacote de risco. Uma política de rede impede o build de chegar a sítios onde não deve.

Evidências de build determinísticas

O Aikido constrói a sua visão das dependências a partir de manifestos e lockfiles e acrescenta análise por cima, incluindo verificações de explorabilidade baseadas em IA. É uma forma sensata de priorizar o trabalho.

A SBOM do CRACI não é inferida. Um proxy que reconhece pacotes regista o que o job obteve das fontes de pacotes, e as evidências de dependências acompanham as caches de CI, pelo que os pacotes restaurados de uma cache continuam a ser contabilizados. Cada SBOM indica a sua própria completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. É um registo do que aconteceu e não uma estimativa, e indica-lhe onde tem lacunas.

Isto importa porque as ferramentas de SBOM estáticas discordam mais do que a maioria das pessoas espera, e a razão é estrutural. Cada uma lê um conjunto diferente de ficheiros e resolve-os de forma diferente, pelo que aquilo que se diz que um repositório contém depende da ferramenta a que se perguntou e de como foi configurada. Um projeto que não inclui lockfile, como o express 5.2.1, não dá a um leitor de lockfiles nada para resolver. O CRACI não pode ser comparado nesses termos, porque regista builds em vez de analisar diretórios, e é esse o objetivo: um registo de build não depende dos ficheiros que por acaso estejam presentes.

Dados de proveniência através da API

O CRACI gera a SBOM dentro do seu próprio runner, a partir do que o job obteve. A API devolve SBOM, traços de rede e proveniência.

Resultados de conformidade assentes nesse registo

Para o Cyber Resilience Act da UE, a parte difícil é mostrar o que entrou em cada versão e como acompanha as suas vulnerabilidades ao longo do tempo. O CRACI agrega vulnerabilidades de todos os builds e repositórios e reavalia continuamente as SBOM monitorizadas. As SBOM são exportadas em CycloneDX ou SPDX, incluindo vulnerabilidades, e a API devolve SBOM, traços de rede e proveniência. Automatiza uma parte significativa da visibilidade e das evidências da cadeia de abastecimento de software de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA. Consulte conformidade com o CRA e evidências para o CRA.

Um inventário do que está implementado e onde

A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. Quando surge uma nova vulnerabilidade, pode ver que produtos executam a versão afetada, em vez de reconstituir essa informação a partir de notas de versão e folhas de cálculo.

Quando escolher cada um

• Escolha o Aikido quando quiser uma só ferramenta que cubra código, dependências, cloud e aplicações em execução, usar hoje sistemas de CI que não o GitHub Actions, ou quando o seu foco de conformidade for o reporte SOC 2 ou ISO 27001 a partir de conclusões de segurança aplicacional.
• Escolha o CRACI quando fizer build no GitHub Actions e precisar de saber exatamente o que cada build obteve, controlar o acesso à rede do build e guardar evidências das versões para o CRA e para auditorias de clientes.
• Use ambos quando quiser a análise e o controlo de pull requests do Aikido, mais os controlos de runtime de build e as evidências do CRACI. As verificações de CI e o Safe Chain do Aikido correm como passos no seu workflow, e esses passos podem correr num runner do CRACI como quaisquer outros.