CRACI vs ReversingLabs Spectra Assure

A resposta curta

O ReversingLabs Spectra Assure analisa pacotes de software compilados, sem código-fonte, em busca de malware, adulteração, segredos expostos, comportamento suspeito e vulnerabilidades, e produz uma SBOM a partir do que encontra. O CRACI é um runner de GitHub Actions que regista o que cada build traz durante a execução, controla o que o build pode alcançar e continua a monitorizar o que foi distribuído. O Spectra Assure é o exame final do resultado; o CRACI é o registo do build. Ambos abordam o risco da cadeia de abastecimento de software, a partir de extremos opostos, e complementam-se bem.

Visão geral

O que o Spectra Assure faz bem

Análise profunda do pacote final. O Spectra Assure usa análise estática de binários para processar pacotes de software grandes e complexos sem código-fonte. O seu suporte de tipos de ficheiro cobre mais de 70 formatos de arquivo, muitos tipos de instaladores e mais de 200 packers de executáveis, e cada ficheiro recebe uma classificação: goodware, suspicious, malicious ou unknown.

Malware e adulteração. Este é o terreno da ReversingLabs. O Spectra Assure usa 16 motores proprietários de deteção de malware, apoiados por uma base de dados de informação sobre ameaças que a ReversingLabs afirma cobrir 400 mil milhões de ficheiros. A análise diferencial integrada compara versões e assinala alterações suspeitas e indícios de adulteração, e é assim que se apanha uma alteração inesperada de comportamento numa versão que construiu por si.

SBOM e mais. O relatório SAFE combina uma SBOM com uma avaliação de risco. A CLI exporta CycloneDX 1.6 e SPDX 3.0.1, e a ReversingLabs gera também vistas ML-BOM, CBOM e SaaSBOM do mesmo pacote.

Software que não construiu. Como trabalha com binários, o Spectra Assure pode avaliar software comercial e de terceiros antes de o implementar, e o Spectra Assure Community, gratuito, verifica pacotes open source e ferramentas de programação amplamente utilizados.

Integra-se em pipelines de lançamento. A CLI rl-secure corre on-premises e em CI, e um Portal alojado gere projetos e versões. As integrações oficiais cobrem GitHub Actions, GitLab CI, Jenkins, Azure DevOps, TeamCity e JFrog Artifactory.

Onde o CRACI é diferente

Uma análise de binários trabalha para trás, a partir do pacote final. O CRACI trabalha para a frente, a partir do build, porque é a máquina onde o build corre.

O build é a fonte da verdade

Com uma alteração de uma linha em runs-on, o seu workflow corre no CRACI. Um proxy que reconhece pacotes regista o que cada job transfere de origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, e os pacotes restaurados de caches de CI continuam a constar do registo. Cada SBOM indica quão completa é, por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Isto inclui o que o build obteve e usou mas não distribuiu, como ferramentas de build e dependências de teste, que uma análise do resultado não vê.

Controlo sobre o que o build pode alcançar

Uma política de egress no runner decide a que hosts um job se pode ligar. É validada antes de o job arrancar, falha em modo fechado e envia um alerta em caso de violação. Uma análise posterior ao build pode encontrar um payload malicioso no resultado; uma política de egress pode impedir que uma dependência comprometida chegue a um host não aprovado durante o build.

Proveniência e monitorização

A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência. Continua a reavaliar as SBOM monitorizadas à medida que surgem avisos de segurança.

O que o CRACI não faz importa tanto como o que faz. Não analisa binários, não deteta malware nem compara o comportamento de duas versões. Se um passo de build injetar código no resultado, o registo do CRACI mostra o que o build obteve e de onde, mas é uma análise de binários que inspeciona o resultado.

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

• Implementa software comercial ou de terceiros. Spectra Assure. O CRACI só consegue registar os builds que nele correm.
• Precisa de provar o que entrou em cada versão. CRACI. O registo vem do runner, com a completude indicada.
• Quer um controlo de lançamento para malware e adulteração. Spectra Assure. Execute-o sobre o artefacto antes de publicar.
• Quer ambas as visões de uma versão. Construa no CRACI e execute a análise do Spectra Assure como um passo do mesmo workflow. O CRACI responde a "o que entrou neste build"; o Spectra Assure responde a "o que está neste pacote". Onde os dois discordarem, tem algo para investigar.

Para o CRA

O Cyber Resilience Act pede aos fabricantes que documentem os componentes dos seus produtos, incluindo uma SBOM, e que tratem as vulnerabilidades enquanto um produto tiver suporte. O reporte de vulnerabilidades ativamente exploradas aplica-se a partir de setembro de 2026. A ReversingLabs inclui o CRA entre os regulamentos que as suas capacidades de SBOM suportam, e a sua análise do pacote que a sua empresa coloca no mercado constitui uma evidência útil. O CRACI acrescenta evidências por build do que entrou nesse pacote, 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 as empresas precisam para o seu processo mais amplo de conformidade com o CRA; nenhuma das ferramentas torna um produto conforme por si só. Leia o que exige o CRA.

Adicionar o CRACI ao lado do Spectra Assure

Mantenha o seu passo de análise do Spectra Assure. Mova o job de lançamento para um runner do CRACI definindo runs-on: craci, e o mesmo workflow continua a correr em GitHub Actions enquanto o CRACI regista o build. As GitHub Actions da ReversingLabs são passos normais de workflow, pelo que a análise fica no mesmo job; se definir uma política de egress, permita os hosts de que o scanner precisa. O CRACI suporta hoje apenas GitHub Actions, pelo que os pipelines de GitLab, Jenkins ou Azure DevOps 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 eletrónica de consumo e SaaS.