Ferramentas de PSIRT comparadas

A resposta curta

• Firmware de fornecedores em binário: ONEKEY, Finite State, NetRise ou Cybellum. A análise de binários é a forma de ver dentro de código cujo build nunca executa.
• Dispositivos automóveis, médicos ou industriais com modelos regulamentares: Cybellum, com modelos para FDA PMA, ISO 21434 e o CRA da UE.
• Dispositivos médicos e submissões à FDA: Medcrypt, com o Helm para SBOM e vulnerabilidades.
• Muitos scanners numa só fila, com um fluxo de avisos de PSIRT: DefectDojo, open source com uma edição Pro.
• Um sistema de registo para SBOM de muitos fornecedores: Cybeats SBOM Studio.
• Imagens Yocto ou Buildroot com dados de CVE curados: Timesys Vigiles.
• Proteção também no dispositivo: Exein.
• Um local gratuito e self-hosted para monitorizar SBOM: OWASP Dependency-Track.
• Software que desenvolve em GitHub Actions: CRACI, que regista a SBOM de cada build, guarda todos os builds anteriores e monitoriza o que foi distribuído.

A quem se destina esta página

Gere ou está a criar uma função de segurança de produto, e está a escolher as ferramentas que a suportam. Se ainda está a definir o papel, comece por o que faz uma PSIRT. Somos nós que desenvolvemos o CRACI, por isso tenha isso em conta. Cada afirmação sobre outro produto vem do seu próprio site ou documentação, verificados em outubro de 2026, e a maioria dos fornecedores aqui presentes tem uma página CRACI vs X mais longa.

O que uma ferramenta de PSIRT tem de fazer

O trabalho segue o ciclo de vida da gestão de vulnerabilidades, e uma PSIRT precisa de apoio em cada passo:

1. Saber o que é distribuído. Uma SBOM por versão do produto, incluindo dependências transitivas e componentes de fornecedores. Tudo o que vem a seguir depende de esta estar completa.
2. Detetar novas vulnerabilidades. Monitorização contínua que cruza novos avisos de segurança com todas as versões lançadas, não apenas com a próxima.
3. Encontrar os produtos afetados. Que produtos, versões e builds contêm o componente, e durante quanto tempo o contiveram.
4. Fazer a triagem e encaminhar. Decidir o que importa e enviá-lo à equipa responsável pela correção.
5. Dizer o que não é afetado. O VEX regista que produtos uma vulnerabilidade afeta e porque é que os outros não são afetados.
6. Receber relatórios e informar as pessoas. Um canal para investigadores externos, acompanhamento de casos e avisos de segurança, muitas vezes em CSAF legível por máquina.

Nenhuma ferramenta abaixo cobre os seis passos por igual. A maioria é mais forte nos dois ou três primeiros, e diferem sobretudo na origem do seu inventário.

Como escolher

• Desenvolve o software ou recebe-o? Se grande parte do produto chega de fornecedores de chips e de outros fornecedores em binário, a análise de binários é a forma de ver lá dentro. Se o desenvolve internamente, o build é a fonte mais direta do inventário.
• O produto é regulamentado? Os dispositivos médicos, os veículos e o equipamento industrial vêm com formatos de submissão e normas. Algumas ferramentas incluem modelos para eles; outras deixam isso para o processo da sua empresa.
• Quantos scanners já utiliza? Se as conclusões chegam de muitas ferramentas, um agregador que elimine duplicados pode importar mais do que outra fonte de conclusões.
• Por onde entram os relatórios externos? As submissões de investigadores precisam normalmente do seu próprio canal (ver abaixo), seja qual for a ferramenta de inventário que escolher.
• Tem de ser self-hosted? O DefectDojo, o Dependency-Track e o Medcrypt Enterprise podem ser executados na infraestrutura da sua empresa, e o Cybellum pode ser executado no seu datacenter.

Visão geral

Duas tabelas: primeiro as ferramentas construídas em torno de firmware e dispositivos, depois as plataformas de gestão de vulnerabilidades e de SBOM. "Não indicado" significa que as páginas de fornecedores que citamos não dizem nem que sim nem que não. A receção de relatórios, a gestão de casos e a publicação de avisos de segurança são tratadas no texto abaixo, e não nas tabelas.

