CRACI vs Exein | Evidências de build e segurança em runtime

A resposta curta

O Exein desenvolve produtos de segurança para dispositivos embebidos e ligados. O Exein Runtime vigia e bloqueia ameaças no próprio dispositivo, e o Exein Analyzer analisa o firmware em busca de vulnerabilidades antes do lançamento. A sua camada Yocto, meta-exein, coloca o agente de runtime na sua imagem. O CRACI é um runner de GitHub Actions: o seu build Yocto corre nele, e o CRACI regista o que o build transferiu e limita a que se pode ligar. O Exein trabalha no dispositivo e no firmware; o CRACI trabalha no build. A maioria das equipas que precisam de ambos usará ambos.

Visão geral

Funcionalidade	CRACI	Exein
Executa os seus builds Yocto	BitBake em runners de até 32 vCPU	Integra-se no seu pipeline existente
Regista o que o build obteve	Observado pelo runner durante cada job	Analisa o firmware ou uma SBOM que fornecer
Política de egress durante o build	Verificada antes do job, falha em modo fechado	Fora do seu âmbito
Agente de segurança no dispositivo		Exein Runtime, baseado em eBPF
Camada Yocto para a sua imagem	O CRACI executa o build, não acrescenta nada à imagem	meta-exein adiciona o Pulsar à imagem
Análise de firmware binário		Exein Analyzer
Priorização por alcançabilidade		Pontuação de alcançabilidade e filtragem por LLM
SBOM	A partir do build, com estado de completude	Gerada pelo Exein Analyzer
Evidências para o CRA	SBOM em CycloneDX ou SPDX, registos via API; sem exportação de relatórios	Mapeamento de evidências para o CRA no Analyzer

Incluído
Em parte
Não incluído

O que é a integração Yocto do Exein

Os dois produtos confundem-se facilmente porque ambos mencionam o Yocto, por isso vale a pena ser preciso. meta-exein é uma camada Yocto open source que "contains Pulsar and kernel recipes to add the Pulsar security framework to an image." Adiciona a camada a bblayers.conf, acrescenta pulsar a IMAGE_INSTALL e ativa o BTF, e a sua imagem é distribuída com o Pulsar, a ferramenta de segurança em runtime do Exein baseada em eBPF. A camada é testada em versões do Yocto a partir da Kirkstone e tornou-se uma camada oficial Yocto Project Compatible em 2024. O Exein aderiu ao Yocto Project como Platinum Member em 2023.

Por outras palavras, a camada do Exein altera o que corre no dispositivo. Não executa o seu build nem regista o que o build obteve. O Exein afirma também que o Exein Analyzer está "natively integrated into Yocto, Buildroot, and your CI/CD pipeline", de modo a analisar cada novo build, o que é uma análise do resultado do build dentro do seu próprio pipeline.

O que o Exein faz bem

Proteção em runtime no dispositivo. O Exein Runtime é escrito em Rust e usa eBPF para monitorizar e bloquear comportamentos maliciosos ao nível do kernel, "the moment it tries to run." Numa frota, rastreia incidentes e gera relatórios forenses e de conformidade a partir da telemetria de runtime. O Exein publica também como open source o Pulsar, "a modular and blazing fast runtime security tool for the IoT, powered by eBPF".

Análise de firmware antes do lançamento. O Exein Analyzer inspeciona diretamente o firmware final ou importa a sua SBOM quando o binário não está disponível. O Exein afirma que cobre Linux, RTOS, Docker, UEFI, Android e mais, e usa pontuação de alcançabilidade e filtragem por LLM para colocar em primeiro lugar os CVE exploráveis.

Remediação e mapeamento para o CRA. O Exein descreve uma remediação orientada por IA que corre dentro de pipelines Yocto e de CI/CD, e mapeia as conclusões para os requisitos do Cyber Resilience Act.

Onde o CRACI é diferente

Executa o build

Os builds Yocto são longos e pesados. O CRACI executa o BitBake a partir do seu workflow de GitHub Actions em runners de até 32 vCPU e 96 GB de RAM, definidos com cracicorp/setup@v1 e size: "32". Os jobs correm em máquinas virtuais isoladas, e as execuções continuam a aparecer no GitHub.

Regista o que o build obteve

Enquanto um job corre, o CRACI observa o tráfego para hosts de pacotes e de código-fonte e guarda-o como evidência do build, com um estado de completude por job e por cache. Para o Yocto, isso é um relato independente do que chegou pela rede, incluindo o que a SBOM SPDX da classe create-spdx do Yocto deixa de fora: num build lado a lado de core-image-sato, a SBOM do CRACI tinha todos os componentes da 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 URL. As fontes que o BitBake obtém do mirror de código-fonte do Yocto são registadas na SBOM do job no CRACI.

Controla a que o build se pode ligar

O BitBake pode restringir o seu fetcher com BB_ALLOWED_NETWORKS. O CRACI acrescenta uma política de egress no runner, validada antes de o job arrancar e com falha em modo fechado, para que um script ou uma ferramenta que contorne o fetcher continue sem conseguir alcançar um host que não permitiu. O CRACI alerta-o em caso de violação.

Vigia o que foi distribuído

A API devolve SBOM, traços de rede e proveniência. O CRACI agrega vulnerabilidades de todos os builds e repositórios e continua a reavaliar as SBOM monitorizadas.

O CRACI não coloca nada no dispositivo e não analisa binários. Se precisar de proteção em runtime ou de uma análise de uma imagem finalizada, esse é o terreno do Exein.

Um inventário do que está implementado e onde

A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. Quando surge uma nova vulnerabilidade, pode ver que produtos executam a versão afetada, em vez de o reconstituir a partir de notas de lançamento e folhas de cálculo.

Quando usar cada um e quando usar ambos

Quer deteção e bloqueio de ameaças em dispositivos no terreno. Exein Runtime. O CRACI não tem nenhum componente no dispositivo.
Os seus builds Yocto correm num servidor debaixo de uma secretária, ou demoram horas em pequenos runners de CI. O CRACI executa-os a partir do GitHub Actions e guarda um registo de cada um.
Distribui uma imagem Yocto com meta-exein. Construa-a no CRACI. A camada é construída como qualquer outra, e o CRACI regista o que o build obteve.
Precisa de mostrar de onde veio a SBOM. O registo do runner do CRACI liga a SBOM a um build específico. A análise do resultado feita pelo Exein Analyzer é uma segunda perspetiva útil.

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, a partir de setembro de 2026, que reportem vulnerabilidades ativamente exploradas. O Exein ajuda do lado do dispositivo, com análise de firmware antes do lançamento, mapeamento de evidências para o CRA e telemetria de runtime a partir do terreno. O CRACI ajuda do lado do build, com evidências por build do que entrou no firmware, proveniência, monitorização contínua e exportação de SBOM em CycloneDX ou SPDX. 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 a um workflow Yocto

Mantenha as suas camadas, incluindo meta-exein, e o seu passo do Exein Analyzer. Defina runs-on: craci no job de build e escolha um tamanho de runner. O exemplo de Yocto na documentação do CRACI constrói core-image-sato com o mirror oficial de código-fonte do Yocto e uma definição correspondente de BB_ALLOWED_NETWORKS. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Veja como o CRACI funciona para IoT industrial e eletrónica de consumo.