Alternativas ao Cybellum

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 Cybellum

O Cybellum é uma plataforma de segurança do produto para fabricantes de dispositivos nos mercados automóvel, médico e industrial. Os seus Cyber Digital Twins "can be extracted from the binary files of any product or component," e a plataforma funde-os com código-fonte e SBOM "in SPDX, CycloneDX or CPEs CSV formats." Monitoriza versões e branches pós-produção, faz a triagem com um assistente de IA, mostra "which products or components are affected by a new vulnerability or regulation," dá a um PSIRT "a workbench for creating and managing investigations," e partilha o estado "via VEX/CSAF reports." Os modelos regulamentares abrangem a FDA PMA, a ISO 21434 e o CRA da UE. A LG Electronics adquiriu uma participação maioritária em 2021.

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

• A maior parte do software é da própria empresa. Analisar um binário é reconstituir a origem a partir do resultado. Uma equipa que compila o seu próprio software e as suas imagens pode, em vez disso, registar o que entrou nelas.
• Uma tarefa mais específica. Algumas equipas precisam apenas de análise de firmware, apenas de um sistema de registo de SBOM, ou apenas de receção de avisos e gestão de casos, e não de uma plataforma completa de segurança do produto.
• Adequação ao setor. Os modelos do Cybellum privilegiam a regulamentação automóvel e médica; algumas equipas querem uma ferramenta construída em torno de um setor, ou uma que não o seja.
• Preços e alojamento. O Cybellum não publica preços, e algumas equipas querem uma base open source que elas próprias operam.

O que um PSIRT deve avaliar

• Um inventário do que é distribuído: se vem do binário, das SBOM que recebe ou do build.
• Produtos e versões afetados: com que rapidez a ferramenta responde a "onde é que distribuímos este componente?"
• Monitorização após o lançamento, e que fontes de vulnerabilidades acompanha.
• Triagem: sinais de explorabilidade, VEX e encaminhamento de cada conclusão para a equipa responsável pela correção.
• Avisos e notificações: o que pode publicar para os clientes, e as evidências que o Cyber Resilience Act exige.
• Cobertura de CI, opções de alojamento e a forma como os preços escalam.

Para o processo em si, consulte o que faz um PSIRT e ferramentas de PSIRT comparadas.

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 software e firmware. 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.

Para um PSIRT, o CRACI guarda todos os builds anteriores com a respetiva SBOM, pelo que pode ver que builds continham uma dependência vulnerável e durante quanto tempo, e a vista de inventário mostra que versões de software estão implementadas em que produtos. Reavalia continuamente as SBOM monitorizadas, 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.

Indicado para: fabricantes que compilam o seu próprio software e imagens no GitHub Actions e querem o build, a SBOM e o acompanhamento de vulnerabilidades num só lugar. A considerar se: consegue dispensar a análise de binários, a deteção de zero-days, a alcançabilidade e as verificações guiadas face a normas, nenhuma das quais o CRACI tem; não consegue ver o interior de firmware que não compilou. Suporta apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. CRACI vs Cybellum

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.

Indicado para: fabricantes de dispositivos que verificam imagens de firmware que não compilaram, com verificações guiadas face a normas. A considerar se: quer a análise de imagens sem modelos regulamentares para os setores automóvel e médico. 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.

Indicado para: fabricantes de dispositivos conectados que precisam de analisar firmware de muitos fornecedores, com menos ruído de conclusões não alcançáveis. A considerar se: a alcançabilidade for o sinal pelo qual o seu PSIRT faz a triagem. CRACI vs Finite State

4. NetRise

O NetRise Turbine analisa código compilado "to create accurate SBOMs and uncover risk within the software that actually executes" nos dispositivos, e prioriza as vulnerabilidades por alcançabilidade e explorabilidade. O NetRise Provenance analisa a origem, os responsáveis pela manutenção e a saúde dos repositórios dos componentes open source. A Dragos adquiriu a NetRise a 21 de setembro de 2026 e posiciona-a para frotas de tecnologia operacional.

Indicado para: equipas de segurança do produto, de risco de terceiros e de resposta a incidentes, sobretudo na indústria e em infraestruturas críticas, que precisam de saber o que é executado nos dispositivos. A considerar se: a compra sob orçamento lhe servir; a NetRise não publica preços e faz parte da Dragos desde setembro de 2026.

5. 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.

Indicado para: fabricantes dos setores médico, industrial e das telecomunicações que gerem um programa de SBOM em muitos produtos e fornecedores. A considerar se: já tem uma forma de gerar SBOM; o SBOM Studio gere SBOM geradas por outra ferramenta. CRACI vs Cybeats

6. Medcrypt

A Medcrypt dedica-se a fabricantes de dispositivos médicos. O seu produto Helm trata da gestão de SBOM e de vulnerabilidades: pode "upload or manually create SBOMs (CycloneDX or SPDX)" ou ligar o Helm ao seu pipeline através da API, de uma GitHub Action ou da integração com Azure DevOps. O Helm usa EPSS, CISA KEV, ExploitDB e Metasploit para classificar as vulnerabilidades, reavalia-as à medida que chegam dados de correções e exporta SBOM, VDR e VEX. A Medcrypt oferece também serviços como a revisão da modelação de ameaças e apoio nas submissões à FDA.

