`npm audit` marca una CVE crítica en una dependencia transitiva usada en producción. ¿Cuál es la respuesta correcta?
Respuesta breve
El código transitivo se ejecuta en tu aplicación, así que una CVE crítica es tu riesgo. Evalúa si la ruta de código vulnerable es realmente alcanzable, luego remedia subiendo o anulando la versión (o mitigando) y verifica en producción. Ignorarla por ser transitiva deja un agujero conocido que un atacante puede explotar. Silenciar la auditoría solo oculta el aviso. Reinstalar node_modules trae la misma versión vulnerable. Haz seguimiento mediante SCA, no la acalles.
Una dependencia transitiva es código que no elegiste directamente pero que aun así se entrega y ejecuta dentro de tu aplicación. Una CVE crítica en ella es tu vulnerabilidad, exactamente como si estuviera en tu propio código fuente. La respuesta profesional es triar y luego remediar, no descartar.
La respuesta correcta
- Evaluar la alcanzabilidad y la explotabilidad. ¿Tu aplicación llama realmente a la función o ruta vulnerable, con entrada influida por el atacante? Una puntuación CVSS crítica en una ruta de código inalcanzable supone menos riesgo real que un «medio» que invocas en cada solicitud. Esto prioriza el trabajo sin ignorar nunca el problema.
- Remediar. Actualiza el padre directo que arrastra la versión defectuosa; si no ha publicado una corrección, usa una resolución/
overridesde dependencia para forzar la versión transitiva parcheada, o aplica una mitigación documentada (configuración, WAF, desactivar la funcionalidad) como medida provisional. - Verificar y redesplegar, luego confirmar que el aviso desaparece en tu herramienta SCA.
Por qué los distractores son erróneos o arriesgados
- Ignorarla por ser transitiva es un malentendido de cómo funcionan las dependencias — el código se ejecuta sin importar quién lo declaró, y a los atacantes no les importa que no lo escribieras tú.
- Borrar node_modules y reinstalar vuelve a resolver a la misma versión vulnerable que permiten tus rangos/lockfile. No cambia nada respecto al aviso.
- Silenciar el aviso de la auditoría oculta la señal mientras el código explotable sigue en producción — el peor resultado, porque ya nadie le hace seguimiento.
Qué evalúa el entrevistador
Si tratas el riesgo de las dependencias como real y propio, sabes priorizar mediante alcanzabilidad en vez de entrar en pánico ante cada línea roja, y conoces los mecanismos concretos — overrides/resoluciones, comportamiento del lockfile y seguimiento SCA — para impulsar de verdad la corrección y evitar que regrese en silencio.
Posibles preguntas de seguimiento
- ¿Cómo fuerzas una versión corregida de una dependencia transitiva cuando el padre directo no se ha actualizado?
- ¿Qué aporta el análisis de «alcanzabilidad» frente a un recuento bruto de CVE, y cuáles son sus límites?
- ¿Cómo evitarías que esto se repita en muchos repositorios?