Saltar al contenido
ITDPlataforma de seguridad web
ITD
Buscar

Guías de seguridad

#CVE#dependencias#respuesta a vulnerabilidades#operaciones#preparación para la era de la IA

Corregir CVE de dependencias de verdad: escanear, corregir, aislar y seguir vigilando

Corregir CVE de dependencias no acaba con el parche. Una definición de «hecho» en 4 partes para equipos pequeños: escanear, corregir, aislar y monitorear.

Publicado 2026-06-11 Actualizado 2026-10-05 9 min de lectura
En esta página

Para: cualquiera que opere varias apps web (frameworks mezclados) con un equipo pequeño, y que quiera corregir las vulnerabilidades de dependencias (CVE) de verdad, de una vez. Sin pasos de ataque — solo la práctica de corregir, hacer que las correcciones perduren y seguir vigilando. Para el tipo de incidente que suele desencadenar esto, véase un RCE público descuidado facturado de forma fraudulenta.

La visión de este sitio: los equipos pequeños se mantienen seguros con dos disciplinas

Lo que funciona en un equipo pequeño no es el utillaje vistoso — son dos disciplinas: 1) detección automatizada de cambios (alertar solo de vulnerabilidades nuevas) y 2) local→push→deploy (producción recibe, nunca edita). Este sitio funciona igual: una auditoría de dependencias (pnpm audit) antes de cada despliegue más un cron diario, con push-to-deploy entregando a producción. Montar alertas que sigan funcionando, en lugar de tratarlo como una corrección puntual, es lo más barato que perdura.

Primero, decide las cuatro condiciones de «hecho»

Así evitas dar las cosas por «hechas» demasiado pronto. Decide de antemano: hasta que se cumplan las cuatro, está incompleto.

1. Escanear

poner el estado en números

2. Corregir

corregir en su origen los crít/altos que no son de dev

3. Aislar/delegar

hacer explícito lo no corregible

4. Monitorear

poner detección diaria de cambios

Trabajo de vulnerabilidades hecho = un conjunto de cuatro. Si falta uno, queda una vulnerabilidad aunque creas que ya lo corregiste.

1. Escanear: contar lo que tienes ahora

Primero, ve qué hay dónde, por máquina. Las comprobaciones manuales ad hoc siempre se descuidan.

1

Autodescubre lockfiles y escanea

Encuentra composer.lock / package-lock.json / pnpm-lock.yaml y pásalos a diario por un escáner de código abierto (osv-scanner o pnpm audit). Solo lee lockfiles, así que la carga es mínima.
2

Sabe que la gravedad no es un solo número

El mismo fallo puede ser Alto en CVSS (digamos 7.5) pero Moderado en la valoración revisada de un proveedor. CVSS se calcula por máquina y tiende a sobrecontar. Decide qué base fija tu umbral, y asegúrate de que todo el equipo sepa cuál está en uso (→ qué es CVSS). Crúzalo con si está realmente siendo explotado (KEV) para priorizar.
3

Excluye el ruido CON una razón registrada, no ignorando

Las dependencias de desarrollo solo para pruebas/compilación a menudo no están en el bundle de producción y pueden no conllevar riesgo real. Usa la agrupación del escáner para sacar las de dev de las notificaciones, pero registra por qué la excluiste. Mantente capaz de responder «¿esto no sigue sin corregir?» más tarde.

2. Corregir: actualizar la propia versión vulnerable

Una medida temporal que oculta el síntoma y una corrección de la causa real son trabajos distintos. Haz ambos para terminar.

Solo ocultar el síntoma (la causa sigue ahí)

  • bloquear solo las peticiones «de aspecto sospechoso» en un proxy inverso
  • el síntoma se detuvo, así que lo llamas «resuelto»
  • la dependencia vulnerable permanece — el RCE sigue siendo explotable

Corregir la causa (correcto)

  • actualiza la dependencia vulnerable a la versión parcheada
  • tras actualizar, confirma que la firma desaparece en tus registros
  • trata la medida temporal y la corrección real como dos trabajos distintos, haz ambos

Verifica la compilación de los saltos mayores ANTES de producción

A diferencia de un parche, un salto de versión mayor (framework 14→15, un kit de UI 4→6, etc.) conlleva cambios incompatibles. Actualizar sin comprobar y romper la compilación de producción deja el servicio caído. Pon el código editado en un entorno idéntico al de producción (mismo contenedor de versión de Node/PHP) y deja la compilación/comprobación de tipos totalmente en verde antes de hacer push. Resuelve los errores uno a uno (codemods sync→async, cadenas de clases CSS multilínea, un espacio de nombres de tipo global retirado, etc.). Si el contenedor antiguo sigue corriendo, un fallo revierte con cero tiempo de inactividad.

Comprueba que el siguiente despliegue no deshaga la corrección