Indicado para: fabricantes de dispositivos médicos que preparam submissões pré-comercialização à FDA e fazem a gestão de vulnerabilidades pós-comercialização. A considerar se: os seus produtos não forem dispositivos médicos, ou se precisar de análise de binários, que a Medcrypt não descreve.

7. DefectDojo

O DefectDojo é uma plataforma open source de gestão de vulnerabilidades que importa conclusões de "500+ integrations," elimina duplicados e acompanha a correção. O PSIRT Advisory Engine, que faz parte do DefectDojo Pro, recebe avisos da CISA, da NVD, da EUVD e de mais de uma dúzia de outras fontes, cruza-os com os seus dados de SBOM, pontua-os com CVSS, EPSS e KEV, agrupa as correspondências em casos com responsáveis e gera avisos em PDF com a sua marca. O Pro funciona na cloud ou self-hosted.

Indicado para: PSIRT que querem receção de avisos, gestão de casos e acompanhamento de SLA sobre uma base open source de gestão de vulnerabilidades. A considerar se: já tem SBOM com que cruzar os avisos; o DefectDojo não as gera nem analisa binários. A Community Edition é gratuita; o Pro custa $100 por mês mais 15 cêntimos por conclusão (em outubro de 2026).

8. 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.

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

9. Timesys Vigiles

O Vigiles, agora vendido pela Lynx Software Technologies, transforma os metadados de um build Yocto ou Buildroot numa SBOM e cruza-a com uma base de dados de CVE curada. As equipas registam se cada CVE é afetada, corrigida, adiada ou não explorável, o Vigiles guarda essas decisões por versão e exporta SBOM, bem como VEX e relatórios de vulnerabilidades.

Indicado para: equipas de Linux embebido que querem menos ruído de CVE em imagens Yocto e Buildroot. A considerar se: os seus produtos não são construídos sobre Linux embebido. CRACI vs Timesys Vigiles

Lado a lado

"Medcrypt Helm" refere-se ao produto de gestão de SBOM e de vulnerabilidades da Medcrypt, "NetRise" ao NetRise Turbine e "Cybeats" ao SBOM Studio. O Timesys Vigiles está descrito acima e fica fora da tabela. "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 Cybellum, o ONEKEY, o Finite State, o DefectDojo e o Exein descrevem todos suporte para o CRA. As obrigações de notificação do CRA aplicam-se desde 11 de setembro de 2026, e as 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 API do CRACI 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 conformidade com o CRA comparadas.

Quando manter o Cybellum

• Grande parte do seu firmware chega dos fornecedores como binários, e precisa de ver o seu interior.
• Quer binários, código-fonte e SBOM de fornecedores fundidos numa SBOM validada por produto e por versão.
• O seu PSIRT conduz as investigações num só ambiente de trabalho e partilha o estado em relatórios VEX ou CSAF.
• Depende de modelos para a FDA PMA, a ISO 21434 ou o CRA da UE, ou precisa de funcionar no seu próprio datacenter.

Para saber mais, consulte CRACI para equipas de PSIRT, ferramentas de segurança para sistemas embebidos comparadas e alternativas ao Finite State.

Alternativas ao Cybellum: perguntas frequentes

Respostas curtas às perguntas que as equipas fazem quando comparam

Qual é a melhor alternativa ao Cybellum?

Depende daquilo de que o seu PSIRT mais precisa. Para análise de binários de firmware, considere o ONEKEY, o Finite State ou o NetRise. Para um sistema de registo de SBOM em todos os produtos e fornecedores, considere o Cybeats. Para dispositivos médicos e submissões à FDA, considere o Medcrypt. Para receção de avisos e gestão de casos sobre uma base open source de gestão de vulnerabilidades, considere o DefectDojo com o respetivo PSIRT Advisory Engine. Para proteção também no próprio dispositivo, considere o Exein. 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 CRACI consegue analisar binários de firmware como o Cybellum?

Não. O CRACI não analisa binários nem imagens de firmware, e não procura zero-days. 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 respetivos componentes sejam monitorizados, mas sem uma SBOM precisa de uma ferramenta de análise de binários.

Qual destas ferramentas indica a um PSIRT que produtos são afetados por uma nova CVE?

A maioria, a partir de dados diferentes. O Cybellum, o ONEKEY, o Finite State e o NetRise partem da análise dos binários que distribui. O Cybeats, o Medcrypt Helm e o DefectDojo cruzam as SBOM que lhes fornece. O CRACI parte de um registo do que cada build obteve: o histórico de builds mostra que builds continham uma dependência vulnerável, direta ou transitiva, e a vista de inventário mostra que versões de software estão implementadas em que produtos.

Existe uma alternativa gratuita ao Cybellum?

A Community Edition do DefectDojo é gratuita e open source, e agrega e elimina duplicados das conclusões de outros scanners. O PSIRT Advisory Engine, que cruza avisos com os seus dados de SBOM e os agrupa em casos, faz parte do DefectDojo Pro. Nenhuma das edições analisa binários de firmware.

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.