OSV-Scanner: vulnerabilidades con fuente de verdad

Actualizado: 2026-05-03

OSV-Scanner es la herramienta de Google que consulta directamente la base de datos abierta OSV.dev para identificar vulnerabilidades en dependencias de proyectos. A primera vista se parece a cualquier otro escáner de dependencias, y de hecho la salida es similar. La diferencia está más abajo, en cómo se representan los datos de vulnerabilidad y cómo se hace el cruce con las dependencias reales. Después de dos años usándola en varios proyectos, este artículo recoge por qué esta estructura produce menos ruido que otras herramientas y dónde siguen quedando fricciones.

Puntos clave

• Los escáneres basados en versión generan muchos falsos positivos porque las listas de versiones afectadas en los avisos CVE originales son a menudo imprecisas o genéricas.
• OSV representa cada vulnerabilidad con rangos de commits o versiones semánticas precisas, lo que permite comparaciones deterministas.
• OSV-Scanner soporta los manifiestos más comunes: npm, Python, Go, Ruby, PHP, Rust, Maven, Gradle; también imágenes de contenedor y SBOMs en SPDX o CycloneDX.
• La integración en CI que más valor aporta es fallar solo en vulnerabilidades nuevas introducidas por el cambio actual, no en las preexistentes.
• El escáner es una parte importante de un sistema, no el sistema entero.

El problema de los escáneres basados en versión

Muchos escáneres de dependencias funcionan comparando la versión que usas con una lista de versiones afectadas para cada CVE. Esto suena razonable pero genera una cantidad sorprendente de falsos positivos. Las razones son varias:

• Las listas de versiones afectadas en los avisos de CVE originales son a menudo imprecisas o generales.
• Las distribuciones Linux retroportan parches sin cambiar la versión pública del paquete, así que un escáner puede pensar que una versión es vulnerable cuando en realidad ya está parcheada.
• El aviso puede aplicar solo a ciertas configuraciones o usos del componente, y el escáner no los distingue.

El resultado práctico es familiar para cualquier equipo: los escáneres de dependencias producen cientos o miles de alertas, una mezcla de reales y falsas, y filtrar las reales consume tanto tiempo que muchos equipos terminan ignorando el escáner. La señal se pierde en el ruido.

OSV como formato estructurado

La idea detrás de OSV es cambiar la forma en que se representan los datos de vulnerabilidad. En lugar de un aviso en prosa libre con una lista vaga de versiones afectadas, cada vulnerabilidad en OSV tiene un formato estructurado con:

• Rangos de commits o de versiones semánticas precisas.
• Identificadores estables para cada paquete y ecosistema.
• Referencias cruzadas a los avisos originales.

Esta estructura permite hacer comparaciones deterministas entre lo que tiene un proyecto y lo que está listado como afectado. Un ejemplo concreto: un aviso OSV para una vulnerabilidad en una librería npm especifica exactamente que las versiones entre 1.2.0 y 1.4.5 son afectadas, con el formato SemVer exacto. Si tu proyecto usa la versión 1.4.6, la comparación es determinista: no afectado. Sin margen de ambigüedad.

OSV.dev agrega avisos de múltiples fuentes manteniendo esta estructura: GitHub Security Advisories, National Vulnerability Database, ecosistemas específicos como RustSec o PyPI Advisory Database. La agregación no es solo juntarlos, es normalizarlos al formato OSV y cruzar referencias.

Cómo funciona OSV-Scanner

OSV-Scanner toma el manifiesto de dependencias de tu proyecto, resuelve las versiones exactas y consulta OSV.dev por cada combinación paquete y versión. La consulta devuelve la lista de avisos OSV que aplican exactamente a esas versiones. No hay heurística de coincidencia de versión ni interpretación libre: si aparece en la respuesta, aplica.

El escáner soporta los manifiestos más comunes:

• package-lock.json de npm.
• requirements.txt y poetry.lock de Python.
• go.mod y go.sum de Go.
• Gemfile.lock de Ruby.
• composer.lock de PHP.
• Cargo.lock de Rust.
• pom.xml de Maven.
• gradle.lockfile de Gradle.

También puede escanear imágenes de contenedor inspeccionando los paquetes instalados, y archivos SBOM en formato SPDX o CycloneDX.

Uso práctico en CI

La integración en CI es uno de los lugares donde más brilla. OSV-Scanner es un binario estático que se puede ejecutar en cualquier entorno. El patrón típico es añadir un paso al pipeline que ejecuta osv-scanner sobre el repositorio y falla el build si aparecen vulnerabilidades que cumplan ciertos criterios.