Firmware e dispositivos

Plataformas de gestão de vulnerabilidades e de SBOM

CRACI

O CRACI é um runner de GitHub Actions. Altera runs-on para craci e, enquanto cada job é executado, um proxy que reconhece pacotes regista o que obtém, incluindo pacotes restaurados de caches de CI e dependências que nenhum lockfile lista. A SBOM, em CycloneDX ou SPDX, inclui um estado de completude por job e por cache. O CRACI guarda todos os builds anteriores com a respetiva SBOM, pelo que, quando surge um aviso de segurança, pode ver que builds continham a dependência vulnerável, direta ou transitiva, e durante quanto tempo, dentro do seu período de retenção. A sua vista de inventário mostra exatamente que versões de software estão implementadas em que produtos, a nível global.

Depois do build, o CRACI reavalia continuamente as SBOM monitorizadas, permite às equipas de segurança fazer a triagem das conclusões e encaminhar cada uma para a equipa responsável pela correção, e suporta VEX. Os policy gates podem bloquear um build que contenha um CVE específico, e uma política de egress limita o que o build pode alcançar. Pode adicionar SBOM de fornecedores, para que os componentes adquiridos sejam monitorizados ao lado dos seus próprios builds. Para vulnerabilidades ativamente exploradas, o CRACI submete as notificações do CRA em seu nome. Para Yocto, um build lado a lado de core-image-sato deu uma SBOM com todos os componentes da própria SBOM do Yocto mais 88 que esta não incluía. O preço é apenas por minutos de build: $0.004 por minuto de 2 vCPU, medido ao segundo, sem mensalidade e sem custos por SBOM. Ideal para: PSIRT cujos produtos são compilados em GitHub Actions. A ter em conta: não analisa binários, pelo que o firmware que não compilou precisa de uma SBOM do fornecedor ou de uma ferramenta de análise de binários; não tem análise de alcançabilidade nem exportação de relatórios; e suporta hoje o GitHub Actions, com GitLab CI e Jenkins no roadmap. Consulte CRACI para equipas de PSIRT.

Plataformas de firmware e dispositivos

Cybellum

O Cybellum é uma plataforma de segurança de produto para fabricantes de dispositivos nos mercados automóvel, médico e industrial, detida maioritariamente pela LG Electronics desde 2021. Os seus Cyber Digital Twins são construídos a partir de binários de firmware, e junta-os ao código-fonte e a SBOM de fornecedores em SPDX, CycloneDX ou CPE CSV. Monitoriza versões pós-produção, faz a triagem com um assistente de IA, o VM CoPilot, oferece um espaço de trabalho para criar e gerir investigações com tickets, e partilha o estado das vulnerabilidades através de relatórios VEX e CSAF. Os modelos regulamentares cobrem FDA PMA, ISO 21434, o CRA da UE e mais de 50 normas. É executado em clouds públicas ou no datacenter da sua empresa. Ideal para: fabricantes de dispositivos que precisam de análise de binários e de evidências regulamentares numa só plataforma. A ter em conta: o preço não é publicado, e trabalha a partir de artefactos em vez de executar o seu build. CRACI vs Cybellum e alternativas ao Cybellum

ONEKEY

O ONEKEY analisa firmware compilado sem necessitar de código-fonte nem de acesso à rede. Gera uma SBOM a partir do binário, importa SBOM de fornecedores, procura prováveis zero-days, como credenciais fixas no código, e reanalisa o firmware diariamente. O seu Compliance Wizard acompanha as equipas ao longo do CRA, da IEC 62443-4-2, da ETSI EN 303 645 e da Radio Equipment Directive. Ideal para: equipas que integram muito firmware de fornecedores. A ter em conta: trabalha sobre a imagem depois do build, pelo que não regista o que o build obteve. CRACI vs ONEKEY e alternativas ao ONEKEY

Finite State

