Introducción
Cualquiera que haya mantenido un proyecto medianamente serio sabe que el verdadero riesgo de seguridad rara vez está en el código que uno escribe: está en las cientos —a veces miles— de dependencias transitivas que arrastra cada npm install, cada go mod tidy o cada pip install -r requirements.txt. La superficie de ataque real no es tu repositorio; es el grafo completo de paquetes que termina dentro de tu binario o tu contenedor.
Durante años, las herramientas de auditoría de dependencias estuvieron dominadas por soluciones comerciales (Snyk, WhiteSource, Black Duck) o por escáneres específicos por ecosistema (npm audit, pip-audit, cargo audit, bundler-audit). El problema es obvio: si tu stack mezcla Node, Python, Go y un par de imágenes Docker, terminás corriendo cuatro herramientas distintas, con cuatro formatos de salida y cuatro bases de datos que se contradicen entre sí.
En 2021, Google publicó OSV.dev, una base de datos abierta de vulnerabilidades de software open source con un formato común y machine-readable. osv-scanner es la herramienta de línea de comandos oficial que consume esa base de datos y reemplaza, de un solo binario, a la mayoría de los escáneres específicos por lenguaje. Y lo hace gratis, con licencia Apache-2.0 y código auditado bajo SLSA nivel 3.
Qué es osv-scanner
osv-scanner es un escáner de vulnerabilidades escrito en Go, mantenido por Google, que toma como entrada los manifiestos y lockfiles de tu proyecto (o una imagen de contenedor, o un directorio de fuentes) y los compara contra la base de datos OSV.dev para reportar qué dependencias tienen vulnerabilidades conocidas y, cuando es posible, qué versiones las corrigen.
Por debajo usa la librería OSV-Scalibr, también de Google, que es la que se encarga de detectar paquetes en disco. Esto le permite cubrir un rango muy amplio de ecosistemas con una sola herramienta:
- Lenguajes: C/C++, Dart, Elixir, Go, Java, JavaScript, PHP, Python, R, Ruby y Rust.
- Gestores de paquetes: npm, pip, yarn, Maven, go modules, Cargo, Gem, Composer, NuGet y otros.
- Sistemas operativos: detecta vulnerabilidades en paquetes de Alpine, Debian y Ubuntu.
- Contenedores: escaneo layer-aware de imágenes Docker/OCI.
- Licencias: auditoría de licencias usando datos de deps.dev.
- Remediación guiada: sugiere actualizaciones de versión basadas en profundidad, severidad y estrategia de fix.
La diferencia clave con otras herramientas es la fuente de datos. OSV.dev agrega advisories de fuentes oficiales (GitHub Security Advisories, RustSec, Ubuntu Security Notices, GHSA, PyPA, Go vulnerability database, etc.) en un formato unívoco que mapea con precisión versiones afectadas a paquetes concretos. Eso reduce los falsos positivos respecto a escáneres que hacen matching difuso por nombre o por rango.
El proyecto está hospedado en google/osv-scanner y al momento de escribir este artículo lleva más de 9.500 estrellas y poco más de 600 forks. La documentación oficial vive en google.github.io/osv-scanner. La versión más reciente al cierre de este artículo es v2.3.5 (publicada el 25 de marzo de 2026), parte de una línea V2 que Google anunció en marzo de 2025 con tres cambios mayores: integración con la librería OSV-SCALIBR (el motor SCA que el propio Google describe como su herramienta primaria para hosts, repos y contenedores internamente), escaneo de contenedores con análisis por capas e identificación de imagen base, y guided remediation para Maven además del soporte original para npm.
Instalación
El método recomendado por el equipo de Google es descargar el binario precompilado desde la página de releases. Para usuarios con Go instalado, también se puede compilar desde fuente. Veamos las tres plataformas principales.
Linux
En la mayoría de distribuciones, lo más simple es bajar el binario directamente. Reemplazá la versión por la última disponible en releases:
# Descargar binario para Linux x86_64
curl -L -o osv-scanner \
https://github.com/google/osv-scanner/releases/latest/download/osv-scanner_linux_amd64
chmod +x osv-scanner
sudo mv osv-scanner /usr/local/bin/
# Verificar instalación
osv-scanner --version
Para distribuciones basadas en Debian/Ubuntu, también podés instalarlo vía go install si tenés Go 1.21 o superior:
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
# Asegurate de tener $GOPATH/bin en tu PATH
export PATH="$PATH:$(go env GOPATH)/bin"
macOS
En macOS la forma más cómoda es Homebrew, que mantiene una fórmula actualizada:
brew install osv-scanner
# Verificar
osv-scanner --version
Si preferís el binario directo (Apple Silicon o Intel):
# Apple Silicon (M1/M2/M3/M4)
curl -L -o osv-scanner \
https://github.com/google/osv-scanner/releases/latest/download/osv-scanner_darwin_arm64
# Intel
curl -L -o osv-scanner \
https://github.com/google/osv-scanner/releases/latest/download/osv-scanner_darwin_amd64
chmod +x osv-scanner
sudo mv osv-scanner /usr/local/bin/
Windows
En Windows hay tres caminos. El más rápido es Scoop o Chocolatey:
# Con Scoop
scoop install osv-scanner
# Con Chocolatey (PowerShell admin)
choco install osv-scanner
O bajar el ejecutable manualmente desde releases y agregarlo al PATH:
# PowerShell
Invoke-WebRequest `
-Uri "https://github.com/google/osv-scanner/releases/latest/download/osv-scanner_windows_amd64.exe" `
-OutFile "$env:USERPROFILE\bin\osv-scanner.exe"
# Agregar al PATH (sesión actual)
$env:PATH += ";$env:USERPROFILE\bin"
# Verificar
osv-scanner --version
Si tenés Go instalado, el comando go install funciona idéntico al de Linux y macOS.
Uso básico
El comando central es osv-scanner scan source, que recorre un directorio buscando manifiestos conocidos (package.json, go.mod, requirements.txt, pom.xml, Cargo.lock, etc.) y consulta cada uno contra OSV.dev:
# Escanear el directorio actual de forma recursiva
osv-scanner scan source -r .
# Escanear una ruta específica
osv-scanner scan source -r /home/dev/mi-proyecto
La salida por defecto es una tabla legible que lista, por cada vulnerabilidad encontrada, el ID OSV, el paquete afectado, la versión instalada y un link al advisory completo. Algo así:
╭─────────────────────────────────┬──────┬───────────┬─────────┬─────────╮
│ OSV URL │ CVSS │ Ecosystem │ Package │ Version │
├─────────────────────────────────┼──────┼───────────┼─────────┼─────────┤
│ https://osv.dev/GHSA-xxxx-xxxx │ 7.5 │ npm │ axios │ 1.6.0 │
│ https://osv.dev/GHSA-yyyy-yyyy │ 9.8 │ PyPI │ pillow │ 9.5.0 │
╰─────────────────────────────────┴──────┴───────────┴─────────┴─────────╯
Si querés integrarlo en CI/CD, lo más útil es pedir salida en JSON o SARIF, que se pueden consumir desde otras herramientas:
# JSON (para parsear con jq, scripts, etc.)
osv-scanner scan source -r . --format json > report.json
# SARIF (para subir a GitHub Code Scanning)
osv-scanner scan source -r . --format sarif > report.sarif
Por defecto, osv-scanner devuelve exit code distinto de cero si encuentra vulnerabilidades, lo que lo hace ideal como gate en pipelines.
Integración en proyectos reales
Hasta acá vimos el uso interactivo. La verdadera potencia aparece cuando lo metés dentro del flujo de desarrollo. Tres patrones son particularmente comunes en equipos LATAM que ya lo están adoptando.
1. GitHub Actions con SARIF
Subir el reporte SARIF a GitHub Code Scanning te da una vista nativa de las vulnerabilidades en la pestaña Security del repo, con tracking de duplicados y dismissal por usuario. Crear .github/workflows/osv-scan.yml:
name: OSV-Scanner
on:
push:
branches: [main]
pull_request:
branches: [main]
schedule:
- cron: '0 6 * * *' # Diario a las 06:00 UTC
jobs:
scan:
runs-on: ubuntu-latest
permissions:
security-events: write
contents: read
steps:
- uses: actions/checkout@v4
- name: Run osv-scanner
uses: google/osv-scanner-action/osv-scanner-action@v2
with:
scan-args: |-
--format=sarif
--output=results.sarif
--recursive
./
continue-on-error: true
- name: Upload SARIF
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: results.sarif
El continue-on-error: true es deliberado: si el scan falla, querés que el SARIF igualmente se suba para no perder visibilidad del problema.
2. Escaneo de contenedores en producción
Para equipos que despliegan con Docker o Kubernetes, osv-scanner puede analizar imágenes ya construidas, detectando tanto paquetes del sistema operativo (Alpine, Debian, Ubuntu) como dependencias de lenguaje (Go, Java, Node, Python) embebidas dentro de la imagen:
# Escanear imagen local
osv-scanner scan image mi-app:1.2.3
# Escanear imagen de un registry
osv-scanner scan image registry.gitlab.com/empresa/api:latest
# Salida en HTML para compartir con el equipo
osv-scanner scan image mi-app:1.2.3 --format html > reporte.html
El escaneo es layer-aware: te dice exactamente en qué capa de la imagen está la dependencia vulnerable, lo que ayuda a decidir si conviene actualizar la imagen base, el paso de RUN apt-get install, o tu propia capa de aplicación.
3. Modo offline para entornos air-gapped
Bancos, gobiernos y empresas con compliance estricto (en LATAM esto cubre desde fintechs hasta operadoras de telecomunicaciones reguladas) suelen prohibir que herramientas de CI hagan llamadas salientes. osv-scanner soporta modo offline descargando primero la base de datos OSV completa y luego escaneando contra esa copia local:
# Descargar la base de datos y escanear
osv-scanner --offline --download-offline-databases ./mi-proyecto
# Posteriores ejecuciones (sin descargar de nuevo)
osv-scanner --offline ./mi-proyecto
La base de datos pesa unos cientos de megabytes y se puede actualizar periódicamente con un cron interno, sin que el escáner toque internet en cada ejecución.
4. Remediación guiada (experimental)
El comando osv-scanner fix intenta proponer actualizaciones de versión que cierren las vulnerabilidades sin romper el grafo de dependencias. Hoy soporta npm (in-place y relock) y Maven (override):
# Modo headless: aplica fixes que cumplan los criterios
osv-scanner fix \
--max-depth=3 \
--min-severity=5 \
--ignore-dev \
--strategy=in-place \
-L path/to/package-lock.json
# Modo interactivo: te muestra una TUI con los parches sugeridos
osv-scanner fix \
-M path/to/package.json \
-L path/to/package-lock.json
El propio equipo de Google advierte que ejecutar fix sobre proyectos no confiables es riesgoso, porque puede gatillar scripts del package manager. Úsenlo en sus propios repos, no en clones de terceros.
Cuándo usarlo y cuándo no
osv-scanner brilla en escenarios concretos y se queda corto en otros. Vale la pena ser explícito.
Usalo si:
- Tu stack mezcla varios lenguajes y querés un único escáner con un único formato de salida.
- Necesitás auditar imágenes de contenedor con detalle por capa.
- Querés integración con GitHub Code Scanning vía SARIF sin pagar licencia.
- Operás en un entorno air-gapped y necesitás escaneo offline.
- Te importa la trazabilidad: cada hallazgo apunta a un advisory público y verificable en OSV.dev.
- Estás construyendo software para clientes que exigen evidencia de SBOM y CVE scanning (cada vez más común en licitaciones públicas LATAM).
Pensalo dos veces si:
- Necesitás escanear vulnerabilidades en infraestructura como código (Terraform, Kubernetes manifests). Para eso hay herramientas más específicas como Checkov o Trivy.
- Tu prioridad es SAST (análisis de tu propio código fuente). osv-scanner sólo mira dependencias; para SAST necesitás Semgrep, CodeQL o SonarQube.
- Querés un dashboard SaaS con tracking histórico, asignación a desarrolladores y workflow de tickets. osv-scanner es CLI; el componente de plataforma corre por tu cuenta.
- Tu ecosistema no está cubierto. Aunque el soporte es amplio, lenguajes muy de nicho pueden quedar fuera.
Una limitación técnica honesta: como toda herramienta basada en bases de datos públicas, osv-scanner no detecta vulnerabilidades que aún no fueron divulgadas. No reemplaza un programa de respuesta a incidentes ni un equipo de seguridad ofensiva interna.
Otra limitación reconocida por el propio equipo: el matching actual no incluye reachability analysis (analizar si la función vulnerable se invoca desde tu código). Eso significa que un CVE que afecta una rama de código que vos nunca tocás aparece igual como hallazgo. Google declaró reachability analysis y soporte VEX como prioridades del roadmap V2, pero hoy todavía no están en el binario estable.
Sobre adopción: en el anuncio original de diciembre de 2022, Google mencionó la integración del escaneo OSV en OpenSSF Scorecard (que evalúa más de un millón de proyectos open source) y citó a DependencyTrack y al repositorio de Flutter como adoptantes tempranos. No abundan los case studies formales públicos —es la norma en herramientas de seguridad—, pero esos puntos son verificables.
Alternativas
El espacio de escáneres de dependencias está bien poblado. Comparemos osv-scanner con tres alternativas comunes, sin ranking subjetivo: cada una sirve para un perfil distinto.
Trivy (Aqua Security): también escrito en Go, también open source (Apache-2.0), soporta escaneo de imágenes, IaC, secretos y dependencias. Tiene mayor cobertura de IaC y detección de secretos hardcodeados. La diferencia más concreta está en la fuente de datos: Trivy agrega múltiples bases (NVD, GHSA, vendor advisories) y aplica reglas propias de matching, mientras que osv-scanner consume OSV.dev directamente. Si necesitás un «swiss army knife» de seguridad cubriendo IaC y secretos, Trivy gana en amplitud; si tu foco es exclusivamente dependencias y querés cada hallazgo trazable a un advisory público, osv-scanner es más directo.
Snyk: producto comercial (con tier gratuito limitado) muy popular por su UX, integración con IDEs y dashboard SaaS. Cubre dependencias, contenedores, IaC y SAST en una sola plataforma. La diferencia es modelo de negocio: Snyk depende de su base de datos propietaria y precios por desarrollador. osv-scanner es 100% gratuito y la base de datos es pública.
Grype (Anchore): otro escáner Go, open source, especializado en imágenes de contenedor y SBOMs (formatos SPDX y CycloneDX). Si tu workflow está construido alrededor de Syft (también de Anchore) para generar SBOMs, Grype encaja naturalmente. osv-scanner cubre escaneo de fuentes y manifiestos sin pasar por SBOM intermedio.
En proyectos reales no es raro correr dos herramientas en paralelo (por ejemplo osv-scanner + Trivy) y deduplicar resultados, justamente porque cada base de datos cubre advisories ligeramente distintos.
Conclusión
osv-scanner ocupa un nicho que hace cinco años parecía imposible de cubrir gratis: un escáner unificado, multi-ecosistema, mantenido por Google, con datos auditables públicamente y un binario simple de integrar en cualquier pipeline. Para equipos LATAM —donde el presupuesto de herramientas de seguridad suele ser el primero que se recorta— representa una alternativa seria a las soluciones comerciales de cuatro cifras anuales por desarrollador.
No es una bala de plata: necesitás complementarlo con SAST, escaneo de IaC y, sobre todo, con criterio humano para decidir qué CVE realmente impacta tu superficie de ataque y cuál es ruido. Pero como pieza fundamental de un programa de seguridad de la cadena de suministro de software, es difícil encontrar mejor relación costo/beneficio en 2026.
El proyecto vive en Repositorio oficial en GitHub, está bajo licencia Apache-2.0, recibe releases frecuentes y tiene una comunidad activa respondiendo issues. Si todavía estás corriendo npm audit, pip-audit y cargo audit por separado, vale la pena dedicar una tarde a unificar todo bajo osv-scanner.
Referencias
- google/osv-scanner — Repositorio oficial en GitHub
- Documentación oficial de osv-scanner
- OSV.dev — Base de datos de vulnerabilidades open source
- google/osv-scalibr — Librería de detección de paquetes
- Página de releases de osv-scanner
- Documentación de Guided Remediation
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)