CAPÍTULO 10 · Operar también es desarrollar
El hallazgo necesita una historia de cierre
Detectar un aviso no nos dice todavía si el proyecto está afectado, y cambiar una línea en requirements.txt no demuestra que la versión corregida esté ejecutándose. Entre ambos momentos hay decisiones, pruebas y una entrega. Si no las relacionamos, podemos declarar resuelto un riesgo que continúa en el servicio.
Registramos el componente, el alcance, la prioridad y la acción elegida, junto con el responsable y la evidencia. Después comprobamos la actualización o mitigación y la conectamos con el artefacto desplegado. La comunicación al cliente se concentra en lo que requiere su atención, mientras el seguimiento técnico conserva también los asuntos menos urgentes.
Este cierre devuelve la seguridad al ciclo de entrega que ya conocemos. Paralelamente, la operación deja archivos, registros y residuos de construcción. Aunque ninguno sea una vulnerabilidad por sí mismo, su crecimiento puede impedir una nueva publicación. Necesitamos observar también el espacio que utiliza la plataforma.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Un hallazgo se cierra con evidencia
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Hallazgo. Aviso y versión confirmados
- Decisión. Riesgo, responsable y plazo
- Cambio. Actualiza y prueba artefacto
- Cierre. Verifica versión en destino
01 / EL PROBLEMA
¿Para qué sirve?
Un resultado de scanner sin decisión ni seguimiento se acumula como ruido. Hace falta demostrar qué versión cambió, por qué y si la corrección llegó a producción.
02 / COMPRENDER
El concepto, explicado
Un registro de riesgo incluye identificador del aviso, paquete, versión efectiva, rango afectado, versión corregida, aplicabilidad, prioridad, responsable y pruebas. Conserva enlaces y fecha de consulta.
No reportado, no aplicable, mitigado y corregido son estados diferentes. No aplicable necesita evidencia; mitigado necesita revisión de vigencia. Deduplicar por aviso evita repetir alertas sin ocultar cambios de riesgo.
Revisar diariamente puede ser apropiado, pero frecuencia y plazos se definen según exposición y operación. Un informe interno conserva resultados, incluso los que no generan comunicación externa.
Al cliente o responsable de producto comunica cambios importantes, impacto y decisión necesaria. Cerrar requiere comprobar versión desplegada y pruebas, no solo editar requirements.txt.
El informe interno identifica paquete, versión instalada, versión corregida, fuente, severidad, aplicabilidad, prioridad, responsable y prueba de cierre. La comunicación al cliente se reserva para riesgos accionables o decisiones que requieren su participación; no se confunde silencio hacia el cliente con ausencia de seguimiento interno.
Estados y evidencia de cierre
| Estado | Qué significa | Evidencia necesaria |
|---|---|---|
| No aplicable | Condiciones del aviso no se cumplen | Versión y análisis de superficie |
| Mitigado | Riesgo reducido sin corrección completa | Control efectivo y revisión pendiente |
| En pruebas | Cambio propuesto aún sin confirmar en destino | Build, inventario y resultados |
| Corregido | Versión corregida desplegada y comprobada | Artefacto, versión y pruebas en destino |
03 / CONSTRUIR
Implementación paso a paso
- Asigna una clave al hallazgo y relaciona avisos equivalentes.
- Registra evidencia de versión instalada y aplicabilidad sin inventar CVEs.
- Prioriza e identifica responsable y plazo; documenta aceptación temporal si corresponde.
- Propón un cambio reproducible y ejecuta instalación, pruebas y smoke tests.
- Publica mediante la estrategia del proyecto y comprueba versión en destino.
- Cierra con evidencia o conserva estado abierto si la mitigación no resuelve la causa.
04 / APLICAR
Ejemplo en SensorHub
# Ejemplo de registro sin una vulnerabilidad real atribuida a Django.
finding = {
"advisory": "<CVE/GHSA/OSV confirmado>",
"package": "<paquete>",
"installed": "<versión del artefacto>",
"fixed": "<versión verificada en aviso>",
"commit": "<commit desplegado>",
"applicability": "<superficie y evidencia>",
"priority": "<según política y contexto>",
"owner": "<responsable>",
"status": "analizando",
"tests": ["instalación limpia", "casos críticos", "smoke en destino"],
"closure_evidence": [],
}Cómo leer el ejemplo
- Los marcadores impiden presentar datos de ejemplo como CVEs reales.
- Un parche puede requerir pruebas de autenticación en una app privada; esta academia verifica sus rutas públicas.
- El cierre asocia evidencia al artefacto, no solo a una rama.
Error habitual
Avisar por cada release, silenciar indefinidamente un hallazgo o afirmar cumplimiento de un marco por ejecutar un scanner.
05 / PRACTICAR
Tu turno
El scanner no encuentra hallazgos nuevos pero hubo un error al consultar una fuente. Redacta estado y acción.
Ver solución orientativa
Indica revisión incompleta y la fuente que falló, conserva lo revisado y programa reintento interno. No declares ausencia de novedades hasta completar la cobertura definida.
06 / VERIFICAR
Cómo sabes que funciona
- Hallazgo tiene evidencia y decisión verificables.
- La mitigación tiene responsable y revisión.
- Cierre prueba versión desplegada.
- La comunicación distingue riesgo confirmado de revisión incompleta.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Kudu y diagnóstico de cuota de almacenamiento →Continuar en modo relato