CRACI vs Xygeni

A resposta curta

O Xygeni é uma plataforma de segurança de aplicações de Valladolid, Espanha. Descreve-se como "one AI-powered platform that detects, prioritizes, and remediates vulnerabilities and malware end-to-end". Os seus módulos cobrem SAST, SCA com alcançabilidade e deteção de malware, segredos, IaC, contentores, segurança de CI/CD, segurança de build com atestações SLSA e in-toto, deteção de anomalias, DAST, segurança de API e uma camada de ASPM. Publica os seus preços e tem um plano gratuito. Não executa builds: liga-se aos sistemas de CI que já utiliza.

O CRACI compete pelo mesmo orçamento de cadeia de abastecimento a partir de outro lugar. É o runner para GitHub Actions: regista os pacotes que cada job realmente trouxe, aplica uma política de egress enquanto o job corre e continua a monitorizar o que foi distribuído. O Xygeni é muito mais abrangente em AppSec; o CRACI vai mais fundo no build e no que dele resultou.

Visão geral

"Não indicado" significa que não o conseguimos confirmar nas páginas públicas do Xygeni.

O que o Xygeni faz bem

• Amplitude numa só plataforma. SAST com correção automática por IA, SCA com alcançabilidade e pull requests de atualização automáticos, deteção de segredos com revogação automática, análise de IaC e de imagens de contentor e, no Enterprise, DAST, segurança de API e ASPM com ingestão de dados de terceiros.
• Malware em open source. O Xygeni afirma analisar todos os dias milhares de pacotes open source novos e atualizados, usa um motor assistido por ML para detetar malware desconhecido, coloca pacotes suspeitos em quarentena e pode bloqueá-los com uma firewall de dependências. Isto vai além de cruzar CVE.
• Segurança de CI/CD. Procura configurações incorretas em scripts de build e pipelines, aborda os riscos OWASP Top 10 CI/CD, verifica definições como a proteção de branches e a autenticação multifator, e assinala comandos nocivos em pipelines, como reverse shells e transferências de malware.
• Atestações de build. O Build Security acrescenta uma linha a um pipeline para recolher evidências de cada fase do build e gerar proveniência SLSA e atestações in-toto, assinadas com assinaturas keyless. As atestações podem conter análises de vulnerabilidades, SBOM em SPDX ou CycloneDX e resultados de testes, e os artefactos adulterados podem ser bloqueados antes da entrega.
• Deteção de anomalias. Sensores para GitHub, GitLab, Jenkins e Azure vigiam alterações não autorizadas a código, dependências, pipelines e configuração de build, e alertam em tempo real.
• Ampla cobertura de CI e preços publicados. O Xygeni lista integrações com GitHub, GitLab, Jenkins, Azure Pipelines, Bitbucket, CircleCI e Travis CI, e oferece implementação on-premise no Enterprise.

Onde o CRACI é diferente

Registado a partir do build, não lido de descritores

A documentação do Xygeni diz que os seus analisadores processam descritores de dependências para extrair dependências diretas e indiretas e resolver as respetivas versões. É a forma habitual de construir uma SBOM a partir de um repositório. O CRACI vê, em vez disso, o tráfego que entra em cada build: um proxy que reconhece pacotes regista cada pacote que o job obteve de origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência. Os pacotes restaurados de caches de CI ficam no registo.

É assim que o CRACI regista as dependências ocultas que as ferramentas baseadas em lockfiles não veem: código transferido por hooks de instalação npm, scripts de build em Rust que obtêm dados durante o build e as camadas da imagem base de um build de contentor. Cada SBOM traz um estado de completude por job e por cache (Complete, Complete with connections, Incomplete, Unavailable ou Not recorded), pelo que, quando o registo tem uma lacuna, di-lo.

Controlo durante o build

As verificações de CI/CD do Xygeni olham para a forma como os pipelines estão configurados e para os comandos que contêm. O CRACI limita o que o build pode alcançar. As políticas de egress são de negação ou de permissão por defeito, com 24 predefinições integradas de origens de software, origens personalizadas tipadas para npm, PyPI, apt, apk, o proxy de 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. Como uma política de negação por defeito permite apenas aquilo de que o build precisa, um pacote comprometido que tente enviar os seus segredos para um host desconhecido é bloqueado, mesmo num ataque que ninguém viu antes, e o CRACI alerta-o para a violação.

Proveniência e monitorização a partir de um único registo

O Xygeni assina atestações a partir de um passo acrescentado ao seu pipeline. O registo do CRACI vem do runner onde o job correu: a API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência e não reivindica nenhum nível SLSA. O CRACI continua a reavaliar as SBOM do que distribuiu à medida que são publicadas novas vulnerabilidades e mostra todos os builds anteriores que continham uma dependência vulnerável, para que saiba durante quanto tempo esteve exposto.

O runner faz parte do produto

Como o CRACI é o runner, as evidências vêm com a computação: as execuções continuam a aparecer no GitHub, e o CRACI executa builds cerca de duas vezes mais depressa do que os runners alojados no GitHub, graças a hardware mais rápido, tempos de fila mais curtos e cache. O CRACI cobra apenas os minutos de build, $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU), medido ao segundo, sem mensalidade nem custos por SBOM. Consulte os preços do CRACI.

