Mantén el software durante toda su vida útil

Asigna un responsable del servicio al mantenimiento

El software útil sigue cambiando después de su primera publicación. Las dependencias reciben correcciones. Los entornos de ejecución pierden soporte. Los certificados caducan. Las reglas de negocio cambian. El acceso concedido durante la configuración puede mantenerse más de lo previsto.

Mantén un inventario de servicios, responsables, versiones desplegadas, dependencias y fechas de soporte. Incluye trabajo programado y trabajo provocado por nuevos hallazgos. Reserva capacidad para ambos. Una lista de mantenimiento pendiente sin responsable no protege el servicio.

Separa el mantenimiento de la respuesta inmediata a incidentes. Una credencial expuesta o pruebas de un compromiso activo pueden exigir contención antes de que termine un ciclo normal de desarrollo. Deriva esos casos al proceso de respuesta de seguridad.

Prioriza la exposición real

La gravedad describe consecuencias potenciales. La prioridad también depende de la explotación, la posibilidad de alcanzar el comportamiento afectado, los datos, los controles existentes y el coste del retraso. Un servicio interno con poco tráfico puede contener credenciales importantes.

El catálogo de vulnerabilidades conocidas explotadas de CISA registra vulnerabilidades con pruebas de explotación. Úsalo como entrada para priorizar. Que una vulnerabilidad no aparezca en él no demuestra que sea segura. Catálogo de CISA.

Considera estos hallazgos ficticios. Los plazos pertenecen a la organización del ejemplo; no son fechas límite universales.

No conviertas automáticamente cada hallazgo en una actualización mayor. Elige una corrección con soporte, inspecciona la compatibilidad y prueba el comportamiento relevante. Registra las mitigaciones temporales con responsable y condición de caducidad.

Sigue la corrección hasta producción

Usa una secuencia trazable: hallazgo, decisión, cambio, revisión, despliegue y verificación. Registra el identificador del artefacto que producción utiliza realmente. Vuelve a analizar el artefacto o entorno pertinente después del cambio.

En un ejemplo ficticio con un paquete PDF vulnerable, el equipo hace merge de una actualización a las 10:00. A las 11:00, producción sigue ejecutando la imagen de ayer. La corrección del repositorio está terminada. La corrección en producción está incompleta.

Después del despliegue, verifica la versión del paquete y la generación de PDF. Un análisis de vulnerabilidades no demuestra que la exportación siga funcionando. Una prueba funcional no demuestra que se haya eliminado el componente vulnerable.

El SSDF de NIST incluye la identificación continua de vulnerabilidades y la respuesta a ellas. Aplica esas prácticas durante todo el ciclo de vida, también al software que recibe pocas peticiones de funciones nuevas. NIST SSDF.

Usa automatización con límites visibles

Taiga Maintaining analiza los repositorios vinculados y puede convertir hallazgos en iniciativas de corrección. Comprueba el último análisis satisfactorio, la versión afectada y el cambio resultante. Analizar el repositorio no demuestra si el comportamiento afectado es accesible en producción. Maintaining.

La automatización puede reducir el trabajo repetido, pero el servicio sigue necesitando responsables del despliegue y verificación. Mantén explícitas las decisiones de publicación, el acceso de emergencia y la caducidad de excepciones.

El mantenimiento también incluye la retirada. Elimina rutas, credenciales, integraciones e infraestructura sin uso mediante un proceso controlado. Comprueba los requisitos de conservación y los servicios dependientes antes de borrar. Retira el servicio en ejecución y asigna las obligaciones restantes de conservación o auditoría.

La siguiente lección explica en detalle el análisis continuo de vulnerabilidades y su corrección.