Una corrección perfecta vale cero si el siguiente despliegue la borra. Este es el error más común.

1

No hagas commit sobre el árbol de trabajo de producción

Un commit directo en producción bifurca el historial del repositorio central, y el siguiente despliegue (pull / checkout -f) lo sobrescribe y la corrección desaparece. Producción es «donde aterrizan los resultados del despliegue», no donde editas.
2

Estandariza una sola dirección: local→push→deploy

Edita en local → commit → push → (producción) hace pull / despliega automáticamente. Incluso un cambio que tuviste que verificar en producción debe rebobinarse a local y volverse a hacer push (→ hacer que producción sea solo de recepción).
3

No confíes en el HTTP 200 como «sano»

En hosting compartido, un error fatal puede aun así devolver 200. Verifica con contenido real — ¿se renderiza el encabezado/texto esperado (curl | grep)?, ¿hay errores nuevos en los registros?, y recorre las rutas dinámicas (basadas en BD, parametrizadas), no solo la página de inicio. Las cachés pueden retrasar el cambio, así que espera o vacíalas primero.

3. Aislar/delegar: anotar lo que no puedes corregir

No siempre puedes corregir todo ahora. El truco es no dejar nunca «no se puede corregir / no es mi área / sin uso» en la ambigüedad.

1

Código huérfano/EOL: aísla ANTES de borrar

El código antiguo que ya no sirves (frameworks EOL, etc.) — no lo borres de golpe; renómbralo para aislarlo y deja una marca anotando cuándo/por qué y dónde solía servir. Quítalo también de los escaneos. «Borrar» es irreversible; «aislar» es reversible y conserva el rastro.
2

Confirma primero que de verdad no está referenciado

Rastrea la configuración del proxy inverso, el montaje de compilación y los puntos de montaje para confirmar que nada lo referencia antes de aislar — así evitas volver a servirlo por accidente.
3

Delega explícitamente lo que no puedes corregir

Para lo que está fuera de tu alcance, delégalo con «quién / qué» indicado, en lugar de dejarlo. El valor de un inventario es no dejar que lo no corregido se convierta en descuido invisible.

4. Monitorear: poner en marcha la detección diaria de cambios

Ahora, por fin, pon el mecanismo de alertas. Sin él, una corrección que hiciste no te avisará cuando reaparezca.

Alerta de lo NUEVO, no de todo cada día

Compara los resultados del escaneo contra la ejecución anterior (un archivo de estado) y notifica solo cuando aparece un nuevo crítico/alto. El mismo contenido cada día se ignora (fatiga de alertas). Resume en un solo correo (nuevo / resuelto / actual) en un cron diario. Hasta el hosting compartido maneja bien un binario de escáner + cron (la carga es de milisegundos; añade nice para mayor tranquilidad).

diff
notifica solo lo nuevo = sin fatiga
diario
mantenlo corriendo en cron
1 correo
resumen nuevo / resuelto / actual
los 4
hecho solo cuando el monitoreo está activo

Las claves de API y claves SSH que un inventario también encuentra

Corregir CVE de verdad tiende a sacar a la luz también problemas que no son de dependencias. Dos casos habituales: un archivo de secretos dejado en un directorio público (un token antiguo en la raíz web; si vino de una plantilla compartida, todos los sitios tienen el mismo problema) y una clave raíz entregada a un entorno que puede ser comprometido. Ambos crean el patrón «una fuga, todo», así que compruébalos en la misma pasada (cada uno merece su propio análisis a fondo). Para los fundamentos de secretos, véase guardar secretos de forma segura y la lista de base.

Leer a continuación

FAQ

Q¿Cuándo está «hecho» de verdad el trabajo de vulnerabilidades?
A

Solo cuando se alinean cuatro cosas: 1) escaneaste y pusiste el estado en números, 2) corregiste los críticos/altos que no son de desarrollo, 3) aislaste o delegaste explícitamente lo que no puedes corregir / el código huérfano, y 4) pusiste en marcha la detección diaria de cambios (monitoreo que capta problemas nuevos y recurrentes). Hasta que esté el 4, no está hecho — las dependencias vuelven a ser vulnerables mañana.

Q¿No causará fatiga de alertas el escaneo diario?
A

Alertar de todo a diario se ignora rápido. Compara contra el resultado anterior (un archivo de estado) y notifica solo cuando aparece un NUEVO crítico/alto — detección de cambios. No enviar lo mismo cada día es lo que hace que el monitoreo dure de verdad.

Q¿Por qué a veces una corrección revierte a vulnerable?
A

Hacer commit directamente sobre el árbol de trabajo de producción significa que el siguiente despliegue (un pull o checkout -f) sobrescribe y borra la corrección. Estandariza una sola dirección — local→push→deploy — y haz que producción sea «solo recepción». Una corrección perfecta sobre un flujo que la borra vale cero.