Su canal de CI acaba de ponerse rojo: Dependabot informa un CVE "crítico" en una biblioteca transitiva. El equipo entra en pánico, alguien sugiere una revisión al final del día; luego descubrimos que el módulo infractor nunca se carga en producción, que reside en una herramienta de compilación y que la versión realmente instalada no es la que aparece en el boletín. Resultado: una noche de insomnio por un riesgo teórico, mientras una vulnerabilidad XSS expuesta en la API pública todavía espera su turno.
El problema no es la falta de alertas. Esto es la ausencia de clasificación: tratar cada CVE como urgente equivale a no priorizar ninguno.
Lo que no dice una alerta
Un escáner de dependencias compara las versiones de los paquetes con una base de datos de vulnerabilidades conocidas. No conoce su arquitectura, sus firewalls ni si se puede acceder al código vulnerable desde Internet.
Tres filtros separan el ruido del riesgo real:
| Señal | Lo que indica | Límite |
|---|---|---|
| Puntuación CVSS | Gravedad teórica | Ignora la exposición local |
| Accesibilidad (Snyk, Grype…) | Ruta de llamada en tu código | Depende del análisis estático |
| Superficie de red | Puerto abierto, autenticación, WAF | Para mapearse usted mismo |
Un CVE “9.8” en una dependencia devDependencies no tiene la misma urgencia que un “6.5” en su punto final de autenticación pública.
Exposición del mapa antes de parchear
Antes de abrir una solicitud de extracción, responda cuatro preguntas en este orden.
1. ¿Dónde se ejecuta el componente? Producción, preparación, CI, estación de desarrollo: cada entorno tiene su propio SLA. Una falla en una imagen de prueba de Docker no justifica una implementación de emergencia el viernes por la noche.
2. ¿Es accesible desde el exterior? Un servidor detrás de una VPN, sin puerto público y sin proxy inverso expuesto reduce en gran medida la probabilidad de explotación oportunista.
3. ¿Qué privilegios obtendría el atacante? RCE como root en un pod aislado sin acceso a datos confidenciales ≠ RCE en la base de datos principal de PostgreSQL.
4. ¿Existe explotación activa (boletines de KEV, CERT)? Las vulnerabilidades enumeradas como explotadas activamente pasan al frente de la fila, incluso con una puntuación CVSS promedio.
Cuadrícula de priorización operativa
Aquí hay una cuadrícula pragmática para un equipo web alojado en VPS o en la nube:
| Nivel | Criterios | Plazo objetivo |
|---|---|---|
| P0 | Explotación activa + superficie pública | Solución o solución alternativa < 24 horas |
| P1 | RCE/LFI en servicio expuesto, no se conoce ningún exploit | < 7 días |
| P2 | Dependencia de producción, no expuesta directamente | Próximo ciclo de lanzamiento |
| P3 | Desarrollo/pruebas, herramientas internas | Trabajo pendiente mensual |
Las medidas compensatorias son importantes: bloquear un punto final, restringir un rango de IP, activar una regla WAF o eliminar temporalmente una característica puede tomar el tiempo de un parche limpio.
SBOM, archivos de bloqueo y continuidad
Sin un inventario confiable, no se sabe qué se está ejecutando realmente. Los Lockfiles (package-lock.json, composer.lock, poetry.lock) y las imágenes congeladas de Docker son su fuente de verdad, no solo el declarativo package.json.
Genere una SBOM (lista de materiales de software) con cada compilación, guárdela con el artefacto implementado y vuelva a escanear las imágenes que ya están en producción cuando aparezcan nuevos CVE. Esta es la única manera de responder honestamente a la pregunta “¿estamos afectados?” » sin reiniciar una auditoría manual.
La cumbre: la tasa de parches no mide la seguridad
Esto es lo que cubren los paneles "100% de CVE corregidos en 48 horas".
Los equipos que clasifican por exposición solucionan menos tickets y asumen menos riesgos.
Decide y avanza sin puntos ciegos
- Adjunte una cuadrícula P0–P3 y compártala con el producto y el alojamiento.
- Conecte el escaneo al CI bloqueando solo las alertas accesibles en producción.
- Revise las soluciones alternativas cada semana: un WAF temporal no debería volverse permanente.
- Pruebe la reversión después de un parche de dependencia importante, especialmente en PHP, Node o Python, donde los cambios importantes son comunes.
Para elegir un host capaz de soportar sus ciclos de parches (instantáneas, puesta en escena de espejo, reversión), explore nuestro directorio o la comparación.
Preguntas frecuentes
¿Deben corregirse inmediatamente todas las alertas de Dependabot o Snyk?
No. Primero arregle lo que está expuesto a la red o se ejecuta con privilegios elevados. Un CVE crítico en una dependencia de prueba puede esperar un ciclo programado.
¿Cómo sé si una vulnerabilidad realmente puede ser aprovechada por mí?
Haga una referencia cruzada de la ruta de la llamada, la versión exacta instalada, la configuración de la red y la evidencia de explotación activa. Una puntuación CVSS por sí sola no es suficiente.
¿Qué hacer cuando la actualización rompe la compatibilidad?
Documente una solución temporal con una fecha de vencimiento. Una vulnerabilidad sin parches y sin medidas compensatorias es una deuda asumida.
SBOM y escaneo automático, ¿por dónde empezar?
Genere un inventario de dependencias en producción, conecte un escáner al IC y luego clasifique las alertas por exposición antes de establecer SLA.
La próxima alerta roja no pregunta "parcheemos todo", sino "¿dónde está la exposición real?"