CRACI vs Cybellum

A resposta curta

O Cybellum é uma plataforma de segurança de produto para fabricantes de dispositivos nos mercados automóvel, médico e industrial. Analisa binários de firmware, combina-os com código-fonte e SBOM de fornecedores, cruza o resultado com dados de vulnerabilidades e apoia o trabalho que um PSIRT faz após o lançamento: monitorização, triagem, investigações e evidências regulamentares. O CRACI é um runner de GitHub Actions que regista o que cada build descarrega durante a execução, produz a SBOM a partir desse registo e continua a monitorizá-la.

A primeira pergunta em qualquer caso de PSIRT é que produtos e versões contêm o componente vulnerável. O Cybellum responde a partir da análise do que a sua empresa distribui, venha de onde vier. O CRACI responde a partir de um registo do que os seus próprios builds realmente obtiveram. Para o software que compila em GitHub Actions, o CRACI cobre o inventário, a monitorização e a própria triagem. Para o firmware que recebe como binários, o Cybellum cobre terreno que o CRACI não cobre.

Visão geral

O que o Cybellum faz bem

Análise do binário. Os Cyber Digital Twins do Cybellum "podem ser extraídos dos ficheiros binários de qualquer produto ou componente." A plataforma analisa os binários de firmware de cada produto para revelar "SBOM, histórico de versões, licenças, arquitetura de HW, configurações de SO e mais," e só pergunta como extra: "Também tem o código-fonte?" Isso importa quando grande parte de um veículo ou dispositivo médico executa código de fornecedores cujos builds nunca vê.

Uma SBOM a partir de muitas fontes. O Cybellum combina "dados de scanners de binários, código-fonte e fontes externas de SBOM nos formatos SPDX, CycloneDX ou CPEs CSV," elimina pacotes idênticos duplicados e permite às equipas corrigir automaticamente, validar e aprovar SBOM para qualquer produto, versão ou branch antes de as partilhar em SPDX ou CycloneDX.

Conclusões para além de CVE conhecidos. A sua base de dados de vulnerabilidades combina fontes públicas e privadas, EPSS e resultados de investigação, e o Cybellum acrescenta "motores integrados de deteção de malware e de fragilidades de código." As equipas podem importar modelos de ameaças, TARA, resultados de fuzzing e de testes de intrusão, e depois fazer a triagem com um assistente de IA, o VM CoPilot.

Criado para o trabalho de PSIRT. O seu módulo de resposta a incidentes permite a uma equipa "ver exatamente que produtos ou componentes são afetados por uma nova vulnerabilidade ou regulamento," dá-lhe "uma bancada de trabalho para criar e gerir investigações," abre tickets e partilha o estado das vulnerabilidades "através de relatórios VEX/CSAF, conforme necessário."

Evidências regulamentares. O Cybellum gere evidências para "FDA PMA, ISO 21434, CRA, bem como os seus próprios referenciais de políticas personalizados," com requisitos pré-mapeados de "mais de 50 normas, regulamentos e boas práticas." É executado em clouds públicas ou no seu próprio datacenter. A LG Electronics comprou uma participação maioritária no Cybellum em 2021, e o Cybellum continua como marca própria.

Onde o CRACI é diferente

O Cybellum parte de artefactos: a imagem de firmware, a árvore de código-fonte, a SBOM que um fornecedor enviou. O CRACI parte do próprio build, porque o build é executado no CRACI.

Observado, não inferido

Basta mudar runs-on para craci e o job é executado numa máquina virtual isolada num runner do CRACI. Um proxy que reconhece pacotes regista o que o job descarrega de fontes de pacotes, e os pacotes restaurados de caches de CI são mantidos no registo. Cada SBOM indica quão completa é, por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. As equipas de firmware podem executar Yocto 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 da própria saída SPDX do Yocto, mais 88, como pacotes do host e GitHub Actions, e um package URL para cada uma das 653 versões de crates Rust que o Yocto lista sem ele.

Que builds e produtos um CVE atingiu

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 vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. O CRACI reavalia continuamente as SBOM monitorizadas, suporta VEX e permite às equipas de segurança fazer a triagem das conclusões e encaminhar cada uma para a equipa responsável pela correção. Pode adicionar SBOM de fornecedores, pelo que os componentes comprados são monitorizados a par dos seus próprios builds.

Controlo durante o build

Uma análise do resultado não pode mudar o que o build conseguiu alcançar. A política de egress do CRACI pode: é de negação ou de permissão por defeito, validada antes de o job arrancar, falha em modo fechado e envia um alerta em caso de violação. Os pontos de controlo de políticas também podem parar um build que contenha um CVE específico.

Aquilo de que abdica com o CRACI

O CRACI não analisa binários, pelo que não lhe pode dizer o que está dentro de um blob de fornecedor que o seu build descarrega, apenas que o build o obteve e de onde. Não procura zero days, a análise de código-fonte em busca de fragilidades de código está fora do seu âmbito, e não tem verificações guiadas face a normas nem exportação de relatórios. Suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap, e funciona como runners geridos em infraestrutura europeia, com runners alojados pelo cliente no roadmap.

Quando usar cada um

• A maior parte do seu firmware vem de fornecedores como binários. Cybellum. A análise do binário é a forma de ver lá dentro.
• Compila o seu próprio software e imagens em GitHub Actions. O CRACI executa o build, regista as respetivas entradas e acompanha as vulnerabilidades do que registou, pelo que o inventário do PSIRT vem do próprio build.
• Precisa de evidências para submissões regulamentares no setor automóvel ou médico. O Cybellum tem modelos regulamentares para FDA PMA, ISO 21434 e o CRA da UE. O CRACI exporta SBOM em CycloneDX ou SPDX, e a sua API devolve SBOM, traços de rede e proveniência, para o seu processo mais amplo.
• Quer limitar o que os builds podem descarregar. CRACI. Esse controlo só existe onde o build é executado.

Para o CRA

O Cyber Resilience Act pede aos fabricantes que identifiquem e documentem os componentes dos seus produtos, incluindo uma SBOM, que tratem as vulnerabilidades durante o período de suporte e que, a partir de setembro de 2026, comuniquem as vulnerabilidades ativamente exploradas. O Cybellum ajuda com modelos e evidências do CRA em todos os produtos e fornecedores. O CRACI ajuda produzindo evidências por build do que entrou no software que compila, com monitorização contínua e exportação de SBOM em CycloneDX ou SPDX, 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 o CRA exige.

Executar os seus builds no CRACI

Aponte o seu job de build para runs-on: craci e o mesmo workflow continua a correr em GitHub Actions enquanto o CRACI o regista. Para Yocto, o exemplo na documentação do CRACI mostra um workflow BitBake completo. Veja como o CRACI funciona para a IoT industrial e a eletrónica de consumo.

É novo na função? Leia o que faz um PSIRT e CRACI para equipas PSIRT. Está a avaliar mais de duas ferramentas? Consulte ferramentas de PSIRT comparadas e as alternativas ao Cybellum.