Los criterios más útiles en la práctica son dos:

1. Fallar si hay cualquier vulnerabilidad listada en KEV (Known Exploited Vulnerabilities), porque eso indica que ya está siendo explotada en producción.
2. Fallar si aparecen vulnerabilidades introducidas por el cambio actual, es decir, vulnerabilidades que no existían en la rama principal y que aparecen por dependencias añadidas o actualizadas en esta rama. Este segundo criterio es mucho más útil que fallar por vulnerabilidades preexistentes, porque permite avanzar el baseline sin que cada arreglo de seguridad existente bloquee todos los commits.

Otra práctica útil es ejecutar el escaneo con frecuencia mayor que la de los commits, por ejemplo una vez al día sobre el repositorio principal. Las vulnerabilidades publicadas después de que un commit pasase el CI pueden aparecer en cualquier momento.

Qué pasa con los ecosistemas no cubiertos

Una crítica válida es que la cobertura de ecosistemas no es uniforme. npm, PyPI, Maven y Go están muy bien cubiertos. Rust y Ruby están bien. PHP y NuGet están adecuadamente. Pero hay ecosistemas donde la cobertura es parcial o inexistente.

Para estos casos hay dos estrategias: complementar OSV-Scanner con otras herramientas especializadas del ecosistema, o contribuir a OSV.dev que acepta contribuciones de avisos.

Para la mayoría de proyectos con dependencias en los ecosistemas más grandes, OSV-Scanner es suficiente como herramienta principal. Para proyectos con dependencias en ecosistemas menos mainstream, merece la pena tener al menos una segunda capa. Esto conecta con el enfoque de defensa en profundidad que describimos en guardrails en LLM: frameworks y su coste real.

La relación con SBOMs

OSV-Scanner trabaja muy bien con SBOMs. Se le puede pasar un archivo SBOM en formato SPDX o CycloneDX como entrada, y produce el mismo tipo de informe que si hubiera partido de los manifiestos. Esto es especialmente útil cuando el proceso de construcción genera SBOMs y se quiere escanear a partir de ellos, o cuando se quiere escanear artefactos ya desplegados para los que solo se tiene el SBOM.

La arquitectura que funciona en varios proyectos es: la cadena de construcción genera SBOMs como parte del artefacto, los SBOMs se almacenan en un registro junto al artefacto, y un trabajo periódico ejecuta OSV-Scanner contra todos los SBOMs almacenados para detectar vulnerabilidades nuevas en artefactos ya desplegados.

Límites reales

Tres áreas donde OSV-Scanner sigue mejorando pero aún no basta:

• Alcance de los escáneres basados en ejecución: OSV-Scanner trabaja sobre declaraciones estáticas: manifiestos y SBOMs. No detecta dependencias cargadas dinámicamente en runtime, ni librerías nativas del sistema que el binario enlaza, ni plugins.
• Falta de contexto sobre si una vulnerabilidad afecta a tu uso concreto del paquete: una CVE en una función XML de una librería que solo usas para JSON no te afecta en la práctica, pero OSV-Scanner la reportará igual.
• El ecosistema de priorización: OSV-Scanner reporta vulnerabilidades pero no las ordena por riesgo real. El trabajo de convertir una lista de vulnerabilidades en una cola de trabajo priorizada sigue necesitando una capa encima.

Mi lectura

OSV-Scanner es la mejor pieza disponible hoy para el paso básico de escanear dependencias. Su valor está en la fuente de verdad que consulta, OSV.dev, más que en el escáner en sí. La combinación produce significativamente menos falsos positivos que los escáneres tradicionales.

La recomendación concreta es que cualquier proyecto con dependencias open source debería tener OSV-Scanner ejecutándose en CI, al menos en el modo de detectar vulnerabilidades nuevas introducidas por el cambio actual. Es gratis, es rápido y la fuente de datos es buena.

Pensar que con tenerlo activo ya está cubierto el escaneo de dependencias es un error común. La herramienta es una parte importante de un sistema, no el sistema entero. Así pensada, es útil, estable y reduce la fatiga de alertas que tanto daño hace a la seguridad práctica.

Conclusión

La fatiga de alertas es el enemigo de la seguridad real. OSV-Scanner ataca ese problema desde la raíz, usando datos estructurados en lugar de heurísticas de versión. Para equipos que hoy tienen un escáner de dependencias que produce cientos de alertas ignoradas, migrar a OSV-Scanner suele reducir el ruido a una fracción manejable sin perder cobertura real.