Guías de seguridad
Corregir CVE de dependencias de verdad: escanear, corregir, aislar y seguir vigilando
Manual práctico para corregir de verdad las vulnerabilidades de dependencias (CVE) en una flota pequeña, con una definición de «hecho» en 4 partes: escanear, corregir, aislar/delegar y monitorear, para que las correcciones no desaparezcan.
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. Tratar la seguridad como «un sistema que sigue disparándose», no «una corrección puntual», es lo más barato que perdura.
Primero, fija la «definición de hecho» en 4 partes
Una barrera contra declarar las cosas «hechas» de forma prematura. Decide de antemano: hasta que se alineen las cuatro, está incompleto.
1. Escanear
poner el estado en números
2. Corregir
corregir en la raíz 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
1. Escanear: convertir el estado en números
Primero, ve qué hay dónde, por máquina. Las comprobaciones manuales ad hoc siempre se descuidan.
Autodescubre lockfiles y escanea
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.Sabe que la gravedad no es un solo número
Excluye el ruido CON una razón registrada, no ignorando
2. Corregir: corrección de raíz, no ocultar el síntoma
Los primeros auxilios (ocultar el síntoma) y una corrección de raíz son trabajos distintos. Haz ambos para terminar.
Solo ocultar el síntoma (contención)
- 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 vivo
Corrección de raíz (correcta)
- actualiza la dependencia vulnerable a la versión parcheada
- tras actualizar, confirma que la firma desaparece en tus registros
- trata los primeros auxilios y la corrección de raíz 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. Saltar a ciegas y romper la compilación de producción es el peor caso. 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.
La finalización incluye la durabilidad de la corrección
Una corrección perfecta vale cero si el siguiente despliegue la borra. Esta es la trampa más común.
No hagas commit sobre el árbol de trabajo de producción
Estandariza una sola dirección: local→push→deploy
No confíes en el HTTP 200 como «sano»
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: hacer explícito lo no corregible
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.
Código huérfano/EOL: aísla ANTES de borrar
Confirma primero que de verdad no está referenciado
Delega explícitamente lo que no puedes corregir
4. Monitorear: solo con detección diaria de cambios está hecho
Ahora, por fin, pon el mecanismo de disparo. 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).
Los «secretos» y «claves» que un inventario también saca a la luz
Corregir CVE de verdad tiende a sacar a la luz también agujeros que no son de dependencias. Dos clásicos — 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 agujero) 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
- Monitoreo de dependencias: instalar y usar osv-scanner · no quedarse atrás con los CVE
- Incidente: un RCE público descuidado facturado de forma fraudulenta
- Operaciones: producción solo recibe / Git autoalojado vs GitHub
- Base: la lista de base de seguridad
FAQ
Q¿Cuándo está «hecho» de verdad el trabajo de vulnerabilidades?
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?
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?
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.