Ferramentas SCA open source em 2026: Trivy, Grype e OSV-Scanner postos à prova, e o OpenCVE para vigiar as novas CVE

O que verifica uma ferramenta SCA?

Uma ferramenta SCA, de software composition analysis ou análise de composição de software, lista os pacotes open source que o teu projeto usa, incluindo os que as tuas dependências puxam, e compara cada versão exata com bases de avisos de segurança como a do GitHub e a OSV. Reporta as vulnerabilidades conhecidas, a versão corrigida quando existe e, em algumas ferramentas, a licença de cada pacote.

A lista é mais longa do que o manifesto deixa adivinhar. A 5 de novembro de 2026, o repositório do nosso próprio site declarava 39 pacotes no package.json, 17 dependências e 22 dependências de desenvolvimento, e o pnpm-lock.yaml listava 965. O que se instala é o lockfile, por isso um scanner que só lê o manifesto deixa escapar os outros 926.

O SCA não lê o código que a tua equipa escreve. Isso é trabalho do SAST, e os dois respondem a perguntas diferentes: o SAST procura uma falha no teu código, o SCA procura uma falha publicada num pacote que entregas. Nenhum dos dois vê um pacote malicioso que ainda não tem aviso de segurança, e é por aí que passa o slopsquatting, o ataque aos nomes de pacotes que os modelos de IA inventam.

Que ferramentas SCA open source continuam a ser mantidas em 2026?

O Trivy, o Grype, o OSV-Scanner, o Dependency-Check, o Dependency-Track e o pip-audit lançaram todos uma versão em 2026 e nenhum está arquivado, segundo o GitHub a 5 de novembro de 2026. Os seis usam a licença Apache-2.0. Diferem no que leem, na origem dos dados e no que fazem depois da análise, e o Dependency-Track é uma plataforma que guarda resultados, não um scanner que se corre na CI.

O OSV-Scanner é a porta de entrada da Google para o OSV.dev, uma base num formato aberto que reúne a GitHub Advisory Database, as bases de vulnerabilidades do PyPI e do Go, a RustSec e outras. O Trivy analisa repositórios, imagens de contentores e código de infraestrutura com um só binário. O Grype analisa imagens de contentores, sistemas de ficheiros e SBOM, e lê as listas de pacotes que o Syft, a outra ferramenta da Anchore, constrói. O Dependency-Check e o Dependency-Track são projetos Flagship da OWASP. O pip-audit é mantido sob a alçada da Python Packaging Authority.

Duas ferramentas que muitas vezes aparecem arrumadas no SCA atualizam dependências sem as analisar no mesmo sentido. O Dependabot, cuja biblioteca central tem licença MIT, abre pull requests que atualizam dependências, e o Renovate, com licença AGPL-3.0, faz o mesmo para uma grande variedade de linguagens e plataformas. Mantêm as versões em dia, e nenhum dos dois guarda registo do que entregaste.

O que encontrou cada ferramenta no mesmo repositório?

No nosso teste de 5 de novembro de 2026, cinco ferramentas SCA correram sobre o mesmo repositório, com dependências desatualizadas em quatro ecossistemas, e reportaram juntas 109 vulnerabilidades distintas em 21 pacotes. O OSV-Scanner encontrou 109, o Trivy 105, o Grype 104. O npm audit encontrou as mesmas 43 vulnerabilidades npm que as outras, e o pip-audit as mesmas 21 nos quatro pacotes Python fixados.

Montámos um pequeno repositório que imita o backend de uma loja online, com um serviço por ecossistema e versões de 2020 e 2021 fixadas de propósito:

• uma API Node.js com express 4.17.1, lodash 4.17.20 e axios 0.21.1, e um lockfile de 53 pacotes resolvido no próprio dia;
• um worker Python cujo requirements.txt fixa requests 2.25.0, urllib3 1.26.4, PyYAML 5.3.1 e Jinja2 2.11.2;
• um serviço de faturação em Java cujo pom.xml declara log4j-core 2.14.1 e commons-text 1.9;
• um gateway em Go sobre uma versão de novembro de 2021 do golang.org/x/net e sobre o golang.org/x/text 0.3.7, cujo código chama o parser HTML do primeiro e uma única função de largura do segundo.

Cada ferramenta correu com as definições por omissão. Fundimos os resultados entre identificadores CVE, GHSA, Go e PyPA, com base nos aliases de cada ferramenta e nos da OSV, para que uma vulnerabilidade reportada com dois nomes conte uma só vez.

Os tempos do Trivy e do Grype são de uma segunda execução. Na primeira, cada um gastou a maior parte do tempo a descarregar uma base de vulnerabilidades, 132 MiB no caso do Trivy, e demorou 19,2 s e 101,7 s. O OSV-Scanner consulta o osv.dev online por omissão.

Três diferenças explicam as falhas:

• Um requirements.txt sem lockfile lista quatro pacotes, e nada abaixo deles. O OSV-Scanner resolveu aquilo de que o próprio requests depende e encontrou mais três avisos no idna e no certifi. O Trivy, o Grype e o pip-audit leram as quatro linhas fixadas e ficaram por aí.
• Do lado Java, o log4j-core precisa do log4j-api, e o commons-text do commons-lang3. O Trivy e o OSV-Scanner resolveram os dois e encontraram um aviso em cada; o Grype só leu os dois pacotes declarados.
• Em Go, o Trivy não listou a CVE-2023-44487, a falha HTTP/2 Rapid Reset, no golang.org/x/net, ao passo que o Grype e o OSV-Scanner a listaram.

No npm as quatro ferramentas concordaram nas 43, e 13 delas estão em seis pacotes não declarados que o express puxa: qs, body-parser, path-to-regexp, cookie, send e serve-static. O Log4Shell, CVE-2021-44228, foi encontrado pelo Trivy, pelo Grype e pelo OSV-Scanner, e o JSON do Grype trazia ainda a pontuação EPSS de 0,99999 e a entrada no catálogo CISA Known Exploited Vulnerabilities. Os níveis de gravidade nem sempre batiam certo: para os mesmos resultados, o Trivy marcou quatro como críticos e o Grype cinco.

Trivy, Grype ou OSV-Scanner: qual deves usar?

Escolhe o OSV-Scanner se o teu código tem serviços em Go ou projetos Maven e Python sem lockfile, porque resolveu o que os outros falharam e a análise de chamadas em Go corta ruído. Escolhe o Trivy se queres um só binário para dependências, imagens de contentores, IaC e licenças. Escolhe o Grype se já produzes SBOM com o Syft ou queres os dados EPSS e KEV ao lado de cada resultado.

Os três concordam quando a entrada é um lockfile, como mostram os nossos resultados npm, por isso a escolha depende do que mais analisas e do que fazes com a saída:

• O Trivy serve uma equipa que quer um só scanner na CI para várias camadas. O mesmo comando analisa um repositório, uma imagem ou uma pasta Terraform, e --scanners license acrescenta as licenças. A base descarrega-se uma vez e fica em cache, e é por isso que a nossa segunda execução levou um segundo.
• O Grype serve uma equipa que já constrói SBOM. Analisas o SBOM uma vez no build e de novo mais tarde sem reconstruir nada, e ordenas pelos dados EPSS e KEV que o JSON traz.
• O OSV-Scanner serve uma equipa que dá prioridade à precisão. Resolveu as dependências transitivas de Maven e, no nosso teste, também as de Python, a análise de chamadas em Go está ativa por omissão, e o comando fix sugere atualizações de versão para projetos npm e Maven.

O npm audit e o pip-audit continuam úteis como primeira verificação de quem programa antes de um commit, porque não exigem nada instalado, mas cada um só cobre um ecossistema.

Uma ferramenta SCA diz-te se uma vulnerabilidade é alcançável?

No nosso teste, só o OSV-Scanner o fez, e só para Go. A análise de chamadas, ativa por omissão, marcou 12 das 31 vulnerabilidades Go como chamadas pelo nosso código e 18 como não chamadas; uma não pôde ser analisada. A tabela por omissão listava 13 vulnerabilidades de 31 para o gateway Go, e nada para o golang.org/x/text.

As chamadas batiam com o que o nosso código faz. O gateway usa o parser HTML do x/net, por isso os avisos no parser e no renderizador apareceram como chamados, enquanto os avisos HTTP/2 do mesmo módulo, um caminho de código em que o gateway nunca toca, não apareceram. Os três avisos do x/text estão em funções que o gateway não chama. O OSV-Scanner usa para isto a biblioteca govulncheck, do próprio Go, e --all-vulns faz reaparecer os resultados escondidos. A análise de chamadas em Rust está marcada como experimental e executa os scripts de build das tuas dependências.

Para npm, Python e Java, nenhuma ferramenta open source do nosso teste foi tão longe, e cada resultado conta o mesmo, quer o teu código chame a função vulnerável quer não. É essa a lacuna que a reachability preenche, e é o mesmo problema de triagem que descrevemos em porque é que um scanner reporta 1200 vulnerabilidades quando só 12 são reais. O SCA da CybeDefend trabalha a esse nível: marca cada pacote como usado, potencialmente usado ou não usado, para que os que o teu código chama de facto apareçam primeiro. Como a CybeDefend trata o SCA mostra essa triagem.

Ainda vale a pena correr o OWASP Dependency-Check?

O Dependency-Check 13.0.0 continua mantido e é um projeto Flagship da OWASP, mas no nosso teste parou na primeira atualização da base com "Invalid API Key" e não produziu resultado. O README diz que os utilizadores são "highly" encorajados a obter uma chave de API da NVD e que, sem ela, as atualizações são "extremely slow". Conta com uma chave e uma base em cache antes de o adotares.

Continua a ser uma boa escolha para builds Java e .NET, em que lê os JAR e os assemblies compilados, e os plugins Maven e Gradle correm dentro do build. Há duas coisas que lhe pesam em 2026. Faz a correspondência dos pacotes por identificadores CPE da NVD, e é por isso que a chave conta tanto, e o OSS Index da Sonatype, outra das suas fontes, exige credenciais desde setembro de 2025. Sem elas, diz o README, o Dependency-Check "will automatically disable the OSS Index analyzer".

O que é que as ferramentas SCA deixam escapar?

As ferramentas SCA deixam escapar três coisas: pacotes maliciosos que ainda não têm aviso, vulnerabilidades em código copiado sem gestor de pacotes, e tudo o que nenhum lockfile ou manifesto descreve. Também só reportam problemas conhecidos, por isso um pacote publicado ontem com uma backdoor passa por limpo até alguém registar um aviso.

Os agentes de código acrescentam uma quarta lacuna, que é o momento. O Claude Code, o Cursor ou o Codex podem acrescentar uma dependência a meio de uma tarefa, e a análise na CI corre quando o agente já passou à frente, às vezes já com o pull request aberto. Um agente que consegue ler os resultados do projeto enquanto trabalha pode escolher a versão corrigida logo de início, que é o que descrevemos em dar aos agentes de código acesso em direto a todos os resultados. O VibeDefend entrega ao agente os resultados das dependências do projeto através de MCP enquanto ele escreve, seja o Claude Code, o Cursor, o Codex, o Devin Desktop ou o GitHub Copilot, para que o agente passe para a versão corrigida na mesma sessão. Como funciona o VibeDefend mostra o ciclo.

Entre duas análises: vigiar as novas CVE com o OpenCVE

Uma análise SCA é uma fotografia de um momento. Lista as vulnerabilidades conhecidas das tuas dependências no dia em que corre, e uma CVE publicada na manhã seguinte num pacote que distribuis fica fora de vista até à análise seguinte, a não ser que uma plataforma como o Dependency-Track volte a verificar os SBOM que lá guardaste. Além disso, o SCA só vê o que tu constróis, e nenhum lockfile lista o appliance de VPN ou o servidor de base de dados que a tua equipa tem a correr ao lado do código.

Essa vigilância é o trabalho do OpenCVE. Subscreves os fabricantes e produtos que te interessam, como a Fortinet ou o WordPress, e o OpenCVE avisa-te por e-mail, Slack ou webhook assim que uma CVE que os afeta é publicada ou atualizada. Não há agente para instalar nem nada para analisar. Vai buscar dados ao MITRE, à NVD, ao CISA KEV, à Red Hat e ao Vulnrichment, entre outras fontes, e põe lado a lado o CVSS, o EPSS e o KEV de cada CVE, para distinguires uma falha que os atacantes já exploram de uma que só tem uma pontuação alta. Funciona como serviço cloud com um plano gratuito, ou em auto-alojamento com a edição Community, cujo código está no GitHub sob a Business Source License.

O OpenCVE não é um scanner SCA, porque não lê nenhum lockfile nem analisa nenhum repositório, e é por isso mesmo que os dois se completam: a tua ferramenta SCA diz-te que pacotes usas, e o OpenCVE avisa-te no dia em que uma nova CVE cai num dos produtos que segues.

Como correr SCA na CI e manter uma só lista?

Corre o scanner em cada pull request sobre os lockfiles, gera SARIF para a plataforma de código e um SBOM para o histórico, e só faz falhar o build nas vulnerabilidades críticas ou altas que têm correção. Guarda o SBOM de cada release, porque um aviso novo diz muitas vezes respeito a uma versão que entregaste há meses.

Uma configuração mínima com as ferramentas do nosso teste:

# Em cada pull request: lockfiles, SARIF para o code scanning
osv-scanner scan source -r --format sarif --output-file osv.sarif .
trivy fs --scanners vuln --severity CRITICAL,HIGH --ignore-unfixed --exit-code 1 .

# Em cada release: guardar o SBOM e voltar a analisá-lo mais tarde
trivy fs --format cyclonedx --output sbom.cdx.json .
grype sbom:sbom.cdx.json

O Dependency-Track recebe o ficheiro CycloneDX e continua a vigiar os componentes de cada versão de cada aplicação que guarda, o que responde à pergunta que o auditor faz: que release continha a versão vulnerável, e quando foi corrigida. Para uma equipa que prepara SOC 2 ou ISO 27001, esse histórico conta mais do que a própria análise.

Um segundo scanner acrescenta resultados e duplicados ao mesmo tempo. O nosso teste produziu 451 entradas em cinco ficheiros JSON com cinco esquemas diferentes para 109 vulnerabilidades distintas, o mesmo problema de fusão que encontrámos com seis scanners de segredos open source num repositório com segredos plantados. O CybeDefend Open Source foi feito para esse passo. Corre os scanners que escolheres, qualquer ferramenta que escreva SARIF, e põe o que encontram numa só fila sem duplicados, de graça e nos teus servidores. Chega em breve, e a lista de espera está aberta.

Perguntas frequentes

Qual é a melhor ferramenta SCA open source em 2026?

No nosso teste de 5 de novembro de 2026, o OSV-Scanner 2.7.0 encontrou as 109 vulnerabilidades distintas de um repositório com dependências npm, Python, Maven e Go desatualizadas, o Trivy 0.76.1 encontrou 105 e o Grype 0.121.0 encontrou 104. O OSV-Scanner resolveu mais dependências transitivas; o Trivy cobre mais camadas com um só binário.

O Trivy faz SCA?

Sim. O Trivy procura nos lockfiles e nos manifestos as vulnerabilidades conhecidas dos pacotes open source, o que é análise de composição de software, e também analisa imagens de contentores, código de infraestrutura, segredos e licenças. Tem licença Apache-2.0 e é mantido pela Aqua Security. No nosso teste encontrou 105 de 109 vulnerabilidades e resolveu as dependências transitivas Maven.

Qual é a diferença entre o Trivy e o Grype?

São dois scanners com licença Apache-2.0 que leem repositórios, SBOM e imagens de contentores. O Trivy também analisa IaC, segredos e licenças, e resolveu as dependências transitivas Maven no nosso teste, com 105 vulnerabilidades encontradas. O Grype, que assenta nas listas de pacotes do Syft, encontrou 104, falhou os pacotes transitivos Maven e acrescenta ao JSON as pontuações EPSS e as entradas do catálogo CISA KEV.

O OWASP Dependency-Check precisa de chave de API da NVD?

O README considera a chave muito recomendada e avisa que, sem ela, as atualizações são extremamente lentas. No nosso teste da versão 13.0.0, a 5 de novembro de 2026, a primeira atualização da NVD parou com "Invalid API Key" e nenhuma análise chegou a correr. Pede uma chave à NVD e guarda a base em cache entre execuções da CI.

Qual é a diferença entre SCA e SAST?

O SAST lê o código que a tua equipa escreve e procura padrões vulneráveis, como uma injeção. O SCA lê os teus manifestos e lockfiles e reporta as vulnerabilidades publicadas nos pacotes open source que usas, incluindo os que as tuas dependências puxam. Um projeto precisa dos dois: o lockfile do nosso próprio site lista 965 pacotes para 39 declarados.

O npm audit e o pip-audit chegam?

São uma boa primeira verificação, porque não exigem nada instalado e encontraram as mesmas vulnerabilidades npm e Python que as ferramentas maiores nos pacotes que leem. Cada um só cobre um ecossistema, nenhum escreve SARIF, e o pip-audit corrido sobre um ficheiro requirements sem lockfile só audita as linhas que lá estão.

O que é a reachability no SCA?

A reachability diz-te se o teu código chama a função vulnerável de uma dependência ou se só importa o pacote. No nosso teste, a análise de chamadas em Go do OSV-Scanner marcou 18 das 31 vulnerabilidades Go como não chamadas e tirou-as da tabela por omissão. Para npm, Python e Java, nenhuma das ferramentas open source que corremos fazia essa distinção.

Uma ferramenta SCA avisa-me quando sai uma nova CVE?

Não entre duas análises. Um scanner reporta o que se conhece no dia em que corre, por isso corre-o na CI a cada alteração e de forma agendada, todos os dias por exemplo, para apanhar os avisos publicados entretanto. Para saberes no próprio dia que uma CVE afeta um produto que usas, junta um serviço de monitorização de CVE como o OpenCVE, que avisa por e-mail, Slack ou webhook quando é publicada ou atualizada uma CVE que afeta um fabricante ou produto que segues.