Alternativas ao NetRise

Somos nós que desenvolvemos o CRACI, por isso tenha isso em conta; descrevemos cada opção a partir da sua própria documentação e dizemos quando outra ferramenta é mais adequada.

Porque é que as equipas procuram alternativas ao NetRise

O NetRise Turbine produz "a complete, binary-derived SBOM from the software itself" para firmware, imagens de contentor e binários de aplicações, incluindo dependências ligadas estaticamente e embebidas. Reporta segredos, chaves, certificados, configurações incorretas e problemas de licenças que acompanham o artefacto, classifica as vulnerabilidades consoante um caminho de execução as alcança ou não, e importa e exporta SPDX e CycloneDX. O NetRise Provenance verifica a origem e a saúde dos componentes open source, e o ZeroLens procura fragilidades em software compilado. A 21 de setembro de 2026, a Dragos anunciou que adquiriu a NetRise e que a integrará na Dragos Platform.

Ainda assim, as equipas comparam alternativas, normalmente por uma destas razões:

• A aquisição. A Dragos está a integrar a NetRise na sua plataforma para operadores de infraestruturas críticas. Os fabricantes de dispositivos fora desse mercado podem preferir um fornecedor cujo roadmap se dirija a eles.
• A maior parte do software é da própria empresa. Analisar um binário é fazer o caminho inverso a partir do resultado. Uma equipa que compila as suas próprias imagens pode, em vez disso, registar o que entrou nelas.
• Um fluxo de trabalho de PSIRT. O site da NetRise não descreve VEX, avisos nem investigações de PSIRT. Algumas equipas querem tudo isso na mesma ferramenta que faz a análise.
• Preços. A NetRise não publica preços.

O que um PSIRT deve avaliar

Um PSIRT responde por todos os produtos que a empresa distribui. A ferramenta que o apoia deve ajudar com:

• Um inventário do que é distribuído, incluindo firmware de terceiros que nunca compilou.
• A forma como a SBOM é produzida, e se a ferramenta indica quando está incompleta.
• A identificação rápida dos produtos e versões afetados quando surge uma vulnerabilidade.
• A monitorização após o lançamento, à medida que surgem novos avisos para componentes já distribuídos.
• A triagem, a priorização e o VEX, para poder dizer que produtos não são afetados.
• A cobertura de CI, as opções de alojamento e a forma como os preços escalam.

As opções

1. CRACI (o nosso produto)

O CRACI é um runner de GitHub Actions que produz a SBOM durante a execução do build. Destina-se a equipas que compilam o seu próprio firmware e software. Um proxy que reconhece pacotes regista o que cada job obtém de servidores de pacotes e de código-fonte, incluindo pacotes restaurados de caches de CI, e cada SBOM indica a sua completude por job e por cache. Os builds Yocto são executados em runners com até 32 vCPU e 96 GB de RAM: num build comparativo de core-image-sato, a SBOM do CRACI tinha todos os componentes da SBOM do próprio Yocto e mais 88 que esta não incluía, como pacotes do anfitrião e GitHub Actions, e um package URL para cada uma das 653 versões de crates Rust que o Yocto lista sem ele.

O CRACI reavalia continuamente as SBOM monitorizadas, mostra que builds continham uma dependência vulnerável e que versões de software estão implementadas em que produtos, suporta VEX e permite que as equipas de segurança façam a triagem das conclusões e encaminhem cada uma para a equipa responsável pela correção. Pode adicionar SBOM de fornecedores, para que os componentes adquiridos sejam monitorizados a par dos seus próprios builds. Como é o CRACI que executa o job, também impõe uma política de egress que falha em modo fechado.

Ideal para: fabricantes de dispositivos e equipas de software que compilam no GitHub Actions e querem o build, a SBOM e o acompanhamento de vulnerabilidades num só lugar. Considere se: consegue dispensar a análise de binários, a alcançabilidade e a deteção de segredos no resultado, nenhuma das quais o CRACI tem; este não consegue ver o interior de firmware que a sua empresa não compilou. Suporta apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Consulte CRACI para equipas de PSIRT e CRACI vs NetRise.

2. ONEKEY

O ONEKEY analisa firmware compilado com "no source code or network access needed." Gera uma SBOM a partir do binário, importa SBOM de fornecedores, exporta CycloneDX e SPDX, procura prováveis zero-days, como credenciais embutidas no código, e volta a analisar o firmware diariamente. O seu Compliance Wizard guia as equipas pelo CRA, pela IEC 62443-4-2, pela ETSI EN 303 645 e pela Radio Equipment Directive.

