Cómo detectar vulnerabilidades en tu repositorio gratis

Para detectar vulnerabilidades en tu repositorio de forma gratuita, combina tres capas: un escáner de dependencias (npm audit, pip-audit o OSV-Scanner), un escáner de secretos (Gitleaks) y un escáner de código (Semgrep Community Edition). Ejecútalos en cada pull request. Ninguno de ellos detectará la falta de una comprobación de autorización, por lo que conviene añadir una prueba en tiempo de ejecución para cubrir ese caso.

Prueba Apidog hoy

npm audit --audit-level=high
pip-audit -r requirements.txt
gitleaks git . --no-banner
semgrep scan --config p/default --metrics=off --error

Qué cambia con Vercel Security Review

Vercel Security Review es una funcionalidad de Vercel Agent, en beta pública desde el 2 de noviembre de 2026. Analiza cada push en un repositorio de GitHub conectado, examina el diff y el código adyacente, rastrea cómo se puede alcanzar el cambio y verifica de nuevo cada hallazgo antes de reportarlo.

El ejemplo de Vercel es el motivo por el que existe este artículo. Un cambio en un endpoint de facturas buscaba facturas por ID sin comprobar la organización, lo que permitía a cualquier usuario autenticado descargar la factura de otra organización. Se trata de un error de lógica, y los escáneres basados en patrones tienen dificultades para detectar este tipo de fallos.

A continuación se detalla quién puede utilizarlo:

Pregunta	Respuesta
Planes	Solo para equipos Pro y Enterprise
Coste	Gratis hasta el 10 de noviembre de 2026; después, las tarifas por token del proveedor más 0,25 $ por millón de tokens
Repositorios	Repositorios de GitHub conectados; los repositorios que no se despliegan en Vercel aún no son compatibles
Alcance	El diff respecto a una base, o el código fuente completo en la primera revisión
Hallazgos	Panel de vulnerabilidades, un GitHub check y comentarios en los PR en repositorios privados e internos

La documentación de Vercel también señala sus límites: analiza código, no la aplicación en ejecución, y no sustituye a una prueba de penetración. Si no cumples los requisitos o estás leyendo esto después del periodo gratuito, el resto de esta guía no te costará nada.

Qué debería cubrir un escaneo de vulnerabilidades en el repositorio

Un escaneo exhaustivo de vulnerabilidades en un repositorio evalúa cuatro aspectos: vulnerabilidades conocidas en las dependencias, credenciales subidas a Git, patrones de código inseguros como inyecciones y la lógica de autorización. Los tres primeros cuentan con escáneres gratuitos y consolidados. El cuarto depende del comportamiento semántico del código, por lo que requiere una prueba contra una API en ejecución.

Una clave eliminada permanece en el historial de Git, así que analiza el historial y rota cualquier clave real. Para detectar claves en el tráfico de la API y en colecciones de pruebas, consulta nuestra guía para detectar fugas de claves de API.

Comparativa de escáneres de vulnerabilidades gratuitos

Los precios y las licencias se verificaron el 5 de noviembre de 2026. Ninguna de las herramientas de línea de comandos requiere una cuenta ni tarjeta de crédito para los comandos que se muestran en esta guía.

Herramienta	Qué detecta	Coste y licencia	Aspectos a tener en cuenta
npm audit	Vulnerabilidades en dependencias de npm	Gratuito, incluido con npm	Requiere un archivo lockfile
pip-audit	Vulnerabilidades en dependencias de Python	Gratuito, Apache-2.0	Solo para Python
OSV-Scanner	Vulnerabilidades en dependencias de múltiples ecosistemas	Gratuito, Apache-2.0	Reporta más resultados, por lo que requerirá triaje
Trivy	Dependencias, secretos y errores de configuración	Gratuito, Apache-2.0	Fijar versiones (ver más abajo)
Gitleaks	Secretos en el historial de Git	Gratuito, MIT	Su GitHub Action requiere una clave de licencia gratuita para organizaciones
Semgrep Community Edition	Patrones de código y algunos secretos	Gratuito, motor con licencia LGPL-2.1	No puede rastrear datos más allá de una sola función o archivo
Alertas de Dependabot	Vulnerabilidades en dependencias	Gratuito en repositorios públicos y privados	Solo para GitHub
Escaneo de secretos de GitHub	Secretos	Gratuito en repositorios públicos; 19 $ al mes por committer activo en privados	Los repositorios privados requieren Secret Protection
CodeQL	Patrones de código	Gratuito en repositorios públicos; 30 $ al mes por committer activo en privados	Los repositorios privados requieren Code Security

