CRACI vs OX Security

A resposta curta

O OX Security é uma plataforma de gestão da postura de segurança de aplicações (ASPM) com scanners próprios (SAST, SCA, segredos, IaC e contentores), agregação de conclusões de terceiros, políticas de postura de CI/CD e contexto de runtime e de cloud. Para a segurança da cadeia de abastecimento, oferece o Pipeline Bill of Materials (PBOM): um registo assinado de como cada artefacto foi construído, do commit à produção, passando pela CI/CD.

O CRACI compete pelo mesmo orçamento de cadeia de abastecimento. A diferença está no ponto de observação. O OX liga-se ao controlo de versões, aos sistemas de CI e aos registos que já utiliza e constrói a sua imagem a partir deles. O CRACI é o runner de build para GitHub Actions: regista o que cada job realmente trouxe, aplica uma política de egress durante a execução, monitoriza o que foi distribuído e produz evidências para o CRA. O OX é muito mais abrangente; o CRACI é o próprio build.

Visão geral

O que o OX Security faz bem

• Um registo de build para além da SBOM. O PBOM do OX capta definições de pipeline, identidade do runner, argumentos de build, assinaturas de artefactos e linhagem de versões, e o OX afirma que contém todos os componentes open source resolvidos em cada build. É assinado por build. O OX gera também SBOM em SPDX e CycloneDX.
• Postura de CI/CD. As políticas do OX assinalam ficheiros de workflow inseguros, actions de terceiros não fixadas, comandos obsoletos do GitHub Actions, permissões de workflow excessivas, segredos em texto simples e webhooks de risco, e podem assinalar sistemas de CI não aprovados para builds.
• Aplicação no pipeline. A GitHub Action OX Security Scan executa análises de segredos, SAST, SCA e IaC e faz falhar o workflow quando encontra um problema bloqueante segundo as suas políticas do OX.
• Agregação. O OX integra conclusões de scanners como Checkmarx, Veracode, SonarQube, Snyk, Black Duck e JFrog Xray, a par das suas próprias.
• Ampla cobertura de integrações. Do lado da CI, lista GitHub Actions, GitLab CI/CD, Jenkins, Azure Pipelines, CircleCI e Drone CI, além de oito sistemas de controlo de versões e dez registos de contentores.
• Funcionalidades para a era da IA. O OX VibeSec cobre código e dependências gerados por IA com um AI Bill of Materials, e a remediação por IA sugere correções de código em pull requests e no IDE.

Onde o CRACI é diferente

Registado pelo runner, não recolhido de ferramentas ligadas

A documentação do OX indica que a sua SBOM recolhe dados de origens ligadas, incluindo controlo de versões, pipelines de CI/CD, imagens de contentor e ficheiros importados. Isso dá uma visão ampla de todo o seu parque. O CRACI adota uma visão mais estreita e mais profunda de cada build: um proxy que reconhece pacotes observa o tráfego para origens de pacotes durante a execução do job, em npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência. A evidência das dependências acompanha as caches de CI, pelo que um pacote restaurado de uma cache continua a ser contabilizado.

Cada SBOM do CRACI traz um estado de completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Quando o registo tem uma lacuna, di-lo.

Controlo durante o build

As políticas de postura do OX verificam como um pipeline está configurado. 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. As políticas são validadas antes de o job arrancar e falham em modo fechado, e o CRACI pode alertá-lo em caso de violação.

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

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. Continua a reavaliar as SBOM do que distribuiu à medida que são publicadas novas vulnerabilidades.

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 o reconstituir a partir de notas de lançamento e folhas de cálculo.

Onde o OX está à frente

Para sermos claros: o CRACI não tem análise de SAST, segredos, IaC nem contentores, não tem verificações de postura de CI/CD, não agrega scanners de terceiros e não tem contexto de runtime nem de cloud. Os policy gates do CRACI podem bloquear um build com base em conclusões, mas o CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Se precisa de uma plataforma que abranja todos os pipelines e scanners que utiliza, o OX cobre muito mais.

Qual escolher

O OX Security é a melhor opção quando

• Quer uma plataforma ASPM que agregue muitos scanners e priorize entre eles.
• Precisa de políticas de postura de CI/CD em GitLab, Jenkins, Azure Pipelines ou CircleCI.
• Quer hoje bloquear pull requests com base em conclusões de código, segredos e IaC.

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 obteve, com um estado de completude que possa mostrar a um auditor.
• Quer monitorizar o que foi distribuído e obter evidências para o CRA a partir do mesmo registo.

Usar ambos

O CRACI substitui o runner, não o GitHub Actions, pelo que a action OX Security Scan corre num runner do CRACI como qualquer outro passo. O OX pode importar SBOM em formato CycloneDX, pelo que o CRACI pode fornecer a SBOM registada a partir do build para o OX trabalhar sobre ela.

Para o Cyber Resilience Act

O Cyber Resilience Act pede aos fabricantes que conheçam os componentes de cada produto, tratem as respetivas vulnerabilidades e guardem evidências. As SBOM, o PBOM e as políticas de postura do OX apoiam o desenvolvimento seguro e um inventário de todo o seu parque. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA: SBOM do build exportadas em CycloneDX ou SPDX, acompanhamento de vulnerabilidades e proveniência através da API. Nenhuma das ferramentas lhe dá conformidade por si só. Consulte evidências para o CRA e conformidade com o CRA.

Adicionar o CRACI

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

A ponderar mais do que duas ferramentas? Alternativas ao OX Security compara nove opções lado a lado.