CRACI vs Apiiro

A resposta curta

O Apiiro é uma plataforma de gestão da postura de segurança aplicacional (ASPM). A Deep Code Analysis do Apiiro mapeia a arquitetura do seu software desde o código até ao runtime, e o Risk Graph correlaciona conclusões dos scanners do próprio Apiiro e de ferramentas de terceiros. O módulo de segurança da cadeia de abastecimento de software (SSCS) inventaria repositórios e pipelines e assinala riscos como proteção de branches fraca, configurações incorretas de pipelines e commits anómalos.

O CRACI disputa o mesmo orçamento de "proteger a nossa cadeia de abastecimento de software" a partir de uma posição diferente: executa os seus jobs de GitHub Actions. O Apiiro raciocina sobre o que o seu código e a configuração do pipeline dizem que vai acontecer. O CRACI regista o que o build fez, controla o seu egress de rede e continua a vigiar o que lançou. Um grande programa de AppSec pode usar ambos. Uma equipa cuja primeira necessidade são evidências do que entrou em cada versão pode começar pelo CRACI.

Visão geral

O que o Apiiro faz bem

• Contexto de arquitetura sem alterações à CI. O Apiiro liga-se ao seu gestor de código-fonte através de uma integração por API e afirma não precisar de configuração nem de manutenção de CI/CD. A Deep Code Analysis mapeia então APIs, dados sensíveis, frameworks de GenAI e responsabilidade pelo código, atualizados a cada commit e a cada alteração relevante.
• Segurança para a programação com IA. O Guardian Agent, lançado em janeiro de 2026, trabalha com assistentes de programação com IA e acrescenta aos prompts dos programadores diretrizes de segurança provenientes dos seus modelos de ameaças, políticas de conformidade e arquitetura, para que o assistente seja afastado de código vulnerável antes de o escrever. O AI Threat Modeling seguiu-se em março de 2026.
• Amplitude. O Apiiro inclui AI SAST nativo, AI SCA, SSCS, segredos, infraestrutura como código, segurança de APIs no código, DSPM para código e modelação de ameaças com IA. O CRACI não faz nenhuma das análises de código dessa lista.
• Priorização. O Risk Graph integra, elimina duplicados e correlaciona conclusões, e depois encadeia-as em "combinações tóxicas". O exemplo do Apiiro: um repositório com dados pessoais, compilado por um pipeline vulnerável, que recebe commits num branch sem revisores obrigatórios. Três conclusões de gravidade média tornam-se um risco crítico.
• Inventário da fábrica de software. O SSCS inventaria repositórios e pipelines de CI/CD, incluindo shadow pipelines, com contribuidores, permissões, plugins e dependências. Acompanha as vulnerabilidades das dependências dos pipelines ao longo do seu ciclo de vida, e as guardrails podem bloquear commits e merges de risco.
• Análise de dependências e correções. A AI SCA verifica se uma função vulnerável é efetivamente chamada, associa dependências a contentores implementados e a endpoints públicos, deteta pacotes maliciosos e aplica políticas de licenças. O AutoFix entrega atualizações de versão que o Apiiro afirma estarem pré-validadas quanto à compatibilidade da API.
• Integrações. GitHub, GitLab, Azure DevOps, Bitbucket e Perforce do lado do controlo de código-fonte, Jenkins e GitHub Actions para a postura dos pipelines, e uma longa lista de scanners, registos e ferramentas de tickets.

Onde o CRACI é diferente

O build é a fonte de verdade

A XBOM do Apiiro é construída através da análise do código: cada pacote, API, modelo de IA e licença, atualizados a cada alteração de código. É uma imagem sólida do que o seu código declara e usa. Um build faz muitas vezes mais do que o código diz. Executa scripts de instalação, descarrega toolchains, restaura caches, obtém imagens base e descarrega binários de lançamento.