Dos apuntes sobre licencias. Las reglas comunitarias de Semgrep utilizan la Semgrep Rules License, que autoriza el uso interno comercial, pero no su redistribución ni su oferta como servicio. Y si vas a adoptar Trivy, revisa CVE-2026-33634: en marzo de 2026 se comprometieron brevemente partes del ecosistema de Trivy. Utiliza una versión actualizada y fija cualquier GitHub Action al SHA de un commit.

Escanear un repositorio con pocos comandos: lo que encontramos

Construimos una pequeña API de facturación con Express y la subimos a un repositorio local. Contaba con cuatro dependencias de npm y tres de Python en versiones antiguas, dos claves simuladas (una al estilo de Stripe y otra al estilo de AWS), una inyección SQL, una inyección de comandos y una ruta que devuelve la factura de cualquier organización a cualquier usuario autenticado.

A continuación, ejecutamos cada herramienta en macOS el 5 de noviembre de 2026:

npm audit
pip-audit -r requirements.txt --no-deps --disable-pip
osv-scanner scan source -r .
trivy fs --scanners vuln,secret .
gitleaks git . --no-banner
semgrep scan --config p/default --metrics=off
semgrep scan --config p/nodejsscan --metrics=off

Herramienta (versión)	Detectado	No detectado
npm audit (npm 11.12.1)	9 paquetes vulnerables: 6 de severidad alta, 3 baja	Todo lo que no sea un paquete de npm
pip-audit 2.10.1	16 avisos de seguridad en los 3 paquetes fijados	Paquetes transitivos, debido a que usamos --no-deps
OSV-Scanner 2.7.0	66 avisos únicos en 15 paquetes, incluidos los paquetes transitivos de Python	Secretos y errores de código
Trivy 0.76.1	33 vulnerabilidades en dependencias y la clave al estilo de Stripe	La clave al estilo de AWS
Gitleaks 8.30.1	La clave al estilo de Stripe	La clave al estilo de AWS
Semgrep 1.183.0, p/default	Clave al estilo de Stripe, inyección de comandos y un aviso por ausencia del middleware de CSRF	Inyección SQL, clave al estilo de AWS
Semgrep 1.183.0, p/nodejsscan	Inyección SQL, inyección de comandos y clave al estilo de AWS	Clave al estilo de Stripe

Destacan tres conclusiones:

• Las cifras no son comparables. Un paquete, un aviso de seguridad y un hallazgo son métricas distintas, y cada herramienta analiza datos diferentes. Compara lo que se detectó, no los totales.
• Un solo escáner de secretos no basta. Tanto Gitleaks como Trivy pasaron por alto la clave al estilo de AWS.
• Los conjuntos de reglas marcan la diferencia. El paquete predeterminado de Semgrep no detectó una consulta SQL construida mediante concatenación simple de cadenas. p/javascript, p/nodejs, p/owasp-top-ten y p/sql-injection no devolvieron nada en este repositorio, mientras que p/nodejsscan sí la encontró.

Ninguna herramienta señaló la ruta de facturas. Este es solo un repositorio pequeño, así que tómalo como una demostración y no como un benchmark formal. No ejecutamos CodeQL.

Analiza tu repositorio de GitHub en cada pull request

Los ejecutores estándar alojados en GitHub son gratuitos en repositorios públicos. En repositorios privados, GitHub Free incluye un saldo mensual de 12 $, lo que equivale a unos 2000 minutos en un ejecutor Linux de 2 núcleos según la tarifa establecida. Este flujo de trabajo utiliza comandos estándar, por lo que las organizaciones pueden prescindir de la clave de licencia de la GitHub Action de Gitleaks:

name: repo-scan
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7 # pin to a commit SHA
        with:
          fetch-depth: 0
      - name: Dependencies (npm)
        run: npm audit --audit-level=high
      - name: Dependencies (Python)
        run: pipx run pip-audit -r requirements.txt
      - name: Secrets
        run: |
          curl -sSL https://github.com/gitleaks/gitleaks/releases/download/v8.30.1/gitleaks_8.30.1_linux_x64.tar.gz | tar xz gitleaks
          ./gitleaks git . --no-banner
      - name: Code patterns
        run: pipx run semgrep scan --config p/default --config p/nodejsscan --metrics=off --error

Los cuatro escáneres finalizaron con código de salida 1 en nuestro repositorio de prueba, y una salida distinta de cero es lo que hace fallar el job. Elimina los pasos que tu stack no necesite. Para integrar pruebas de API en la misma pipeline, consulta Apidog CLI con GitHub Actions.

Activa también las alertas de Dependabot. Son gratuitas en todos los planes y no esperan a que haya un pull request para avisarte.

La brecha: fallos de autorización que los escáneres pasan por alto

Los fallos de autorización resultan difíciles de detectar para los escáneres de patrones porque el código parece correcto a simple vista: una consulta válida, un parámetro válido y un middleware de auth protegiendo la ruta. El fallo reside en una condición ausente, y únicamente tu modelo de datos determina que dicha condición debería existir.