O Finite State analisa firmware, binários, código-fonte e SBOM de fornecedores, com suporte para mais de 50 arquiteturas de conjuntos de instruções de binários, e reúne-os num único registo do software distribuído, com monitorização pós-comercialização. Classifica as conclusões por alcançabilidade e por informações sobre exploits, regista decisões VEX e mapeia controlos para os requisitos do CRA e da FDA. Ideal para: PSIRT que precisam de priorizar uma longa lista de conclusões de muitos fornecedores. A ter em conta: parte de artefactos, pelo que controlar o que o build da sua empresa pode alcançar fica fora do âmbito do produto. CRACI vs Finite State e alternativas ao Finite State

NetRise

O NetRise Turbine produz uma SBOM completa, derivada do binário, a partir do próprio software, incluindo código ligado estaticamente e incorporado, para software que desenvolve, compra e opera. Importa SBOM SPDX e CycloneDX, verifica continuamente a NVD, a CISA KEV e dados de agentes de ameaça, classifica as conclusões pela alcançabilidade do caminho de execução e reporta segredos, chaves e configurações incorretas dentro do artefacto, e liga-se ao Jira e ao ServiceNow. A Dragos anunciou a 21 de setembro de 2026 que tinha adquirido a NetRise. Ideal para: tecnologia operacional e frotas de dispositivos cujo software vem de muitos fornecedores. A ter em conta: as suas páginas não descrevem VEX, gestão de casos nem publicação de avisos de segurança, e o preço não é publicado. CRACI vs NetRise e alternativas ao NetRise

Exein

O Exein funciona no dispositivo, além de antes do lançamento. O Exein Runtime usa eBPF para monitorizar e bloquear comportamento malicioso em Linux embebido, e a camada Yocto open source meta-exein coloca o agente Pulsar na sua imagem. O Exein Analyzer analisa firmware, ou a sua SBOM quando o binário não está disponível, prioriza com pontuação de alcançabilidade e mapeia as conclusões para os requisitos do CRA. Ideal para: produtos Linux embebidos que precisam de proteção no terreno. A ter em conta: a camada Yocto altera o que é executado no dispositivo; não executa nem regista o seu build. CRACI vs Exein

Timesys Vigiles

O Vigiles, agora vendido pela Lynx Software Technologies, transforma os metadados de um build Yocto, Buildroot ou OpenWrt numa SBOM e cruza-a com uma base de dados de CVE curada. Os filtros de configuração do kernel e do U-Boot removem CVE em funcionalidades que não compila, as decisões de triagem (afetado, corrigido, adiado, não explorável) são guardadas por versão, as entradas CISA KEV ficam em destaque, e exporta SBOM, VEX e relatórios de vulnerabilidades. Ideal para: equipas de Linux embebido que querem menos ruído de CVE. A ter em conta: a sua SBOM reflete o que os metadados do BitBake dizem que entra na imagem, não tudo o que o build obteve. CRACI vs Timesys Vigiles

Plataformas de gestão de vulnerabilidades e de SBOM

DefectDojo

O DefectDojo é um projeto OWASP Flagship com uma edição comercial Pro. A Community Edition gratuita elimina duplicados nas conclusões dos scanners que já utiliza, mais de 500 ferramentas suportadas segundo as suas contas, e reúne-as numa única fila com responsáveis, SLA e tickets do Jira. O Pro acrescenta a importação de SBOM em CycloneDX e SPDX, a exportação de CycloneDX VEX e um PSIRT Advisory Engine que recebe avisos de segurança de mais de 20 feeds, os cruza com dados de SBOM, os agrupa em casos com responsáveis e publica avisos em PDF com marca própria. A sua versão de setembro de 2026 acrescentou a exportação de avisos CSAF 2.0 e VEX e uma interface de notificação do Artigo 14 do CRA. O Pro começa em $100 por mês mais $0.15 por conclusão processada. Ideal para: PSIRT que querem uma base open source e um fluxo de avisos de segurança. A ter em conta: não gera SBOM por si só, pelo que o inventário só é tão completo quanto o que carregar. CRACI vs DefectDojo e alternativas ao DefectDojo

Medcrypt

