CRACI vs NetRise

A resposta curta

O NetRise é uma empresa de análise de binários. O seu produto Turbine analisa firmware, imagens de contentor e binários de aplicações para produzir uma SBOM a partir do código compilado e encontrar nele riscos, incluindo vulnerabilidades, segredos expostos, configurações incorretas e criptografia. A Dragos anunciou a 21 de setembro de 2026 que tinha adquirido a NetRise. O CRACI é um runner de GitHub Actions que regista o que cada build traz durante a execução, produz a SBOM a partir desse registo e monitoriza-a após o lançamento. O NetRise analisa o resultado, incluindo software que não construiu; o CRACI guarda evidências dos builds que executa. Para uma PSIRT, os dois cobrem terreno diferente.

Visão geral

O que o NetRise faz bem

SBOM a partir do código compilado. O NetRise Turbine produz "a complete, binary-derived SBOM from the software itself," incluindo dependências ligadas estaticamente e incorporadas. Cobre firmware, imagens de contentor e binários de aplicações, até kernels, RTOS, controladores e firmware abaixo da camada aplicacional. É essa a forma de ver dentro do software de fabricantes de chips, fornecedores de módulos e outros fornecedores cujos builds nunca vê.

Riscos que uma análise de CVE não mostra. O Turbine reporta segredos, chaves públicas e privadas, certificados e configurações incorretas distribuídos dentro do artefacto, além de problemas de licenças e de um inventário de criptografia para a preparação pós-quântica. O NetRise ZeroLens procura fragilidades em software compilado antes de serem exploradas.

Priorização. O Turbine verifica se um caminho de execução rastreável liga um ponto de entrada em execução a um componente vulnerável e mostra sinais de explorabilidade, como o estado no CISA KEV. A NetRise afirma que a plataforma analisa continuamente a NVD, o catálogo CISA KEV, grupos de atacantes e botnets para obter informação sobre a explorabilidade.

SBOM de fornecedores e integrações. O NetRise suporta a importação, o enriquecimento, a normalização e a exportação de SPDX e CycloneDX, pelo que é possível combinar SBOM de várias origens. Oferece uma API GraphQL para CI/CD e lista integrações com Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub e Google Cloud.

Proveniência de open source. O NetRise Provenance analisa a origem, os responsáveis pela manutenção e a saúde do repositório de componentes open source, e bloqueia pacotes maliciosos ou que violem as políticas no ponto em que os programadores os obtêm, incluindo em CI/CD e em assistentes de programação com IA.

Agora parte da Dragos. O anúncio da Dragos indica que a NetRise acrescenta visibilidade sobre o firmware e o software que correm em dispositivos de tecnologia operacional, e que a liderança da NetRise a integrará na Dragos Platform, continuando a servir os clientes existentes. Não foram divulgados termos financeiros.

Onde o CRACI é diferente

Uma análise de binários trabalha para trás, a partir do que foi distribuído. O CRACI trabalha para a frente, a partir do build, porque o build corre no CRACI.

O build é a fonte da verdade

O seu workflow corre nos runners do CRACI com uma alteração de uma linha em runs-on. Enquanto um job corre, um proxy que reconhece pacotes regista o que ele transfere de origens de pacotes, e os pacotes restaurados de caches de CI continuam a constar do registo. Cada SBOM indica quão completa é, por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Para Yocto, o CRACI executa BitBake em runners de até 32 vCPU e 96 GB de RAM. Num build lado a lado de core-image-sato, a SBOM do CRACI tinha todos os componentes do próprio resultado SPDX do Yocto, mais 88, como pacotes do host e GitHub Actions, e um URL de pacote para cada uma das 653 versões de crates Rust que o Yocto lista sem ele.

Controlo sobre o que o build pode alcançar

Uma política de egress no runner decide a que hosts um job se pode ligar. É validada antes de o job arrancar, falha em modo fechado e envia um alerta em caso de violação. Uma análise do resultado não pode alterar o que o build conseguiu alcançar.

De um CVE aos produtos afetados