// Every scanner passed this
db.query("SELECT * FROM invoices WHERE id = $1", [req.params.id]);

// The fix: scope the lookup to the caller's organization
db.query("SELECT * FROM invoices WHERE id = $1 AND org_id = $2",
  [req.params.id, req.user.orgId]);

Se trata de Broken Object Level Authorization (BOLA), clasificada en el primer puesto del OWASP API Security Top 10 2023. OWASP recomienda validar los permisos de acceso en cada petición que utilice un ID proporcionado por el cliente y escribir pruebas que detecten fallos de autorización antes del despliegue.

Recurrir a un agente de código resulta útil. Eliminamos los comentarios del repositorio de prueba y le pedimos a Claude Code que lo revisara, con y sin una pista sobre las organizaciones. Detectó la ruta de facturas en ambas ocasiones. No obstante, no es una alternativa con coste cero por sí misma, ya que consume el plan de tu agente y los resultados pueden variar entre ejecuciones.

Una prueba ofrece una respuesta binaria (pasa o falla) en cada pull request. Para asegurar una cobertura adecuada a nivel de API, consulta la detección automatizada de vulnerabilidades en API, nuestra recopilación de herramientas de escaneo de seguridad de API y la lista de comprobación para pruebas de seguridad de API.

Permite que tu agente de código pruebe la autorización con Apidog CLI

No escribas esta prueba manualmente para cada ruta. Deja que tu agente de código se encargue utilizando Apidog CLI: lee tus rutas, crea una prueba por cada recurso protegido y genera una suite lista para ejecutarse en CI. Apidog Free cubre hasta 4 usuarios.

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

Necesitarás un entorno de pruebas con dos organizaciones creadas con datos iniciales y un usuario en cada una. Luego, proporciónale este prompt a tu agente:

Read the routes in src/. For each route that returns data owned by an
organization, create an Apidog test scenario in project <id>: log in as
the Org A test user, request an Org B resource by ID, and assert the
status is 403 or 404. Add an Org A request for its own resource and
assert 200, so a broken login can't pass. Group the scenarios in a test
suite, run it against the staging environment, and summarize failures.

El agente comprueba la estructura del payload, crea los escenarios y ejecuta la suite:

apidog cli-schema get test-scenario-create
apidog cli-schema validate test-scenario-create --file scenario.json
apidog test-scenario create --project <id> --file scenario.json
apidog test-scenario import-steps <scenarioId> --project <id> --source endpoint --ids <endpointIds>
apidog test-suite create --project <id> --file suite.json
apidog run --test-suite <suiteId> --project <id> -e <envId> -r cli,junit

La comprobación positiva es fundamental. Sin ella, una URL base incorrecta también devolvería un 404 y la prueba pasaría por el motivo equivocado.

Añade la misma línea con apidog run al flujo de trabajo anterior, ejecutándola contra un despliegue de preview o staging con organizaciones de prueba precargadas, nunca con datos de producción. La referencia del comando apidog run cubre el resto de parámetros, y la guía de Apidog CLI en Claude Code explica paso a paso la configuración del agente.

Preguntas frecuentes

¿Cuál es la mejor forma gratuita de detectar vulnerabilidades en un repositorio? Combina un escáner de dependencias, Gitleaks y Semgrep Community Edition, y añade además una prueba en tiempo de ejecución para la autorización. Ninguna herramienta por sí sola cubrió todo en nuestro repositorio de prueba.

¿Es gratuito Vercel Security Review? Solo hasta el 10 de noviembre de 2026 y únicamente para equipos Pro y Enterprise. A partir de esa fecha, se pagan las tarifas por token del proveedor más 0,25 $ por millón de tokens. Los repositorios que no se despliegan en Vercel aún no son compatibles.

¿El escaneo de secretos de GitHub es gratuito en repositorios privados? No. Tanto el escaneo de secretos como CodeQL son gratuitos en repositorios públicos, pero los repositorios privados requieren GitHub Secret Protection (19 $) o GitHub Code Security (30 $) por committer activo al mes. Las alertas de Dependabot son gratuitas en ambos.

¿Puede Semgrep detectar fallos de autorización? No detectó nuestra ruta de facturas con los conjuntos de reglas que ejecutamos. Community Edition no puede rastrear el flujo de datos más allá de una sola función o archivo, aunque es posible escribir reglas personalizadas para patrones específicos de tu base de código.

¿Reemplazan los escáneres una prueba de penetración? No. Los escáneres y las pruebas cubren patrones conocidos y los casos de prueba definidos. Una prueba de penetración busca aquello que no se ha previsto, y la propia documentación de Vercel aclara que su análisis tampoco constituye un pentest.