O CRACI vê essa atividade porque é o runner. Um proxy que reconhece pacotes observa o tráfego para as fontes de pacotes durante a execução do job, em fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como predefinições de descarga. As evidências de dependências acompanham as caches de CI, pelo que um pacote restaurado de uma cache continua a ser contabilizado. Cada SBOM tem um estado de completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Sabe quando o registo tem uma lacuna.

Controlo no runner, não apenas postura

O Apiiro avisa-o quando um pipeline está mal configurado ou exposto a adulteração. O CRACI limita o que um build pode alcançar enquanto corre. As políticas de egress são de negação ou de permissão por defeito, com 24 predefinições integradas de fontes de software, fontes personalizadas tipadas para npm, PyPI, apt, apk, o proxy Go, Nix, Cargo, registos OCI e Git, e regras explícitas de TLS, TCP, UDP e ICMP. São validadas antes de o job arrancar e falham em modo fechado, e o CRACI pode alertá-lo para uma violação.

Evidências do build através da API

A API devolve SBOM, traços de rede e proveniência.

Depois do lançamento

O CRACI continua a reavaliar as SBOM do que lançou à medida que são publicadas novas vulnerabilidades, e agrega as conclusões de todos os builds e repositórios.

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.

Onde o Apiiro está à frente

Para ser claro: o CRACI não tem análise SAST, de segredos, de IaC nem de segurança de APIs, não integra as conclusões de outros scanners, não audita a proteção de branches nem as permissões dos repositórios, e suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. O CRACI bloqueia builds através de policy gates e aplica políticas de licenças. Se precisa de uma plataforma que priorize o risco em todo o seu código, o Apiiro cobre muito mais terreno.

Qual escolher

O Apiiro é a melhor opção quando

• Quer uma única plataforma de ASPM para muitos scanners, repositórios e sistemas de SCM.
• A sua prioridade é o contexto de arquitetura: que código está exposto à Internet, trata dados pessoais ou mudou de forma relevante.
• Precisa de postura de repositórios e pipelines em GitLab, Azure DevOps, Bitbucket ou Jenkins.

O CRACI é a melhor opção quando

• Faz build no GitHub Actions e quer o runner, a política de egress e o registo de dependências num só lugar.
• Precisa de uma SBOM do que cada build obteve, com um estado de completude que possa mostrar a um auditor.
• Quer monitorização do que foi lançado e evidências para o CRA.

Usar ambos

O Apiiro descreve-se agora como uma solução para proteger o desenvolvimento agêntico. O Guardian Agent orienta os assistentes de programação com IA para código seguro antes de este ser escrito, e a XBOM do Apiiro resulta da análise do código nos seus repositórios. O CRACI é CI/CD com a segurança integrada no runner, pelo que a SBOM do CRACI regista o que cada build efetivamente obteve, incluindo o que a análise de código não consegue ver: scripts de instalação, toolchains, pacotes em cache e imagens base. O Apiiro trabalha onde o código é escrito, o CRACI onde é compilado e lançado. O CRACI substitui o runner, não o GitHub Actions, pelo que qualquer integração do Apiiro com o pipeline continua a funcionar.

Para o Cyber Resilience Act

O Cyber Resilience Act exige que os fabricantes conheçam os componentes de cada produto, tratem as vulnerabilidades neles existentes e guardem evidências. Uma plataforma de ASPM ajuda no desenvolvimento seguro e no tratamento de vulnerabilidades no seu código. O CRACI 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: SBOM geradas durante o build, acompanhamento de vulnerabilidades, proveniência e exportação de SBOM em CycloneDX ou SPDX. Nenhuma das ferramentas torna, por si só, a sua empresa conforme. Consulte conformidade com o CRA.

Adicionar o CRACI

Instale a GitHub App do CRACI na sua organização e, depois, altere a etiqueta do runner de um job para runs-on: craci. As execuções continuam a aparecer na interface do GitHub. Comece por um workflow que produza um artefacto de lançamento e compare a SBOM do CRACI com o seu inventário atual. Saiba mais sobre a integração com CI/CD, a geração de SBOM durante o build e os preços.