A Medcrypt ajuda os fabricantes de dispositivos médicos a fazer passar a sua submissão de cibersegurança pela revisão da FDA, com uma equipa que inclui antigos revisores da FDA. O seu produto Helm importa SBOM CycloneDX ou SPDX por API, GitHub Action ou Azure DevOps, monitoriza-as continuamente, classifica as conclusões com EPSS, CISA KEV e dados de exploits, e exporta relatórios CycloneDX VEX e VDR. O MSI, que inclui o Helm, custa $35,000 por linha de produto por ano, e a sua adesão à MedISAO traz um programa de divulgação coordenada de vulnerabilidades. Ideal para: fabricantes de dispositivos médicos que preparam ou mantêm submissões à FDA. A ter em conta: importa SBOM em vez de as produzir (há uma ferramenta de geração disponível a pedido), e a sua página de preços diz que a FDA é o que a plataforma cobre hoje. CRACI vs Medcrypt

Cybeats

O Cybeats SBOM Studio apresenta-se como "the SBOM system of record." Armazena SBOM dos seus produtos e fornecedores em SPDX 2.2 a 3.0.1 e CycloneDX 1.2 a 1.7, pontua a sua qualidade antes da importação, cruza continuamente cada componente com informações sobre vulnerabilidades, emite VEX e partilha SBOM com clientes, incluindo através da Transparency Exchange API. Ideal para: equipas de segurança de produto em ICS, dispositivos médicos, telecomunicações e automóvel que gerem um programa de SBOM com muitos fornecedores. A ter em conta: para a geração, remete para fornecedores do seu Marketplace, pelo que a própria SBOM vem de outra ferramenta. CRACI vs Cybeats e alternativas ao Cybeats

A opção open source: Dependency-Track

O OWASP Dependency-Track é uma plataforma Apache 2.0 que acompanha componentes em todas as versões de todas as aplicações, obtém dados de vulnerabilidades de fontes como a NVD e os GitHub Advisories, aplica políticas de segurança, de licenças e operacionais, e consome e produz CycloneDX VEX. Os pipelines carregam SBOM através da sua API. É gratuito, e é a sua equipa que o aloja e opera. Ideal para: equipas que querem uma plataforma de análise transparente e self-hosted. A ter em conta: não gera SBOM, pelo que os seus resultados dependem do gerador que executar a montante. CRACI vs Dependency-Track e alternativas ao Dependency-Track

Receção de relatórios, casos e avisos de segurança

As tabelas acima terminam na triagem e no VEX. O resto do trabalho de uma PSIRT, receber relatórios e informar as pessoas, é coberto de forma desigual:

• Relatórios de investigadores externos. Chegam normalmente através de um programa de divulgação de vulnerabilidades. Muitas empresas gerem um numa plataforma como o HackerOne Response ou o VDP do Bugcrowd, que dão aos investigadores um canal para submeter relatórios e ajudam na sua triagem. Outras publicam elas próprias uma política e um contacto de segurança. O nosso guia de divulgação coordenada de vulnerabilidades cobre a política, o security.txt e os prazos.
• Gestão de casos. O Cybellum tem um espaço de trabalho para investigações com tickets. O DefectDojo Pro agrupa os avisos cruzados em casos com responsáveis e acompanhamento de SLA. Nenhum deles diz alojar submissões de investigadores.
• Avisos de segurança. O DefectDojo Pro publica avisos em PDF com marca própria e exporta CSAF 2.0. O Cybellum partilha o estado das vulnerabilidades através de relatórios VEX e CSAF. A adesão à MedISAO da Medcrypt inclui um programa de divulgação coordenada de vulnerabilidades.

Como o CRACI se enquadra

A primeira pergunta em qualquer caso de PSIRT é que produtos e versões contêm o componente vulnerável. A análise de binários responde a partir do que foi distribuído, as plataformas de SBOM a partir das SBOM que lhes entrega, e os agregadores a partir do que outros scanners reportam. O CRACI responde a partir de um registo do que os builds da sua empresa realmente obtiveram, guardado para todos os builds anteriores. Para software que desenvolve em GitHub Actions, isso cobre o inventário, a monitorização, a triagem e o VEX num só produto, pelo que um gestor de SBOM separado, como o Dependency-Track ou o Cybeats, não é necessário para esses builds.