Ideal para: fabricantes de dispositivos que verificam imagens de firmware que não compilaram, com verificações guiadas face a normas. Considere se: quer conclusões para além de CVE conhecidas de um fornecedor focado em produtos conectados. CRACI vs ONEKEY

3. Finite State

O Finite State analisa firmware, binários, código-fonte e SBOM de fornecedores, com "support for 50+ binary instruction set architectures," e reúne-os num único registo de produto. Ordena as conclusões por alcançabilidade, informação sobre exploração e contexto do produto, regista decisões VEX, e o seu fluxo de conformidade abrange o mapeamento de controlos do CRA e relatórios prontos para auditoria com artefactos SBOM e VEX. Integra verificações no GitHub Actions, no GitLab CI e no Jenkins.

Ideal para: fabricantes de dispositivos conectados que precisam de analisar firmware de muitos fornecedores, com as decisões VEX no mesmo lugar. Considere se: quer uma só plataforma para código-fonte, binários e SBOM de fornecedores. CRACI vs Finite State

4. Cybellum

A Product Security Platform do Cybellum cria SBOM "by combining data from binary scanners, source code and external SBOM sources in SPDX, CycloneDX or CPEs CSV formats." A sua gestão de vulnerabilidades faz a triagem e a priorização das conclusões, e pode criar relatórios VEX. Para o trabalho de PSIRT, identifica que produtos ou componentes são afetados por uma nova vulnerabilidade, partilha o estado das vulnerabilidades "via VEX/CSAF reports," e disponibiliza um ambiente de trabalho para criar e gerir investigações. Abrange também a conformidade com requisitos da FDA, a ISO 21434 e o CRA.

Ideal para: fabricantes dos setores automóvel, médico e industrial que querem SBOM, gestão de vulnerabilidades e investigações de PSIRT numa só plataforma. Considere se: o fluxo de trabalho de PSIRT é mais importante para si do que um scanner de binários autónomo. O Cybellum não publica preços.

5. ReversingLabs Spectra Assure

O Spectra Assure analisa pacotes de software compilados, sem código-fonte, em busca de malware, adulteração, segredos expostos e vulnerabilidades, e produz SBOM CycloneDX e SPDX a partir do que encontra. A análise diferencial compara versões e assinala alterações suspeitas entre lançamentos. A CLI rl-secure funciona on-premises e na CI.

Ideal para: um controlo de lançamento contra malware e adulteração no pacote que distribui, ou em software comercial antes de o implementar. Considere se: o seu principal alvo é firmware de dispositivos e não pacotes de software. O Community é gratuito e o Community+ custa $500 por mês (em setembro de 2026). CRACI vs ReversingLabs

6. Exein

O Exein trabalha no dispositivo e no firmware. O Exein Runtime usa eBPF para monitorizar e bloquear comportamentos maliciosos em Linux embebido, e a camada Yocto open source meta-exein coloca o agente Pulsar do Exein na sua imagem. O Exein Analyzer inspeciona o firmware antes do lançamento, ou a sua SBOM quando o binário não está disponível, classifica as conclusões com pontuação de alcançabilidade e filtragem com LLM, e mapeia-as para os requisitos do CRA.

Ideal para: fabricantes de Linux embebido que querem proteção no terreno, além da análise de firmware. Considere se: não se importa de distribuir um agente no dispositivo. CRACI vs Exein

7. Cybeats

O Cybeats SBOM Studio é um sistema de registo que importa, gere, monitoriza e partilha SBOM em todos os produtos e fornecedores. Pontua a qualidade das SBOM na importação e partilha SBOM e VEX com os clientes. Para a geração de SBOM e a análise de composição de binários, o Cybeats remete para fornecedores do seu Marketplace, e o seu add-on RAVEN raciocina sobre a alcançabilidade e redige VEX.

Ideal para: fabricantes dos setores médico, industrial e das telecomunicações que gerem um programa de SBOM em muitos produtos e fornecedores. Considere se: precisa da análise em si; o SBOM Studio gere SBOM geradas por outra ferramenta. CRACI vs Cybeats

Lado a lado

"NetRise" refere-se ao NetRise Turbine, "Cybellum" à Cybellum Product Security Platform, "ReversingLabs" ao Spectra Assure e "Cybeats" ao SBOM Studio. Os preços da ReversingLabs são de setembro de 2026. "Não indicado" significa que a funcionalidade não está descrita na documentação do fornecedor, e não que não exista.

Para o Cyber Resilience Act

