CRACI vs Kusari

A resposta curta

O Kusari é uma plataforma de segurança da cadeia de abastecimento de software da equipa que cocriou o GUAC, o grafo open source para metadados da cadeia de abastecimento. Constrói um grafo de conhecimento atualizado continuamente a partir do seu código-fonte, SBOM, documentos VEX e resultados dos scanners existentes, ordena o que é explorável, revê pull requests e abre correções. O CRACI é um runner de GitHub Actions. Regista o que cada build obtém durante a execução, controla o que o build pode alcançar e continua a monitorizar o que foi distribuído. Qualquer grafo reflete as SBOM que recebe; o CRACI produz SBOM a partir do próprio build. Os dois competem pelo mesmo orçamento de cadeia de abastecimento. Para o software que constrói, o CRACI cobre a CI, a SBOM e o acompanhamento de vulnerabilidades num só produto.

Visão geral

Kusari e GUAC, com precisão

O GUAC (Graph for Understanding Artifact Composition) é um projeto em incubação da OpenSSF, no grupo de trabalho Supply Chain Integrity, com licença Apache 2.0. Agrega metadados de segurança de software numa base de dados em grafo. As suas entradas documentadas incluem SBOM CycloneDX e SPDX, atestações in-toto e SLSA, documentos OpenVEX e CSAF, resultados do OpenSSF Scorecard e dados do OSV e do deps.dev. O GUAC agrega metadados que outras ferramentas produzem; não executa builds.

Os cofundadores do Kusari cocriaram o GUAC com a Google, e um cofundador do Kusari é o maintainer principal do GUAC. O Kusari afirma usar e fazer a curadoria do GUAC, do SLSA, do OpenSSF Scorecard, do ClearlyDefined e de outros projetos open source nos seus produtos comerciais. O GUAC tem também outros contribuidores, incluindo a Google, a Red Hat, a Purdue University e o Citi. O Kusari é a plataforma comercial; o GUAC é o projeto comunitário.

O que o Kusari faz bem

Um grafo construído a partir de normas abertas. A plataforma do Kusari importa código-fonte, artefactos de build, SBOM CycloneDX e SPDX, VEX e resultados dos scanners existentes, incluindo do Snyk, do Black Duck, do Prisma Cloud, do Dependabot e do GitHub Advanced Security. Mapeia dependências diretas e transitivas com proveniência e linhagem, e mostra o raio de impacto de uma nova vulnerabilidade em todo o seu parque.

Menos conclusões, e melhores. A análise de alcançabilidade e de explorabilidade procura evidências de que o código vulnerável é realmente chamado, para que a fila contenha o que importa. O AutoFix gera pull requests de correção e valida-os antes de chegarem ao seu repositório.

Verificações no pull request. O Kusari Inspector revê cada pull request no GitHub ou no GitLab em busca de vulnerabilidades transitivas, segredos expostos, pacotes maliciosos e de typosquatting, risco de licenças, dependências em fim de vida, workflows de GitHub Actions inseguros e fragilidades comuns do código. O Kusari afirma que o Inspector é gratuito de instalar, sem necessidade de contacto com vendas.

Normas e referenciais. O Kusari produz SBOM e atestações nos formatos SPDX, CycloneDX e in-toto, e indica suporte para referenciais como o CRA da UE, FDA 524B, SSDF, IEC 62443 e DORA. O seu uploader funciona em GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, Bitbucket Pipelines e TeamCity.

Onde o CRACI é diferente

O Kusari descreve o seu grafo como construído a partir do código-fonte e dos sistemas de build à medida que o software é criado, em vez de reconstruído a partir de binários finais. É o instinto certo, e é também onde os dois produtos divergem. As SBOM do Kusari vêm de um gerador: a sua documentação descreve gerá-las com o waybill, o seu conjunto de ferramentas open source de SBOM, quando os pull requests são integrados, ou trazer a sua própria ferramenta. Um gerador lê lockfiles, manifestos, caches e imagens. O CRACI não lê os ficheiros do build para inferir o que ele usou. É a máquina em que o build corre.

Um registo, não uma reconstrução

Com uma alteração de uma linha a runs-on, o seu workflow corre no CRACI. Um proxy que reconhece pacotes regista o que cada 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. A monitorização parte do que o build realmente obteve e sabe onde estão as lacunas.

Controlo durante o build

Um grafo ajuda a encontrar o que foi afetado a posteriori. Uma política de egress no runner decide, enquanto o job corre, que hosts pode alcançar. As políticas do CRACI são de negação ou de permissão por defeito, com 24 predefinições integradas de origens de software, são validadas antes de o job arrancar e falham em modo fechado.

Proveniência e monitorização a partir do mesmo registo

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.

O CRACI não faz o que distingue o Kusari: não importa outros scanners, não analisa a alcançabilidade nem revê pull requests em busca de pacotes maliciosos e fragilidades do código. Suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap.

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.

Substituir o Kusari pelo CRACI

Para o software que constrói e distribui, o CRACI cobre aquilo para que uma plataforma de grafos é normalmente comprada. Executa o build, regista a SBOM com uma completude indicada, continua a reavaliar as SBOM monitorizadas à medida que são publicadas novas vulnerabilidades, agrega as conclusões de todos os builds e repositórios e permite às equipas de segurança fazer a triagem e encaminhar cada uma para a equipa responsável pela correção. A política de egress limita desde logo o que um build pode alcançar, algo que nenhum grafo consegue fazer.

Tenha bem presente aquilo de que abdica. O Kusari liga um grafo entre muitos scanners e fontes de SBOM, importa VEX, analisa a alcançabilidade e revê pull requests em busca de pacotes maliciosos, segredos expostos e fragilidades do código. O CRACI não faz nada disso hoje e suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Se a sua principal necessidade é correlacionar conclusões de muitas ferramentas existentes, o Kusari continua a ser a opção mais adequada.

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. O Kusari liga SBOM, VEX e conclusões num só grafo e inclui o CRA entre os referenciais que suporta. O CRACI produz as evidências por build e continua a monitorizá-las: a partir de que foi construída cada versão, 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.

Migrar para o CRACI

Defina runs-on: craci nos workflows que constroem o que distribui. O CRACI substitui o runner, não o GitHub Actions, e as execuções continuam a aparecer na interface do GitHub. Saiba mais sobre a geração de SBOM durante o build e o acompanhamento de vulnerabilidades.

A ponderar mais do que duas ferramentas? A página Alternativas ao Kusari compara nove opções lado a lado.