Comparação
CRACI vs Finite State
O Finite State constrói um registo do risco do produto a partir de tudo o que entra num dispositivo, incluindo código que não escreveu. O CRACI constrói um registo a partir do único sítio que controla por completo: o seu próprio build.
Atualizado a
A resposta curta
O Finite State é uma plataforma de segurança de produto para dispositivos ligados. Analisa firmware, binários, código-fonte e SBOM de fornecedores, prioriza vulnerabilidades por alcançabilidade e transforma os resultados em evidências para regulamentos como o CRA. O CRACI é um runner de GitHub Actions que regista o que cada build obtém durante a execução, produz a SBOM a partir desse registo e controla a que o build se pode ligar. O Finite State analisa o que distribui, venha de onde vier; o CRACI regista o que o seu próprio build fez. São, em grande medida, complementares.
Visão geral
| Funcionalidade | CRACI | Finite State |
|---|---|---|
| Executa os seus builds | Os jobs correm em runners do CRACI | A sua CI carrega binários ou SBOM para ele |
| Regista o que o build obteve | Observado pelo runner durante cada job | Analisa código-fonte, binários e SBOM de fornecedores |
| Política de egress durante o build | Verificada antes do job, falha em modo fechado | Fora do seu âmbito |
| Análise de binários e firmware | Mais de 50 arquiteturas de conjuntos de instruções binários | |
| SBOM de fornecedores e conclusões de terceiros | É possível adicionar SBOM de fornecedores; sem conclusões de terceiros | Importadas para um único registo do produto |
| Análise de alcançabilidade | Prioriza o que é realmente explorável | |
| Decisões de triagem registadas | Triagem e encaminhamento de conclusões para as equipas | Decisões VEX com estado de explorabilidade |
| SBOM em CycloneDX e SPDX | Por build, com estado de completude | Por versão, a partir de código-fonte e binários |
| Evidências para o CRA | SBOM em CycloneDX ou SPDX, registos via API; sem exportação de relatórios | Mapeamento de controlos do CRA e relatórios para auditoria |
| Sistemas de CI | Hoje GitHub Actions; GitLab CI e Jenkins no roadmap | GitHub Actions, GitLab CI, Jenkins e outros |
- Incluído
- Em parte
- Não incluído
O que o Finite State faz bem
Cobertura de binários e firmware. O Finite State produz SBOM e um inventário de software em firmware, binários e código-fonte, "with support for 50+ binary instruction set architectures." Para um dispositivo que executa código de muitos fornecedores em chips pouco comuns, essa amplitude é o que importa.
Um registo de todos os fornecedores. Reúne firmware, binários, código-fonte, SBOM de fornecedores e conclusões de terceiros numa só plataforma, o que ajuda quando precisa de confrontar o que um fornecedor diz com o que está realmente no produto.
Menos ruído. O Finite State ordena as conclusões por alcançabilidade, informação sobre exploits e contexto do produto. Indica que, desde 2024, 40,5% das conclusões que analisou quanto à alcançabilidade foram confirmadas como inalcançáveis. Regista decisões VEX com o impacto no produto e o estado de explorabilidade.
Evidências de conformidade. O seu workflow de conformidade cobre o mapeamento de controlos do CRA da UE e a manutenção de evidências, e gera relatórios para auditoria com artefactos SBOM e VEX. Aborda também referenciais como as orientações da FDA, o UN R155 e a IEC 62443.
Integrações de CI. O Finite State incorpora verificações em GitHub Actions, GitLab CI e Jenkins. A sua action Binary Scan carrega um binário construído durante a CI para a plataforma Finite State, para uma análise rápida ou completa.
Onde o CRACI é diferente
O Finite State parte dos artefactos: o binário final, a árvore de código-fonte, a SBOM que um fornecedor enviou. O CRACI parte do próprio build, porque o build corre no CRACI.
Observado, não inferido
Altera runs-on para craci, e o job corre numa máquina virtual isolada num runner do CRACI. Um proxy que reconhece pacotes regista o que o job transfere de origens de pacotes, e os pacotes restaurados de caches de CI são mantidos. 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. As fontes que o BitBake obtém do mirror de código-fonte do Yocto são registadas na SBOM do job no CRACI.
Controlo durante o build
Uma análise do resultado não pode alterar 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.
Proveniência e monitorização
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 à medida que surgem avisos de segurança.
O CRACI não analisa binários nem faz análise de alcançabilidade. O seu registo de build cobre os builds que correm nele, e pode adicionar SBOM entregues pelos seus fornecedores. Para firmware de fornecedores que recebe como binário sem SBOM, o Finite State cobre terreno que o CRACI não cobre.
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
- A maior parte do seu firmware vem de fornecedores. Finite State. A análise de binários e a importação de SBOM de fornecedores foram feitas para isso.
- Constrói as suas próprias imagens e aplicações em GitHub Actions. O CRACI regista cada build. Carregue o mesmo artefacto para o Finite State e terá o registo do build e a análise de binários lado a lado.
- Precisa de um sistema de registo para muitos produtos e fornecedores. Finite State. As SBOM do CRACI são exportadas em CycloneDX ou SPDX, formatos que o Finite State aceita através da sua action de carregamento.
- Quer limitar o que os builds podem transferir. CRACI. Esse controlo só existe onde o build corre.
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, a partir de setembro de 2026, que reportem vulnerabilidades ativamente exploradas. O Finite State ajuda a reunir essas evidências para um produto e os seus fornecedores, com mapeamento de controlos do CRA e relatórios. O CRACI ajuda ao produzir evidências por build do que entrou no software que constrói, com 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 ao lado do Finite State
Nada tem de sair do Finite State. Aponte o seu job de build para runs-on: craci, mantenha o passo de carregamento para o Finite State, e o mesmo workflow corre num runner do CRACI enquanto o CRACI o regista. Para Yocto, o
exemplo na documentação do CRACI mostra um workflow BitBake completo. O CRACI suporta hoje apenas GitHub Actions, pelo que os pipelines de GitLab CI ou Jenkins teriam de ser migrados para usar runners do CRACI. O GitLab CI e o Jenkins estão no roadmap. Veja como o CRACI funciona para IoT industrial e
eletrónica de consumo.
A ponderar mais do que duas ferramentas? A página Alternativas ao Finite State compara nove opções lado a lado.
Veja o registo de um dos seus builds
Marque uma demo e executaremos um dos seus builds de firmware em GitHub Actions no CRACI, percorrendo consigo o que ele obteve.
Marcar demo