npm audit dice 0 vulnerabilities. Eso no quiere decir que tu app sea segura.

Qué hace exactamente

Coge las dependencias de tu proyecto, se las manda al registro de npm y pregunta si alguna de esas versiones aparece en un aviso publicado. Si la respuesta es sí, te lo cuenta y te dice a qué versión subir. Eso es todo, y lo hace bien.

npm audit mira lo que instalaste. No mira lo que escribiste.

Seis cosas que nunca va a ver

Todas son categorías reales de nuestro escáner, con el nombre con el que salen en el informe. Ninguna aparece en un árbol de dependencias, así que ninguna puede salir en un npm audit, por muy limpio que lo tengas.

• Tu clave de OpenAI o de Anthropic, escrita en el código

  Está en TU archivo, no en un paquete. npm audit no abre tus archivos.

• Una consulta SQL construida pegando texto

  El paquete de base de datos está perfectamente al día. Lo inseguro es cómo lo llamas.

• La clave service_role de Supabase, servida al navegador

  El paquete de Supabase no tiene ninguna vulnerabilidad. La vulnerabilidad es dónde pusiste la clave.

• Tus tablas de Supabase sin protección por fila

  Con la clave pública que cualquiera copia de tu JavaScript se leen enteras. Ningún paquete es culpable.

• Una ruta de API que nunca comprueba quién llama

  Es una función tuya de doce líneas. No aparece en ningún árbol de dependencias.

• CORS abierto a todo internet

  Una línea de configuración. npm audit no lee configuración.

Nuestro motor lleva 109 reglas de este tipo, y por debajo un seguimiento de flujo que persigue una variable hasta su origen — porque la clave casi nunca está escrita en la misma línea donde se usa.

Y hay tres cosas que ni siquiera son tu código

• El pasado de tu repositorio

  Borrar una clave del archivo no la borra del repositorio. El commit que la metió sigue ahí, y git log -p la enseña entera a cualquiera que tenga acceso — o a todo internet si el repositorio es público.

• El sitio que ya está publicado

  Tus usuarios no tocan tu código: tocan tu web. Las cabeceras, las cookies, el certificado, el DNS y si un desconocido puede mandar correos haciéndose pasar por tu dominio no viven en ningún archivo del proyecto.

• Mañana

  Un paquete que hoy sale limpio puede tener un CVE publicado la semana que viene sin que tú toques una línea. Un análisis es una foto; el riesgo se mueve.

En qué npm audit es mejor que nosotros

Cinco cosas, y no son de cortesía. Si te bastan, no necesitas nada más para las dependencias.

• Es gratis, sin cuenta y sin conexión

  Ya lo tienes instalado. No hay que registrarse en nada ni subir nada a ningún servidor.

• Lee tu árbol instalado directamente

  Sabe qué hay puesto de verdad en node_modules sin que le des nada. Nosotros necesitamos que tu lockfile entre en el análisis; si no, trabajamos sobre el rango que declara package.json, que es menos exacto.

• npm audit fix lo arregla por ti

  Actualiza y deja el proyecto funcionando. Nosotros te decimos a qué versión hay que subir; el comando lo escribes tú.

• Entiende yarn.lock

  Nosotros leemos package-lock.json y pnpm-lock.yaml. El de yarn, hoy, no.

• Corre dentro de tu CI sin depender de nadie

  Un paso más en el flujo de trabajo, sin llamar a ningún servicio externo.

Qué añadimos nosotros en las dependencias

• Preguntamos a OSV.dev en vivo

  La base pública de vulnerabilidades, en el momento del análisis. No una lista congelada el día que compilamos.

• También Python

  Leemos requirements.txt además de package.json. Un proyecto con las dos cosas se revisa entero.

• Callamos lo que ya estaba arreglado

  Antes de avisar comprobamos si el rango que ya declaraste permite instalar la versión corregida. Si un npm install normal lo resolvía, no te lo contamos como hallazgo: no queremos gastarte una tarde en algo que no era.

• Tu código no viaja

  La consulta a OSV.dev sale de tu navegador y solo lleva nombres de paquete y números de versión. Ni una línea de código.

Preguntas

Entonces, ¿npm audit no sirve?

Sirve, y hay que ejecutarlo. Es la mejor forma de saber si una librería que usas tiene un agujero conocido. Lo que no es, es una revisión de seguridad de tu aplicación — y el problema es que su resultado se lee como si lo fuera.

¿Por qué me salen avisos que no me afectan?

Porque cuenta también las dependencias de desarrollo, que nunca llegan a tus usuarios: un aviso en una herramienta de compilación no es un agujero en tu app. Ese ruido es la razón por la que mucha gente deja de mirar la salida, que es lo peor que puede pasar.

¿Y npm audit fix --force?

Sube versiones mayores y puede romperte el proyecto. Con --force estás aceptando cambios que rompen compatibilidad; conviene ejecutarlo con el árbol de trabajo limpio y probar antes de subir nada.

Uso pnpm o yarn, ¿cambia algo?

pnpm audit y yarn audit hacen lo mismo contra la misma clase de base de datos, con la misma frontera: dependencias sí, tu código no.

¿Necesito las dos cosas?

Sí, y no compiten: no miran el mismo sitio. npm audit revisa lo que instalaste; un escáner de código revisa lo que escribiste. Un proyecto puede tener cero avisos de npm y una clave de API publicada en GitHub.