Análisis de vulnerabilidades y parches
Resumen breve
La gestión de vulnerabilidades es un ciclo continuo: detección → evaluación de riesgos → resolución (parche/migración/configuración) → validación → presentación de informes. Las tecnologías de escaneo (SCA/SAST/DAST/IAST/Cloud/Container) dan señales y el contexto (exposición, privilegios, datos, EPSS, exploits) determina la prioridad. El objetivo es reducir el riesgo real sin downtime empresarial, utilizando automatización, plantillas canarias y SLO claros.
Taxonomía de escaneo
SCA (Software Composition Analysis): análisis de dependencias/licencias; detección de CVE en bibliotecas, SBOM.
SAST: análisis estático del código nativo antes del ensamblaje.
DAST: una «caja negra» dinámica contra el servicio en funcionamiento.
IAST: sensores dentro de la aplicación (durante las pruebas) - menos FP, más profundo contexto.
Container/OS Scan: imágenes (imagen base, paquetes), hosts (núcleo/paquetes/configuraciones), parámetros CIS.
Cloud/Infra (CSPM/KSPM): miscónfigos de nube/K8s (IAM, redes, cifrado, baquetas públicas).
Análisis de secretos: fugas de claves/tokens en repositorios e imágenes.
Análisis binario/artificial: validación de artefactos recogidos (firmas, vulnerabilidades).
Modelo de riesgo y priorización
Puntuación = CVSS v3. x (base) × EPSS (probabilidad de explotación) × contexto (exposición, datos, privilegios, medidas compensatorias).
Factores contextuales:- Exposición en Internet/interior, presencia de WAF/mTLS/aislamiento.
- Datos: PII/finanzas/secretos.
- Privilegios de proceso/nodo, potencial de movimiento lateral.
- Presencia de exploit público/ataques masivos, requisitos de cumplimiento.
Ejemplo de vector CVSS: 'CVSS: 3. 1/AV: N/AC: L/PR: N/UI: N/S: U/C: H/I: H/A: H '→ criticó; si el servicio es público y sin medidas compensatorias - P1.
Umbrales SLO (ejemplo):- P1 (crítico, explotado): fix ≤ 48 h.
- P2 (alto): fix ≤ 7 días.
- P3 (promedio): fix ≤ 30 días.
- P4 (baja/inform.) : planificado/por el backlog.
Ciclo de vida de gestión de vulnerabilidades
1. Inventario de activos: servicios, imágenes, clústeres, sistemas operativos, paquetes, dependencias, versiones.
2. Escaneo programado y por evento: commits, compilaciones, deploy, ventanas semanales/semanales.
3. Triage: deduplicación, normalización (CVE→Ticket), mapping al propietario.
4. Priorización por contexto: CVSS/EPSS + exposición/datos.
5. Remediación: parche/actualización de dependencia/config-hardnening/parche virtual (WAF).
6. Verificación: reescaneo, pruebas, canario.
7. Reporting: métricas de cierre, edad de vulnerabilidad, cumplimiento de SLO.
8. Lecciones: fix en plantillas (imagen base, lista de ayuda), política para el futuro.
Integración en CI/CD
En la etapa PR: SAST + SCA + secreto-escaneado; "break build' por P1/P2 o requisito de appruve.
En la etapa de construcción: escaneo de imagen, generación de SBOM (CycloneDX/SPDX), firma de artefactos (cosign).
En la fase deploy: Admission Policy (Admission) - la prohibición de imágenes con vulnerabilidades 'critical/high' y sin firma/SBOM.
Postdeplay: DAST/IAST contra el estaging y parcialmente la producción (perfiles seguros).
Ejemplo: Renovate/Dependabot (fragmento)
json
{
"extends": ["config:recommended"],
"vulnerabilityAlerts": { "enabled": true },
"packageRules": [
{ "matchUpdateTypes": ["minor","patch"], "automerge": true },
{ "matchManagers": ["dockerfile"], "enabled": true }
]
}
Política de tolerancia (Kubernetes, OPA/Gatekeeper - simplificado)
rego package policy.vuln
deny[msg] {
input.image.vuln.critical > 0 msg:= sprintf("Image %s has critical vulns", [input.image.name])
}
deny[msg] {
input.image.sbom == false msg:= sprintf("Image %s without SBOM", [input.image.name])
}
Gestión de parches (SO, contenedores, K8s)
ОС (Linux/Windows)
Ventana de parche: ventanas regulares + extraordinarias de emergencia para P1.
Estrategia: primero el canario 5-10% de los nudos, luego las olas.
Auto-volteo: Ansible/WSUS/Intune/SSM; comprobación de dependencias y revisiones.
Kernel Live Patching (siempre que sea posible) para minimizar el tiempo de inactividad.
Restart Services: drain/cordon administrado para K8s nod, graceful shutdown.
Contenedores
Enfoque immutable: no «apt upgrade» en el rantime; volver a recopilar la imagen con la base actualizada.
Imágenes básicas: actualizar regularmente las imágenes de oro (Alpine/Debian/Distroless), consolidar las versiones (digest).
Conjuntos multiestatales: minimizar la superficie (quitar build-tools).
Comprobación previa al descapotable: bloque de imágenes con CVE críticos.
Kubernetes/Service Mesh
Control Plane: lanzamientos menores oportunos, cierre de CVE k8s/etcd/containerd.
Node OS/Container runtime: actualizaciones programadas, compatibilidad de versiones.
Mesh/Ingress: las versiones Envoy/Istio/NGINX son críticas (a menudo CVE en parsers/NTTR3).
Políticas de la Administración: prohibición ': latest', requerimiento de firma, límites de vulnerabilidad.
Parches virtuales y medidas compensatorias
Cuando el parche no es posible rápidamente:- WAF/WAAP: firma/modelo positivo para un endpoint específico.
- Fichas: desactivar la funcionalidad vulnerable.
- ACL/mTLS/IP allow-list: restringir el acceso a un servicio vulnerable.
- Config Hardnening: rebaja de derechos, sandbox, FS read-only, desactivación de módulos peligrosos.
- Reducción de TTL de tokens/claves, rotación de secretos.
Administración de excepciones (Risk Acceptance)
La excepción se formaliza con un ticket con: justificación, medidas compensatorias, SLA por eliminación, fecha de revisión.
En los informes, etiquetar como «aceptación temporal del riesgo» e incluirlo en la revisión mensual.
Observabilidad y métricas
Técnicos:- Mean Time To Patch (MTTP) по P1/P2/P3.
- Participación en los activos cubiertos por el escaneo (%).
- Edad de las vulnerabilidades abiertas (p50/p90), backklog burn-down.
- Porcentaje de imágenes con SBOM y firma.
- Ejecución de SLO por fechas de cierre (por ejemplo, ≥ 95% P1 ≤ 48 h).
- Efecto sobre el aptime (cole-in incidentes en parches).
- Redescubrir los mismos CVE (calidad de fix en plantillas).
Playbucks (abreviado)
P1: RCE crítico en el servicio público
1. Activar la regla WAF/parche wirth.
2. Bloquear el acceso a fuentes no autorizadas (si es válido).
3. Reconfiguración urgente de la imagen/parche del sistema operativo, canario → las ondas.
4. Revisión de DAST/telemetría repetida, monitoreo de errores.
5. Post-incidente: fijar el fix en la imagen básica/Helm chart, añadir la prueba a CI.
1. Rotación inmediata de secretos/claves, revocación de tokens.
2. Búsqueda de huellas de uso, limitación de endpoints.
3. Análisis de repo/imágenes en secreto, introducción del escáner pre-commit.
Ejemplos de artefactos
1) Informe SQL sobre vulnerabilidades «calientes»
sql
SELECT service, cve, cvss, epss, exposed, has_exploit, created_at,
PRIORITY(exposed, has_exploit, cvss, epss) AS prio
FROM vuln_findings
WHERE status = 'open' AND (cvss >= 8.0 OR has_exploit = true)
ORDER BY prio DESC, created_at ASC;
2) Política de administración (Kyverno, bloque de vulnerabilidades críticas)
yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata:
name: block-critical-vulns spec:
validationFailureAction: Enforce rules:
- name: image-must-have-no-critical match: { resources: { kinds: ["Pod"] } }
validate:
message: "Image contains critical vulnerabilities"
pattern:
metadata:
annotations:
vuln.scanner/critical: "0"
3) Generación de SBOM y firma (fragmento de Makefile)
make sbom:
cyclonedx create --output sbom.json sign:
cosign sign --key cosign.key $(IMAGE_DIGEST)
Especificidad para iGaming/fintech
Zonas de alto riesgo: pasarelas de pago, backofis de pago, antifraude, procesamiento de PII/PAN - parches prioridad P1/P2.
Ventanas de servicio: alineación con torneos/promociones, cachés pre-warm, canarios en regiones de baja ocupación.
Regulación (PCI DSS/GDPR): plazos para la resolución de vulnerabilidades, pruebas (capturas de pantalla/informes), segmentación de zonas CHD, cifrado.
Integraciones de socios: requerir SDK/clientes versionados, SCA de mandato y HMAC/mTLS en webhooks.
Errores típicos
«Escanear todo es chineme nada»: no hay propietarios y SLO.
Enfoque sólo en CVSS sin contexto (exposición, EPSS, datos).
Parche en el rantime del contenedor en lugar de reconfigurar la imagen.
Ausencia de planes canarios/rollback.
Ignora los miscónfigos de nube/K8s (a menudo más críticos que CVE).
No hay SBOM/firma - trazabilidad débil (cadena de suministro).
Hoja de ruta para la implementación
1. Inventario de activos y propietarios; un único registro de servicios/imágenes.
2. Pila de escáneres: SCA/SAST/DAST/Container/Cloud + secret-scan; Integración en CI/CD.
3. Políticas de SLO y priorización: CVSS + EPSS + contexto; plantillas de tickets.
4. Admission/Policy-as-Code: prohibición de vulnerabilidades críticas, requerimiento de SBOM/firmas.
5. Procesos de parche: ventanas, canarios, retrocesos; piloto automático para versiones menores/parche.
6. Informes y métricas: MTTP, cobertura, edad; revisión semanal del riesgo.
7. Ejercicios regulares: simulación de CVE crítico, verificación de playbucks y rollback.
Resultado
La gestión madura de las vulnerabilidades es un proceso, no un «stripper» único: detección automática, priorización contextual, parches sin resistencia a través de canarios/rollback, policy-as-code en la entrada del prod y métricas de ejecución transparentes. Al fijar las ficciones en las imágenes y plantillas básicas, reduce el riesgo de repetición y mantiene la superficie de ataque bajo control constante.