Já analisa as suas dependências. Eis o que um scanner não consegue ver.

O que a sua stack atual faz bem

Se tem a SCA e a geração de SBOM configuradas, já fez o trabalho organizacional difícil: as dependências são acompanhadas, os avisos de segurança chegam aos programadores e há um ficheiro para entregar quando alguém o pede. Mantenha isso.

• O grafo de dependências e o Dependabot do GitHub estão ativos por predefinição para muitas equipas. O GitHub descreve o grafo de dependências como um resumo dos ficheiros de manifesto e de lockfile guardados num repositório e de quaisquer dependências submetidas para o repositório através da dependency submission API. Os alertas do Dependabot assentam nele e notificam-no quando é publicado um novo aviso de segurança ou quando o seu grafo de dependências muda.
• A SCA comercial, como o Snyk, também gera SBOM. O seu comando snyk sbom lê os ficheiros de manifesto e os respetivos lockfiles, e emite CycloneDX ou SPDX. Em setembro de 2026, o Snyk documenta-o como disponível apenas para clientes dos planos Snyk Enterprise.
• Os geradores open source, como Syft, Trivy e cdxgen, são gratuitos, rápidos e fáceis de adicionar à CI. O Syft descreve-se como uma ferramenta para gerar uma Software Bill of Materials (SBOM) a partir de imagens de contentor e sistemas de ficheiros.

Estas ferramentas são mais fortes no feedback rápido em pull requests, na cobertura alargada de ecossistemas e num fluxo de remediação que os programadores já conhecem. O CRACI não substitui isso hoje. O seu acompanhamento de vulnerabilidades agrega conclusões entre builds e repositórios e reavalia as SBOM monitorizadas à medida que surgem novas vulnerabilidades. As equipas de segurança podem fazer a triagem das conclusões e enviá-las à equipa certa. Os policy gates podem bloquear um build; os webhooks de vulnerabilidades estão no roadmap.

Scanner versus registador

Todas as ferramentas acima são scanners. Aponta-as a uma árvore de código-fonte, a um lockfile ou a uma imagem de contentor, e elas deduzem o que entrou. Isso funciona quando os ficheiros contam a história toda. Torna-se mais difícil quando não contam:

• O repositório não tem lockfile, pelo que as versões são decididas no momento da instalação.
• O build restaura pacotes de uma cache de CI que nenhum manifesto menciona.
• Um passo de build transfere diretamente uma ferramenta, um pacote do sistema operativo ou um binário.
• Um install hook do npm ou um build script de Rust obtém mais código durante a instalação, a via usada pelo worm Shai-Hulud.
• Um build de contentor obtém uma imagem base e as respetivas camadas do sistema operativo, que nenhum lockfile de linguagem lista.
• O que distribui é um binário compilado, e o manifesto ao lado dele não lista quase nada.

O CRACI é um registador: vê o tráfego, e os scanners não. Executa o build no seu próprio runner compatível com GitHub Actions, e um proxy que reconhece pacotes observa o tráfego para fontes de pacotes enquanto o job é executado, pelo que estas dependências ocultas entram na SBOM. Os pacotes restaurados de uma cache transportam a sua evidência. Não existe nenhum comando craci scan ./dir, porque analisar um diretório a posteriori é precisamente o passo que o CRACI existe para evitar.

De que depende uma análise

O resultado de um scanner depende da ferramenta e daquilo a que é apontada. Syft, Trivy, cdxgen, o Microsoft SBOM Tool, a exportação do grafo de dependências do GitHub e a Socket CLI determinam cada um a lista a partir do que conseguem ler. Os padrões abaixo vêm da forma como a documentação destas ferramentas descreve o seu funcionamento.

Nenhum componente é encontrado por todas as ferramentas

Cada gerador decide por si o que conta como componente e em que ficheiros confiar, pelo que o mesmo checkout dá a cada um deles uma lista diferente. A exportação do grafo de dependências do GitHub funciona ainda de outra forma: é construída a partir do que o GitHub sabe sobre o repositório, e não de ficheiros lidos por um scanner, e lê o branch predefinido em vez de um commit fixado.

Sem lockfile, sem dependências

O Express 5.2.1 não inclui nenhum lockfile no repositório. Apontado a um checkout limpo, um gerador que resolve dependências a partir de lockfiles ou de uma árvore instalada não tem nenhum deles à sua frente, pelo que nenhuma das dependências npm declaradas em package.json chega ao documento. Nenhuma ferramenta aqui está avariada. A variável que decide se a SBOM contém sequer alguma dependência não é a ferramenta. É se alguém executou uma instalação primeiro.

Uma flag muda a resposta

A análise de diretórios predefinida do Syft reporta o que um projeto declara, não o que está instalado em disco. Num checkout instalado da mesma versão do express, uma flag de catalogador decide se os pacotes npm instalados aparecem sequer na lista. A mesma ferramenta, a mesma versão, a mesma árvore.

O produto é um binário

O repositório anthropics/claude-code em v2.1.259 não tem nenhum manifesto de dependências nem lockfile de qualquer tipo. O seu pacote npm publicado declara zero dependências de runtime e envolve um binário nativo pré-compilado através de oito pacotes de plataforma. O @openai/codex 0.149.1 tem a mesma forma. Um leitor de manifestos quase nada tem para descrever, enquanto o programa que é executado é um binário compilado, pelo que aquilo que cada ferramenta devolve diz mais sobre a ferramenta do que sobre o projeto.

O mesmo pacote, versões diferentes

Quando duas ferramentas encontram a mesma coisa, nem sempre concordam sobre o que é. Uma pode fixar uma GitHub Action a um SHA de commit enquanto outra reporta uma tag de versão. Uma consulta de vulnerabilidades baseada na versão errada devolve uma resposta errada com toda a confiança.

Onde o CRACI se enquadra ao lado da sua SCA

Mantenha a sua SCA nos pull requests. É o sítio certo para apanhar uma versão vulnerável antes do merge. Acrescente o CRACI onde a pergunta é sobre o build e não sobre o diff:

• O que continha realmente esta versão? A SBOM registada cobre fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de descarga, incluindo dependências transitivas. Os mirrors JFrog Artifactory para npm e PyPI também funcionam.
• Podemos confiar na lista? Cada job e cada cache têm um estado de completude, pelo que um registo incompleto fica visível em vez de passar despercebido.
• Somos afetados por um novo aviso de segurança? As SBOM monitorizadas são reavaliadas à medida que são publicadas novas vulnerabilidades, e as conclusões são agregadas entre builds e repositórios.

A SBOM é transferida em CycloneDX através da API REST pública, juntamente com o traço de rede do job e a proveniência, pelo que pode alimentar qualquer ferramenta que leia CycloneDX, incluindo a SCA que já usa. A configuração é uma linha no workflow: altere runs-on para craci. O GitHub Actions é a CI suportada hoje; GitLab CI, Jenkins e outros sistemas de CI 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.

Saiba mais sobre a geração de SBOM durante o build e o acompanhamento de vulnerabilidades.