CRACI vs Syft e Grype | SBOM registadas vs SBOM analisadas

A resposta curta

O Syft é um gerador de SBOM open source popular, e o Grype é o scanner de vulnerabilidades que o acompanha. Juntos cobrem a geração e a correspondência gratuitamente, em qualquer pipeline. O CRACI é um runner de GitHub Actions que regista o que cada build obteve, indica se esse registo está completo, controla a que o build se pode ligar e continua a monitorizar o que foi distribuído. A diferença numa linha: o Syft reconstrói a SBOM a partir de ficheiros, e o que encontra depende da sua configuração e do que está no disco quando corre. O CRACI observa-a e acompanha as vulnerabilidades no que registou, pelo que um só produto faz o trabalho dos dois.

Funcionalidade	CRACI	Syft e Grype
Executa os seus builds	Os jobs correm em runners do CRACI	Passos de CLI em qualquer pipeline
Dependências registadas a partir do build	Descargas observadas, incluindo pacotes em cache	Os catalogers leem ficheiros a posteriori
Completude da SBOM	Indicada por job e por cache	Depende dos catalogers executados e do que estava no disco
Política de egress no runner	Negação ou permissão por defeito, falha em modo fechado	Fora do seu âmbito
Evidências assinadas	Sem proveniência assinada	O Syft cria atestações de SBOM in-toto assinadas
Correspondência de vulnerabilidades	Agregadas entre builds e repositórios	Grype, com EPSS, KEV e pontuação de risco
Monitorização das SBOM do que foi distribuído	SBOM monitorizadas reavaliadas continuamente	Nova análise de SBOM com o Grype quando a agendar
Fazer falhar a CI num limiar de severidade	Os policy gates bloqueiam builds por conclusões; limiares não indicados	grype --fail-on
Analisar imagens e diretórios que não construiu	Regista os builds que executa	Imagens, diretórios, arquivos e SBOM
Para além do GitHub Actions	Hoje GitHub Actions; GitLab CI e Jenkins no roadmap	Qualquer CI ou CLI local
Preço	$0.002 por vCPU-minuto ($0.004 com 2 vCPU), medido ao segundo; sem mensalidade nem custos por SBOM	Gratuitos e open source sob Apache-2.0. O Anchore Enterprise é um produto pago à parte.

Incluído
Em parte
Não incluído
No roadmap

O que o Syft e o Grype fazem bem

A página inicial de Syft and Grype — anchore.com

O Syft é "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems." Reconhece dezenas de sistemas de empacotamento, de Alpine, Debian e RPM a Go, Python, Java, JavaScript, Ruby, Rust, PHP e .NET. Escreve CycloneDX, SPDX e o seu próprio Syft JSON, converte entre formatos e pode criar atestações de SBOM assinadas com a especificação in-toto.

O Grype analisa imagens de contentores, sistemas de ficheiros e SBOM em busca de vulnerabilidades conhecidas. Prioriza as conclusões com EPSS, KEV e pontuação de risco, suporta OpenVEX para filtrar resultados, e a sua flag --fail-on faz falhar um pipeline quando encontra vulnerabilidades com uma severidade igual ou superior à que escolher. A Anchore nota que o Grype "runs entirely locally and doesn't send any data to external services", à exceção da descarga da sua base de dados.

Ambos estão sob Apache-2.0 e são patrocinados pela Anchore, cuja plataforma comercial, o Anchore Enterprise, "builds on open source Syft and Grype." Esta página trata das ferramentas open source.

O Syft é forte quando tem à frente os ficheiros certos. Apontado a uma árvore de código-fonte que inclui as suas dependências no repositório, como ollama/ollama, a sua análise por defeito resolve-as com versões, package URLs e as ligações de dependência entre elas.

Uma flag muda a resposta

O Syft escolhe os seus catalogers consoante o tipo de análise, e a sua documentação explica porquê: "files that hint at the intent to install software do not have enough information in them to determine the exact version." Os catalogers têm tags como declared, installed, image e directory, e flags como --select-catalogers e --override-default-catalogers alteram o conjunto.

Em syft cataloger list na v1.51.1, o cataloger de JavaScript que lê node_modules tem tags para análises de imagens e de pacotes instalados e não está no conjunto por defeito para uma análise de diretório. Assim, num checkout com as dependências instaladas, uma flag decide se os pacotes npm em node_modules são sequer lidos. Mesma ferramenta, mesma versão, mesma árvore.

O reverso importa igualmente. Nenhuma configuração está certa em todos os casos:

Num checkout limpo do express 5.2.1, que não tem lockfile, a análise por defeito não tem dependências npm para resolver e devolve o que mais reconhecer, como GitHub Actions e ficheiros de workflow.
Ative os catalogers de pacotes instalados e aponte-os a árvores de código-fonte tal como estão no commit, onde ainda nada foi instalado, e quase não terão nada para ler.
Um repositório sem qualquer manifesto de dependências não dá à análise ficheiros de dependências para ler, seja qual for a configuração.

Nada disto é um bug. O Syft reporta o que os ficheiros à sua frente permitem, tal como foi concebido. A consequência prática é que a SBOM depende de duas decisões que alguém tem de acertar em cada pipeline: que catalogers correm, e se as dependências foram instaladas antes da análise. E o Grype só consegue fazer corresponder o que o Syft listou. Um componente em falta na SBOM nunca chega à consulta de vulnerabilidades, pelo que a análise não deteta nada nele.

Onde o CRACI é diferente

O CRACI não tem catalogers para escolher, porque não lê a árvore a posteriori. Altera runs-on para craci, e um proxy que reconhece pacotes regista o que o job obtém de fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como predefinições de descarga. Os pacotes restaurados de uma cache de CI levam consigo as suas evidências. O resultado, em CycloneDX ou SPDX, inclui as dependências transitivas que o build realmente usou.

A completude é explícita. Cada job e cache é marcado como Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.
O build é controlado. Uma política de egress (negação ou permissão por defeito, 24 predefinições integradas de fontes de software) é validada antes de o job arrancar e falha em modo fechado.
Dados de proveniência. A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência; uma atestação do Syft assina a SBOM.
Monitorização. As SBOM monitorizadas são reavaliadas continuamente, e as conclusões são agregadas entre builds e repositórios.

O Grype continua a fazer coisas que o CRACI não faz. A filtragem VEX e a análise de imagens que não construiu são território do Grype. Os policy gates do CRACI podem fazer falhar o build; os seus alertas por limiar estão 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.

Migrar do Syft e do Grype

No CRACI não há SBOM a gerar nem passo de análise a manter. O runner regista a SBOM enquanto o build corre, e o CRACI continua a verificá-la face a novas vulnerabilidades depois de o build terminar. O Syft e o Grype continuam a ser as ferramentas para imagens e software de terceiros que não construiu, e para pipelines fora do GitHub Actions.

Para o Cyber Resilience Act

O CRA pede aos fabricantes que documentem os componentes de cada produto, incluindo uma SBOM, e que tratem as vulnerabilidades nele presentes. O Syft e o Grype podem produzir e verificar essa SBOM, e a cadeia de evidências de cada versão até à sua SBOM cabe-lhe a si construir. O CRACI regista a SBOM por build e exporta-a em CycloneDX ou SPDX. Automatiza uma parte significativa da visibilidade e das evidências da cadeia de abastecimento de software de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA. Consulte o que é o CRA e a geração de SBOM durante o build.