O NetRise, o ONEKEY, o Finite State, o Cybellum e o Exein abordam todos o CRA. As obrigações de notificação do CRA aplicam-se desde 11 de setembro de 2026, e as suas principais disposições aplicam-se a partir de 11 de dezembro de 2027. Um alerta precoce em 24 horas depende de saber rapidamente que versões contêm um componente afetado. Para o software que compila, o CRACI guarda o histórico de builds com a SBOM de cada build, pelo que pode ver que builds continham uma dependência vulnerável. A sua API devolve SBOM, traços de rede e proveniência, as SBOM são exportadas em CycloneDX ou SPDX, e o CRACI submete as notificações do CRA em nome da sua empresa.

Nenhuma ferramenta desta página torna, por si só, um fabricante conforme. Consulte o que o CRA exige e ferramentas de PSIRT comparadas.

Quando manter o NetRise

• Precisa de SBOM para o firmware e os binários que compra e também para os que compila, incluindo código ligado estaticamente.
• Quer que os segredos, as chaves, os certificados e as configurações incorretas do artefacto sejam reportados a par das CVE.
• Depende da alcançabilidade por caminho de execução para reduzir a lista de conclusões.
• Gere tecnologia operacional e quer visibilidade do firmware dentro da Dragos Platform.

Para saber mais, consulte builds Yocto no CRACI, alternativas ao ONEKEY e alternativas ao Finite State.

Alternativas ao NetRise: perguntas frequentes

Respostas curtas às perguntas que as equipas fazem quando comparam

Qual é a melhor alternativa ao NetRise?

Depende daquilo para que usa o NetRise. Para análise de firmware com conclusões para além de CVE conhecidas e verificações de conformidade guiadas, considere o ONEKEY. Para firmware, binários, código-fonte e SBOM de fornecedores num único registo de produto com alcançabilidade, considere o Finite State. Para investigações de PSIRT e relatórios VEX ou CSAF sobre análise de binários, considere o Cybellum. Para verificações de malware e adulteração num pacote de versão, considere o ReversingLabs Spectra Assure. Para proteção no próprio dispositivo, considere o Exein. Para gerir SBOM de muitos fornecedores, considere o Cybeats. Se a sua empresa compila o seu próprio software no GitHub Actions, o CRACI regista a SBOM de cada build e monitoriza-a quanto a vulnerabilidades.

O NetRise continua a ser vendido depois da aquisição pela Dragos?

A Dragos anunciou a aquisição da NetRise e da runZero a 21 de setembro de 2026, sem divulgar condições financeiras. A Dragos afirma que a liderança da NetRise a integrará na Dragos Platform e que continuará a servir os clientes existentes, e o site netrise.io ainda apresentava o Turbine, o Provenance e o ZeroLens em outubro de 2026. Pergunte à NetRise ou à Dragos como será vendido daqui em diante.

O CRACI consegue analisar firmware como o NetRise?

Não. O CRACI não analisa binários nem imagens de firmware, não faz análise de alcançabilidade e não procura segredos nem configurações incorretas no resultado. Regista o que os seus próprios builds obtêm durante a execução nos runners de GitHub Actions do CRACI, incluindo builds Yocto, e produz a SBOM a partir desse registo. Para firmware que recebe como binário, pode adicionar a SBOM do fornecedor ao CRACI para que os seus componentes sejam monitorizados, mas sem uma SBOM precisa de uma ferramenta de análise de binários.

Quais destas ferramentas ajudam um PSIRT a encontrar os produtos afetados?

O Cybellum descreve um ambiente de trabalho de PSIRT que identifica que produtos ou componentes são afetados por uma nova vulnerabilidade. O Finite State e o Cybeats mantêm um registo de todos os produtos e fornecedores. O CRACI mostra que builds continham uma dependência vulnerável, direta ou transitiva, e a sua vista de inventário mostra que versões de software estão implementadas em que produtos. As ferramentas de análise de binários, como o NetRise e o ONEKEY, indicam o que está dentro de firmware que não compilou.

Uma SBOM gerada durante o build é melhor do que uma obtida por análise de binários?

Para o software que compila, uma SBOM gerada durante o build regista o que entrou em vez de o deduzir a partir do resultado, o que é difícil em código compilado como Rust e C. A análise de binários continua a ser a única opção para firmware que não compilou. Num build comparativo de core-image-sato, a SBOM do CRACI tinha todos os componentes da SBOM do próprio Yocto e mais 88 que esta não incluía, e um package URL para cada uma das 653 versões de crates Rust que o Yocto lista sem ele.