Outras ferramentas ganham noutros pontos. A análise de binários do Cybellum, ONEKEY, Finite State ou NetRise vê dentro de firmware que não compilou. O Cybellum e a Medcrypt trazem modelos regulamentares e experiência em submissões. O DefectDojo agrega conclusões de centenas de scanners e publica avisos de segurança. O Finite State, o NetRise e o Exein classificam as conclusões por alcançabilidade, o que o CRACI não oferece. Leia o que faz uma PSIRT e CRACI para equipas de PSIRT, ou compare ferramentas de conformidade com o CRA e ferramentas de SBOM.

Ferramentas de PSIRT: perguntas frequentes

O que é uma ferramenta de PSIRT?

Software que ajuda uma equipa de resposta a incidentes de segurança de produto a fazer o seu trabalho: saber que componentes são distribuídos em cada versão do produto, detetar quando uma nova vulnerabilidade os afeta, fazer a triagem, encaminhar a correção, registar que produtos não são afetados e informar clientes e autoridades. Poucos produtos cobrem tudo isto. A maioria das PSIRT combina uma ferramenta de inventário e monitorização com um canal para relatórios externos e uma forma de publicar avisos de segurança.

Que ferramenta de PSIRT é melhor para firmware que recebemos em binário?

Uma ferramenta de análise de binários. Cybellum, ONEKEY, Finite State e NetRise constroem uma SBOM a partir do próprio firmware compilado, pelo que conseguem ver dentro de código de fornecedores cujo build nunca executa. O Exein Analyzer também analisa firmware antes do lançamento. O CRACI não analisa binários; para firmware de fornecedores, pode monitorizar a SBOM do fornecedor, se este a disponibilizar.

Que ferramenta de PSIRT se adequa a software que nós próprios desenvolvemos?

Se os seus builds são executados em GitHub Actions, o CRACI regista a SBOM de cada build durante a execução, guarda todos os builds anteriores com a respetiva SBOM, reavalia as SBOM monitorizadas à medida que surgem avisos de segurança e mostra que builds continham uma dependência vulnerável e que versões de software estão implementadas em que produtos. GitLab CI e Jenkins estão no seu roadmap. Para imagens Yocto, o Timesys Vigiles constrói uma SBOM a partir de metadados do BitBake em vez de registar o build.

Existe uma ferramenta de PSIRT gratuita ou open source?

Duas das ferramentas aqui presentes têm edições gratuitas. A DefectDojo Community Edition é gratuita sob a licença BSD 3-Clause e elimina duplicados nas conclusões de centenas de scanners, reunindo-as numa única fila; o seu PSIRT Advisory Engine, a importação de SBOM e a exportação CSAF estão no DefectDojo Pro. O OWASP Dependency-Track é gratuito sob Apache 2.0 e monitoriza as SBOM que carrega. É a sua equipa que aloja e opera ambos.

As ferramentas de PSIRT recebem relatórios de investigadores externos?

Os relatórios de investigadores chegam normalmente através de um programa de divulgação de vulnerabilidades, muitas vezes numa plataforma como o HackerOne ou o Bugcrowd, ou de um contacto de segurança publicado. O DefectDojo Pro recebe avisos de segurança de feeds públicos e o Cybellum oferece um espaço de trabalho para investigações, mas nenhum deles diz alojar submissões de investigadores.

Que ferramentas publicam avisos CSAF?

O DefectDojo Pro acrescentou a exportação de avisos CSAF 2.0 e VEX em setembro de 2026 e publica avisos em PDF com marca própria. O Cybellum partilha o estado das vulnerabilidades através de relatórios VEX e CSAF. Os outros fornecedores desta página não descrevem a publicação de avisos CSAF nas páginas que citamos.

O CRA exige uma ferramenta de PSIRT?

Nenhuma ferramenta é exigida. O Cyber Resilience Act pede aos fabricantes que tratem as vulnerabilidades durante o período de suporte, mantenham uma política de divulgação coordenada de vulnerabilidades e um contacto para relatórios e, desde 11 de setembro de 2026, notifiquem as vulnerabilidades ativamente exploradas no prazo de 24 horas, 72 horas e 14 dias. O CRACI submete essas notificações em nome do fabricante, e o DefectDojo Pro tem uma interface de notificação do Artigo 14 do CRA. A obrigação continua a ser do fabricante.