O CRACI agrega vulnerabilidades de todos os builds e repositórios e continua a reavaliar as SBOM monitorizadas à medida que surgem avisos de segurança. O histórico de builds mostra que builds continham uma dependência vulnerável, direta ou transitiva, para que saiba durante que período esteve afetado, e a vista de inventário mostra exatamente que versões de software estão implementadas em que produtos. As equipas de segurança fazem a triagem das conclusões e encaminham cada uma para a equipa responsável pela correção, o VEX é suportado, e os policy gates podem bloquear um build que contenha um CVE específico. A API devolve SBOM, traços de rede e proveniência.

O que o CRACI não faz importa tanto como o que faz. Não analisa binários, pelo que não consegue ver dentro de firmware que não construiu nem de um blob de fornecedor que o seu build transfere; apenas sabe que o build o obteve e de onde. Pode adicionar SBOM de fornecedores para que os respetivos componentes sejam monitorizados, mas sem uma SBOM precisa de uma ferramenta de análise de binários como o NetRise. O CRACI não tem análise de alcançabilidade e não procura segredos nem configurações incorretas no resultado.

O que uma PSIRT exige de cada um

Uma equipa de resposta a incidentes de segurança de produto tem de saber o que é distribuído em cada produto, incluindo firmware de terceiros, encontrar os produtos afetados quando surge uma vulnerabilidade, continuar a monitorizar após o lançamento, fazer a triagem das conclusões e indicar que produtos não estão afetados, muitas vezes com VEX.

• Firmware e binários de terceiros que recebe. NetRise. A análise de binários é a única forma de ver dentro deles quando o fornecedor não envia uma SBOM.
• Firmware e software que constrói em GitHub Actions. O CRACI regista cada build durante a execução e guarda o histórico de que builds continham um componente.
• Priorizar uma longa lista de conclusões. Os sinais de alcançabilidade e de explorabilidade do NetRise. O CRACI mostra que um pacote vulnerável estava no build, não se o seu código o chama.
• Encaminhar uma conclusão para a equipa responsável pela correção. A triagem e o encaminhamento do CRACI funcionam sobre os builds que regista; o NetRise liga-se ao Jira e ao ServiceNow.

Consulte o CRACI para equipas de PSIRT e ferramentas de PSIRT comparadas.

Quando usar cada um e quando usar ambos

• A maior parte do que distribui vem de fornecedores. NetRise. Analisa o software que compra e também o que constrói.
• Constrói a sua própria imagem Linux ou aplicações em GitHub Actions. O CRACI executa o build e regista as suas entradas. Analisar a mesma imagem no NetRise dá-lhe uma segunda visão, independente, do que foi distribuído.
• Gere frotas de tecnologia operacional. O NetRise, agora dentro da Dragos, destina-se ao firmware e ao software que correm nesses dispositivos. O CRACI destina-se às equipas que constroem o software.
• Quer limitar o que os builds podem transferir. CRACI. Esse controlo só existe onde o build corre.

Para o CRA

O Cyber Resilience Act pede aos fabricantes que documentem os componentes dos seus produtos, incluindo uma SBOM, que tratem as vulnerabilidades durante o período de suporte e, desde 11 de setembro de 2026, que reportem vulnerabilidades ativamente exploradas. O NetRise aborda o CRA com SBOM de builds de lançamento a partir do artefacto compilado, tratamento de vulnerabilidades e verificação de correções entre versões, e resultados de reporte para evidências de conformidade. O CRACI produz evidências por build do que entrou no software que constrói, monitoriza-o e submete as notificações do CRA em seu nome. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que os fabricantes precisam para o seu processo mais amplo de conformidade com o CRA; não torna um produto conforme por si só. Leia o que exige o CRA.

Adicionar o CRACI ao lado do NetRise

Nada tem de sair do NetRise. Mova o job de build para um runner do CRACI definindo runs-on: craci, e o mesmo workflow continua a correr em GitHub Actions enquanto o CRACI regista o build. O exemplo de Yocto na documentação do CRACI mostra um workflow BitBake completo. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Veja como o CRACI funciona para IoT industrial.

A ponderar mais do que duas ferramentas? Alternativas ao NetRise compara sete opções lado a lado.