Gestión de Vulnerabilidades

Resumen Ejecutivo

Proceso estructurado para que ninguna vulnerabilidad se quede sin atender, con SLAs mandatorios y escalamiento formal.

• Valor: SLAs claros por severidad (24h para Críticas, 7d para Altas) con bloqueo automático de deploy a producción.
• Eficiencia: El pipeline detecta, notifica y bloquea automáticamente — el equipo solo interviene para remediar y verificar.
• Riesgo sin esto: Vulnerabilidades conocidas llegan a producción por falta de seguimiento, creando exposición regulatoria (PCI-DSS, ISO 27001) y riesgo operativo.

La Gestión de Vulnerabilidades es el proceso continuo que nos permite identificar, clasificar, priorizar, remediar y mitigar las debilidades de seguridad en nuestro software. En HERA, este proceso está integrado en el ciclo de vida del desarrollo para ser lo más ágil y eficiente posible.

Ciclo de Gestión de Vulnerabilidades

Seguimos un ciclo estructurado para asegurar que ninguna vulnerabilidad se quede sin atender.

Ciclo de Gestión de Vulnerabilidades

1

Detección

Pipeline
(SAST, SCA…)

2

Triaje

Clasificar
Severidad / SLA

3

Asignación

Crear Issue
en GitLab

4

Remediación

Corregir
Código/Dep

6

Cerrar

Cerrar Issue
Documentar

5

Verificar

Pipeline
Verifica Fix

SLAs de Remediación Obligatorios

Crítica 24 horas Bloquea PRD

Alta 7 días Bloquea PRD

Media 30 días No bloquea

Baja 90 días No bloquea

Mensaje clave Identificación continua en cada push. Critical/High bloquean el deploy a PRD.

---

Clasificación de Severidad y SLAs

Toda vulnerabilidad detectada es clasificada según su severidad, lo que determina la urgencia de su corrección a través de un SLA (Service Level Agreement).

SLAs Obligatorios de Remediación

Estos tiempos de respuesta son mandatorios y se miden desde el momento de la detección automática en el pipeline.

Severidad	CVSS Score	SLA de Remediación	Bloquea Deploy a PRD
Crítica	9.0 - 10.0	24 horas	Sí
Alta	7.0 - 8.9	7 días	Sí
Media	4.0 - 6.9	30 días	No
Baja	0.1 - 3.9	90 días	No

• Bloqueo de Deploy: Las vulnerabilidades Críticas y Altas no solo deben ser corregidas dentro de su SLA, sino que su mera presencia en la rama main impedirá un despliegue a producción. El pipeline fallará.

Proceso de Triaje y Remediación

1. Detección y Notificación: El pipeline de GitLab detecta una vulnerabilidad. Si es Crítica o Alta, el pipeline falla y notifica al equipo de desarrollo en el Merge Request o en el canal de Google Chat.

2. Creación de Issue: El Tech Lead o un desarrollador designado es responsable de crear un Issue en GitLab para dar seguimiento a la vulnerabilidad. Este Issue debe ser etiquetado correctamente (ej. ~security, ~vulnerability, ~critical).

3. Asignación y Remediación: El Issue se asigna a un desarrollador, quien trabaja en una nueva rama para corregir el problema.

4. Verificación:

   • El desarrollador sube la corrección y crea un nuevo Merge Request.
   • El pipeline se ejecuta de nuevo en esta nueva rama.
   • Las herramientas de seguridad (SonarQube, Docker Scout) verifican automáticamente que la vulnerabilidad ha sido eliminada.
   • Si el pipeline pasa, el fix se integra.

5. Cierre: Una vez que la corrección ha sido integrada a develop, el Issue de GitLab asociado a la vulnerabilidad puede ser cerrado.

Excepciones y Aceptación de Riesgo

Entendemos que no todas las vulnerabilidades pueden ser corregidas de inmediato. Para estos casos, existe un proceso formal de aceptación de riesgo.

Proceso de Excepción

Una excepción no es una forma de ignorar una vulnerabilidad, sino un reconocimiento formal y temporal del riesgo, con controles mitigantes y un plan de acción.

Para solicitar una excepción:

1. Documentar el Caso: Crea un issue en GitLab explicando por qué la vulnerabilidad no puede ser remediada inmediatamente.
2. Proponer Controles Mitigantes: Describe qué otras medidas de seguridad existen para reducir el riesgo (ej. “La vulnerabilidad está en un servicio interno no expuesto a internet”).
3. Solicitar Aprobación: La aprobación depende de la severidad:
   • Media/Baja: Requiere aprobación del Tech Lead y del Equipo de Seguridad.
   • Alta/Crítica: Requiere aprobación del CISO y del Director de TI.
4. Plazo de Excepción: Las excepciones son temporales (máximo 90 días) y deben ser re-evaluadas al vencer el plazo.