Qual se adequa melhor

O Xygeni é a melhor opção quando

• Quer uma plataforma de AppSec para SAST, SCA, segredos, IaC, contentores e configuração de pipelines.
• Quer que os pacotes open source maliciosos sejam detetados e bloqueados antes de existir um aviso de segurança.
• Constrói em GitLab, Jenkins, Azure Pipelines, Bitbucket, CircleCI ou Travis CI.
• Precisa de atestações SLSA e in-toto ou de uma implementação on-premise.
• Uma equipa pequena quer começar num plano gratuito com preços publicados.

O CRACI é a melhor opção quando

• Constrói em 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 realmente obteve, com um estado de completude que possa mostrar a um auditor.
• Quer monitorizar o que foi distribuído e ter o histórico de builds a partir do mesmo registo.

Do que abdica ao mover as evidências de build para o CRACI

Para o software que constrói em GitHub Actions, o CRACI assume a função da exportação de SBOM do Xygeni: o registo, os dados de proveniência e a monitorização vêm do runner. Para sermos claros quanto ao que isso custa: o CRACI não tem análise de alcançabilidade, não deteta novos pacotes maliciosos pelo comportamento ou pela reputação (assinala versões maliciosas conhecidas depois de publicado um aviso de segurança com CVE), não abre pull requests de atualização, não assina a proveniência, não reivindica nenhum nível SLSA, não tem deteção de anomalias no controlo de versões e executa hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap.

As verificações de SAST, segredos, IaC e postura de CI/CD do Xygeni cobrem terreno em que o CRACI, por conceção, não toca, pelo que podem ficar onde estão. O CRACI substitui o runner, não o GitHub Actions, pelo que um passo de análise corre num runner do CRACI como qualquer outro passo.

Para o Cyber Resilience Act

O Cyber Resilience Act é um de vários referenciais que pedem uma SBOM e um processo de tratamento de vulnerabilidades. O Xygeni lista verificações de conformidade da cadeia de abastecimento de software face a CIS e OpenSSF no seu plano Business. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento e das evidências de que um processo do CRA precisa: SBOM do build exportadas em CycloneDX ou SPDX, acompanhamento de vulnerabilidades e proveniência através da API. Consulte evidências para o CRA. Nenhuma das ferramentas torna um produto conforme por si só.

Para outras plataformas nesta área, consulte CRACI vs Cycode, CRACI vs OX Security, CRACI vs Wiz e ferramentas de segurança da cadeia de abastecimento de software.

Xygeni: perguntas e respostas

O que é o Xygeni?

O Xygeni é uma plataforma de segurança de aplicações de Valladolid, Espanha. Combina scanners próprios (SAST, SCA com alcançabilidade e deteção de malware, segredos, IaC, contentores, segurança de CI/CD e, opcionalmente, DAST e segurança de API) com uma camada de ASPM, além de segurança de build com atestações SLSA e in-toto e deteção de anomalias em sistemas de controlo de versões e de CI.

Quanto custa o Xygeni?

Em setembro de 2026, a página de preços do Xygeni apresenta um plano gratuito com SAST, SCA, segredos e um plugin de IDE para até 10 repositórios, 200 análises por mês e 5 contribuidores. O Team começa em cerca de $3,828 (€3,300) por ano e o Business em cerca de $6,844 (€5,900) por ano, ambos com 10 contribuidores incluídos, e o Enterprise tem preço sob orçamento. Um contribuidor é qualquer pessoa que tenha feito commits num repositório analisado nos últimos 90 dias. O Build Security e o Anomalies Detection são opções do Enterprise.

O Xygeni fornece runners de CI?

Não. O Xygeni integra-se com os sistemas de CI que utiliza, como GitHub, GitLab, Jenkins, Azure Pipelines, Bitbucket, CircleCI e Travis CI, e acrescenta scanners próprios e um passo de atestação aos seus pipelines. O CRACI é o runner: os jobs de GitHub Actions correm no CRACI, que regista o que cada job obteve e controla o que pode alcançar.

Qual é a diferença entre o Xygeni e o CRACI?

O Xygeni é uma ampla plataforma de AppSec que analisa código, dependências, segredos, IaC e configuração de pipelines em muitos sistemas de CI. O CRACI é um runner de GitHub Actions que regista os pacotes que cada build realmente obteve, aplica uma política de egress durante a execução e continua a monitorizar o que foi distribuído. O Xygeni é muito mais abrangente; o CRACI regista o próprio build.

O CRACI pode substituir o Xygeni?

Para as evidências de build do software que constrói em GitHub Actions, sim: a SBOM registada, a proveniência e a monitorização de vulnerabilidades do CRACI cobrem essa função. O CRACI não substitui o SAST, os segredos, o IaC, as verificações de postura de CI/CD, a deteção de malware nem a análise de alcançabilidade do Xygeni, e executa hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap.