Herramientas SCA open source en 2026: Trivy, Grype y OSV-Scanner a prueba, y OpenCVE para vigilar las CVE nuevas

¿Qué comprueba una herramienta SCA?

Una herramienta SCA, de software composition analysis o análisis de composición de software, hace la lista de los paquetes open source que usa tu proyecto, también los que traen tus dependencias, y compara cada versión exacta con bases de avisos de seguridad como la de GitHub y OSV. Te devuelve las vulnerabilidades conocidas, la versión corregida cuando existe y, en algunas herramientas, la licencia de cada paquete.

La lista es más larga de lo que sugiere el manifiesto. El 5 de noviembre de 2026, el repositorio de nuestra propia web declaraba 39 paquetes en su package.json, 17 dependencias y 22 dependencias de desarrollo, y su pnpm-lock.yaml listaba 965. Lo que se instala es el lockfile, así que un escáner que solo lee el manifiesto se pierde los otros 926.

El SCA no lee el código que escribe tu equipo; eso es trabajo del SAST, y cada uno responde a una pregunta distinta. El SAST busca un fallo en tu código, el SCA busca un fallo publicado en un paquete que tú distribuyes. Ninguno de los dos ve un paquete malicioso que todavía no tiene aviso, y por ahí se cuela el slopsquatting, el ataque a los nombres de paquetes que se inventa un modelo de IA.

¿Qué herramientas SCA open source siguen mantenidas en 2026?

Trivy, Grype, OSV-Scanner, Dependency-Check, Dependency-Track y pip-audit han publicado versión en 2026 y ninguna está archivada, según GitHub a 5 de noviembre de 2026. Las seis usan licencia Apache-2.0. Se diferencian en lo que leen, en el origen de sus datos y en lo que hacen tras el escaneo, y Dependency-Track es una plataforma que guarda resultados, no un escáner que se lanza en CI.

OSV-Scanner es la puerta de Google a OSV.dev, una base en un formato abierto que reúne la GitHub Advisory Database, las bases de vulnerabilidades de PyPI y de Go, RustSec y otras. Trivy escanea repositorios, imágenes de contenedor y código de infraestructura con un solo binario. Grype escanea imágenes, sistemas de ficheros y SBOM, y lee las listas de paquetes que genera Syft, la otra herramienta de Anchore. Dependency-Check y Dependency-Track son proyectos Flagship de OWASP. pip-audit se mantiene bajo la Python Packaging Authority.

Hay dos herramientas que a menudo se meten en el saco del SCA y que actualizan dependencias sin escanearlas en el mismo sentido. Dependabot, cuya librería central tiene licencia MIT, abre pull requests que actualizan dependencias, y Renovate, con licencia AGPL-3.0, hace lo mismo en una gran variedad de lenguajes y plataformas. Mantienen las versiones al día, y ninguna guarda constancia de lo que has distribuido.

¿Qué encontró cada herramienta en un mismo repositorio?

En nuestra prueba del 5 de noviembre de 2026, cinco herramientas SCA se ejecutaron sobre un repositorio con dependencias anticuadas en cuatro ecosistemas y detectaron entre todas 109 vulnerabilidades distintas en 21 paquetes. OSV-Scanner encontró 109, Trivy 105 y Grype 104. npm audit encontró las mismas 43 vulnerabilidades npm que las demás, y pip-audit las mismas 21 en los cuatro paquetes Python fijados.

Montamos un repositorio pequeño que parece el backend de una tienda online, con un servicio por ecosistema y versiones de 2020 y 2021 fijadas a propósito:

• una API Node.js con express 4.17.1, lodash 4.17.20 y axios 0.21.1, y un lockfile de 53 paquetes resuelto ese mismo día;
• un worker Python cuyo requirements.txt fija requests 2.25.0, urllib3 1.26.4, PyYAML 5.3.1 y Jinja2 2.11.2;
• un servicio de facturación Java cuyo pom.xml declara log4j-core 2.14.1 y commons-text 1.9;
• una pasarela Go sobre una versión de noviembre de 2021 de golang.org/x/net y sobre golang.org/x/text 0.3.7, cuyo código llama al parser HTML del primero y a una sola función de anchura del segundo.

Cada herramienta se ejecutó con su configuración por defecto. Fusionamos los resultados entre identificadores CVE, GHSA, Go y PyPA, con los alias de cada herramienta y los de OSV, para que una vulnerabilidad notificada con dos nombres cuente una sola vez.

Los tiempos de Trivy y Grype son de una segunda ejecución. En la primera, cada una pasó casi todo el tiempo descargando una base de vulnerabilidades, 132 MiB en el caso de Trivy, y tardaron 19,2 s y 101,7 s. OSV-Scanner consulta osv.dev en línea por defecto.

Tres diferencias explican los huecos:

• Un requirements.txt sin lockfile lista cuatro paquetes y nada por debajo. OSV-Scanner resolvió aquello de lo que depende el propio requests y encontró tres avisos más en idna y certifi. Trivy, Grype y pip-audit leyeron las cuatro líneas fijadas y se quedaron ahí.
• En la parte Java, log4j-core necesita log4j-api, y commons-text necesita commons-lang3. Trivy y OSV-Scanner resolvieron las dos y encontraron un aviso en cada una; Grype solo leyó los dos paquetes declarados.
• En Go, Trivy no listó la CVE-2023-44487, el fallo HTTP/2 Rapid Reset, en golang.org/x/net, mientras que Grype y OSV-Scanner sí lo hicieron.

En npm las cuatro herramientas coincidieron en las 43, y 13 de ellas están en seis paquetes no declarados que trae express: qs, body-parser, path-to-regexp, cookie, send y serve-static. Log4Shell, la CVE-2021-44228, la encontraron Trivy, Grype y OSV-Scanner, y el JSON de Grype incluía además su puntuación EPSS de 0,99999 y su entrada en el catálogo CISA Known Exploited Vulnerabilities. Las severidades no siempre coincidían: para los mismos resultados, Trivy marcó cuatro como críticos y Grype cinco.

Trivy, Grype u OSV-Scanner: ¿cuál te conviene?

Elige OSV-Scanner si tu código tiene servicios Go o proyectos Maven y Python sin lockfile, porque resolvió lo que las demás se dejaron y su análisis de llamadas en Go reduce el ruido. Elige Trivy si quieres un solo binario para dependencias, imágenes de contenedor, IaC y licencias. Y Grype si ya generas SBOM con Syft o quieres los datos EPSS y KEV junto a cada resultado.

Las tres coinciden cuando la entrada es un lockfile, como muestran nuestros resultados en npm, así que la elección depende de qué más escaneas y de qué haces con la salida:

• Trivy encaja con un equipo que quiere un solo escáner en CI para varias capas. El mismo comando escanea un repositorio, una imagen o una carpeta de Terraform, y --scanners license añade las licencias. Su base se descarga una vez y queda en caché, y por eso nuestra segunda ejecución tardó un segundo.
• Grype encaja con un equipo que ya construye SBOM. Escaneas el SBOM una vez en el build y otra vez más adelante sin recompilar nada, y ordenas con los datos EPSS y KEV que lleva su JSON.
• OSV-Scanner encaja con un equipo que quiere precisión. Resolvió las dependencias transitivas de Maven y, en nuestra prueba, las de Python; su análisis de llamadas en Go viene activado por defecto, y su comando fix propone actualizaciones para proyectos npm y Maven.

npm audit y pip-audit siguen siendo útiles como primera comprobación del desarrollador antes de un commit, porque no hay que instalar nada, pero cada una cubre un solo ecosistema.

¿Te dice una herramienta SCA si una vulnerabilidad es alcanzable?

En nuestra prueba solo lo hizo OSV-Scanner, y solo en Go. Su análisis de llamadas, activado por defecto, marcó 12 de las 31 vulnerabilidades Go como llamadas por nuestro código y 18 como no llamadas; una no se pudo analizar. Su tabla por defecto mostró 13 vulnerabilidades de 31 para la pasarela Go, y ninguna para golang.org/x/text.

Las llamadas encajaban con lo que hace nuestro código. La pasarela usa el parser HTML de x/net, así que los avisos del parser y del renderizado salieron como llamados, mientras que los avisos HTTP/2 del mismo módulo, una ruta de código que la pasarela nunca toca, no. Los tres avisos de x/text están en funciones a las que la pasarela no llama. Para esto OSV-Scanner usa govulncheck, la librería del propio Go, y --all-vulns vuelve a mostrar los resultados ocultos. Su análisis de llamadas en Rust está marcado como experimental y ejecuta los scripts de build de tus dependencias.

En npm, Python y Java ninguna herramienta open source de la prueba llegó tan lejos, y cada resultado pesa lo mismo tanto si tu código llama a la función vulnerable como si no. Ese es el hueco que cubre la reachability, y es el mismo problema de clasificación que contamos en por qué un escáner te da 1.200 vulnerabilidades cuando solo 12 son reales. El SCA de CybeDefend trabaja a ese nivel: marca cada paquete como usado, posiblemente usado o no usado, para que los que tu código llama de verdad salgan primero. El SCA de CybeDefend muestra esa clasificación.

¿Merece la pena todavía OWASP Dependency-Check?

Dependency-Check 13.0.0 está mantenido y sigue siendo un proyecto Flagship de OWASP, pero en nuestra prueba se paró en su primera actualización de base con «Invalid API Key» y no produjo ningún resultado. Su README dice que se anima «highly» a conseguir una clave de API de la NVD y que sin ella las actualizaciones son «extremely slow». Cuenta con una clave y una base en caché antes de adoptarlo.

Sigue siendo una buena opción para builds Java y .NET, donde lee los JAR y los ensamblados compilados, y sus plugins de Maven y Gradle se ejecutan dentro del build. En 2026 le pesan dos cosas. Relaciona los paquetes con identificadores CPE de la NVD, y por eso la clave importa tanto, y OSS Index de Sonatype, otra de sus fuentes de datos, exige credenciales desde septiembre de 2025. Sin ellas, según el README, Dependency-Check «will automatically disable the OSS Index analyzer».

¿Qué se les escapa a las herramientas SCA?

A las herramientas SCA se les escapan tres cosas: los paquetes maliciosos que aún no tienen aviso, las vulnerabilidades en código copiado sin gestor de paquetes y todo lo que ningún lockfile ni manifiesto describe. Además solo informan de problemas conocidos, así que un paquete publicado ayer con una puerta trasera sale limpio hasta que alguien registra un aviso.

Los agentes de código añaden un cuarto hueco, el del momento. Claude Code, Cursor o Codex pueden añadir una dependencia a mitad de una tarea, y el escaneo en CI llega cuando el agente ya está con otra cosa, a veces con la pull request ya abierta. Un agente que lee los resultados del proyecto mientras trabaja puede elegir la versión corregida desde el principio, que es lo que describimos en dar a los agentes de código acceso en directo a todos los resultados. VibeDefend le pasa al agente los resultados de dependencias del proyecto por MCP mientras escribe, ya sea Claude Code, Cursor, Codex, Devin Desktop o GitHub Copilot, para que pase a la versión corregida en la misma sesión. Cómo funciona VibeDefend muestra el ciclo.

Entre dos escaneos: vigilar las CVE nuevas con OpenCVE

Un escaneo SCA es una foto fija. Lista las vulnerabilidades conocidas de tus dependencias el día en que se lanza, y una CVE publicada a la mañana siguiente sobre un paquete que distribuyes queda fuera de la vista hasta el siguiente escaneo, salvo que una plataforma como Dependency-Track vuelva a revisar los SBOM que guardaste en ella. Además, el SCA solo ve lo que tú construyes, y ningún lockfile recoge el appliance VPN o el servidor de base de datos que tu equipo tiene funcionando junto al código.

Esa vigilancia es el oficio de OpenCVE. Te suscribes a los fabricantes y productos que te importan, como Fortinet o WordPress, y OpenCVE te avisa por correo, Slack o webhook en cuanto se publica o se actualiza una CVE que les afecta. No hay agente que desplegar ni nada que escanear. Se alimenta de MITRE, NVD, CISA KEV, Red Hat y Vulnrichment, entre otras fuentes, y pone lado a lado el CVSS, el EPSS y el KEV de cada CVE, así distingues un fallo que los atacantes ya explotan de uno que solo tiene una puntuación alta. Funciona como servicio en la nube con un plan gratuito, o autoalojado con su edición Community, cuyo código está en GitHub bajo Business Source License.

OpenCVE no es un escáner SCA, porque no lee ningún lockfile ni escanea ningún repositorio, y precisamente por eso los dos se complementan: tu herramienta SCA te dice qué paquetes usas, y OpenCVE te avisa el día en que una CVE nueva cae sobre uno de los productos que sigues.

¿Cómo se lanza el SCA en CI sin perder una lista única?

Lanza el escáner en cada pull request contra los lockfiles, genera SARIF para tu plataforma de código y un SBOM para el histórico, y haz fallar el build solo con las vulnerabilidades críticas o altas que tienen corrección. Guarda el SBOM de cada release, porque un aviso nuevo suele afectar a una versión que distribuiste hace meses.

Una configuración mínima con las herramientas de nuestra prueba:

# En cada pull request: lockfiles, SARIF para 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 .

# En cada release: guardar el SBOM y volver a escanearlo más tarde
trivy fs --format cyclonedx --output sbom.cdx.json .
grype sbom:sbom.cdx.json

Dependency-Track toma el fichero CycloneDX y sigue vigilando los componentes de cada versión de cada aplicación que contiene, lo que responde a la pregunta que hace el auditor: qué release incluía la versión vulnerable y cuándo se corrigió. Para un equipo que prepara SOC 2 o ISO 27001, ese histórico cuenta más que el propio escaneo.

Un segundo escáner añade resultados y duplicados a la vez. Nuestra prueba generó 451 entradas en cinco ficheros JSON con cinco esquemas distintos para 109 vulnerabilidades distintas, el mismo problema de fusión que tuvimos con seis escáneres de secretos open source sobre un repositorio con secretos plantados. CybeDefend Open Source está pensado para ese paso. Ejecuta los escáneres que elijas, cualquier herramienta que escriba SARIF, y reúne lo que encuentran en una sola cola sin duplicados, gratis y en tus servidores. Llega pronto, y la lista de espera está abierta.

Preguntas frecuentes

¿Cuál es la mejor herramienta SCA open source en 2026?

En nuestra prueba del 5 de noviembre de 2026, OSV-Scanner 2.7.0 encontró las 109 vulnerabilidades distintas de un repositorio con dependencias npm, Python, Maven y Go anticuadas, Trivy 0.76.1 encontró 105 y Grype 0.121.0, 104. OSV-Scanner resolvió más dependencias transitivas; Trivy cubre más capas con un solo binario.

¿Trivy sirve como herramienta SCA?

Sí. Trivy busca en lockfiles y manifiestos las vulnerabilidades conocidas de los paquetes open source, que es justo el análisis de composición de software, y además escanea imágenes de contenedor, código de infraestructura, secretos y licencias. Tiene licencia Apache-2.0 y lo mantiene Aqua Security. En nuestra prueba encontró 105 de 109 vulnerabilidades y resolvió las dependencias transitivas de Maven.

¿Qué diferencia hay entre Trivy y Grype?

Las dos son escáneres con licencia Apache-2.0 que leen repositorios, SBOM e imágenes de contenedor. Trivy además escanea IaC, secretos y licencias, y en nuestra prueba resolvió las dependencias transitivas de Maven, con 105 vulnerabilidades encontradas. Grype, que se apoya en las listas de paquetes de Syft, encontró 104, se dejó los paquetes transitivos de Maven y añade a su JSON las puntuaciones EPSS y las entradas del catálogo CISA KEV.

¿OWASP Dependency-Check necesita una clave de API de la NVD?

Su README considera la clave muy recomendable y avisa de que sin ella las actualizaciones son extremadamente lentas. En nuestra prueba de la versión 13.0.0, el 5 de noviembre de 2026, la primera actualización de la NVD se paró con «Invalid API Key» y no se pudo lanzar ningún escaneo. Pide una clave a la NVD y guarda la base en caché entre ejecuciones de CI.

¿En qué se diferencian SCA y SAST?

El SAST lee el código que escribe tu equipo y busca patrones vulnerables, como una inyección. El SCA lee tus manifiestos y lockfiles y te dice qué vulnerabilidades publicadas tienen los paquetes open source que usas, también los que traen tus dependencias. Un proyecto necesita los dos: el lockfile de nuestra propia web lista 965 paquetes para 39 declarados.

¿Basta con npm audit y pip-audit?

Son una buena primera comprobación, porque no hay que instalar nada y encontraron las mismas vulnerabilidades npm y Python que las herramientas grandes en los paquetes que leen. Cada una cubre un solo ecosistema, ninguna escribe SARIF, y pip-audit lanzado sobre un fichero requirements sin lockfile solo audita las líneas que aparecen en él.

¿Qué es la reachability en SCA?

La reachability te dice si tu código llama a la función vulnerable de una dependencia o si solo importa el paquete. En nuestra prueba, el análisis de llamadas Go de OSV-Scanner marcó 18 de las 31 vulnerabilidades Go como no llamadas y las quitó de su tabla por defecto. En npm, Python y Java, ninguna de las herramientas open source que probamos hacía esa distinción.

¿Una herramienta SCA te avisa cuando se publica una CVE nueva?

No entre dos escaneos. Un escáner informa de lo que se conoce el día en que se lanza, así que pásalo en CI con cada cambio y de forma programada, a diario por ejemplo, para pillar los avisos publicados desde entonces. Para enterarte el mismo día en que una CVE afecta a un producto que usas, añade un servicio de vigilancia de CVE como OpenCVE, que avisa por correo, Slack o webhook cuando se publica o se actualiza una CVE que afecta a un fabricante o producto que sigues.