NIS2 Artículo 23: Descripción general de los requisitos de notificación de incidentes
El Artículo 23 de NIS2 impone estrictas obligaciones de notificación de incidentes a las entidades esenciales e importantes. Las organizaciones deben reportar los incidentes significativos a su CSIRT nacional o autoridad competente dentro de plazos estrictos:
- Alerta temprana: En un plazo de 24 horas desde que se tenga conocimiento de un incidente significativo
- Notificación del incidente: En un plazo de 72 horas, proporcionando una evaluación inicial que incluya gravedad e impacto
- Informe final: En el plazo de un mes, incluyendo una descripción detallada, análisis de causa raíz y medidas de mitigación aplicadas
Para las organizaciones que entregan o mantienen software a través de pipelines CI/CD, los registros de pipeline y los registros de despliegue se convierten en evidencia crítica durante la investigación de incidentes y los informes regulatorios. Los auditores y responsables de cumplimiento deben asegurarse de que los entornos de pipeline estén configurados para producir y conservar la evidencia necesaria para cumplir con estas obligaciones.
Cómo los registros de pipelines CI/CD sirven como evidencia de incidentes
Cuando ocurre un incidente de seguridad — ya sea un despliegue comprometido, una brecha en la cadena de suministro o un cambio de código no autorizado — los investigadores necesitan reconstruir exactamente qué sucedió, cuándo y por quién. Los pipelines CI/CD están en una posición única para proporcionar esta evidencia porque se encuentran en la intersección de los cambios de código, los procesos de compilación, los análisis de seguridad y los despliegues en producción.
La evidencia del pipeline permite a las organizaciones:
- Establecer cronologías: Determinar con precisión cuándo un cambio malicioso o defectuoso entró en el proceso de entrega
- Identificar el alcance: Comprender qué artefactos, entornos y servicios se vieron afectados
- Demostrar diligencia debida: Mostrar a los reguladores que los controles apropiados (revisiones de código, análisis de seguridad, puertas de aprobación) estaban en funcionamiento
- Apoyar el análisis de causa raíz: Rastrear el incidente hasta su origen — ya sea una dependencia comprometida, un pipeline mal configurado o un error humano
Categorías de evidencia de pipeline requeridas
Cronologías de despliegue
Registros completos de cuándo ocurrió cada despliegue, en qué entorno y el resultado (éxito, fallo, reversión). Estos registros deben incluir marcas de tiempo sincronizadas con una fuente de tiempo fiable.
Registros de cambios
Registros que vinculan cada despliegue a cambios de código específicos, incluidos los identificadores de commit, las descripciones de cambios y el autor de cada cambio. Los registros de cambios deben demostrar una cadena ininterrumpida desde el commit de código hasta el despliegue en producción.
Registros de aprobación
Evidencia de que se obtuvieron las aprobaciones humanas requeridas antes del despliegue. Esto incluye aprobaciones de revisión de código, aprobaciones del comité asesor de cambios (CAB) donde corresponda, y cualquier autorización de cambio de emergencia con justificación posterior.
Resultados de análisis de seguridad
Registros de las puertas de seguridad automatizadas, incluyendo análisis estático, análisis de vulnerabilidades en dependencias, análisis de imágenes de contenedores y cualquier otra comprobación de seguridad integrada en el pipeline. Los resultados deben mostrar qué se analizó, los hallazgos y si el pipeline continuó o fue detenido.
Procedencia de artefactos
Registros que establecen el origen e integridad de los artefactos desplegados. Esto incluye registros de compilación que muestran cómo se construyeron los artefactos, sumas de verificación o firmas que verifican la integridad de los artefactos, y registros de qué código fuente y dependencias se utilizaron.
Requisitos de retención de evidencia
NIS2 no especifica un periodo de retención obligatorio único para toda la evidencia. Sin embargo, se aplican las siguientes consideraciones:
- El informe final del incidente vence en el plazo de un mes, por lo que toda la evidencia debe estar disponible al menos durante ese periodo
- Las autoridades competentes pueden solicitar información adicional durante investigaciones de seguimiento, que pueden extenderse mucho más allá del periodo de reporte inicial
- Las transposiciones de los estados miembros pueden imponer requisitos de retención específicos — las organizaciones deben verificar su legislación nacional de implementación
- Como línea base prudente, las organizaciones deben conservar la evidencia del pipeline durante un mínimo de 24 meses para cubrir los plazos de investigación, seguimientos regulatorios y posibles procedimientos legales
Mapeo de tipos de incidentes a evidencia de pipeline
| Tipo de incidente | Evidencia de pipeline requerida | Periodo de retención recomendado |
|---|---|---|
| Despliegue comprometido (código malicioso llega a producción) | Cronología completa de despliegue; registros de commit y cambios para la versión afectada; registros de aprobación; resultados de análisis de seguridad (especialmente puertas omitidas); procedencia e integridad de artefactos | Mínimo 24 meses |
| Compromiso de la cadena de suministro (dependencia o imagen base maliciosa) | SBOM para las compilaciones afectadas; registros de actualización de dependencias; procedencia de artefactos; registros de acceso al registro; informes de evaluación de proveedores | Mínimo 24 meses; conservar los SBOM durante el ciclo de vida del software afectado |
| Acceso no autorizado a la infraestructura de pipeline | Registros de autenticación y acceso al pipeline; historial de configuración RBAC; registros de verificación MFA; registros de acciones administrativas | Mínimo 24 meses |
| Exposición de datos a través de registros o artefactos del pipeline | Registros de ejecución del pipeline (para identificar qué datos fueron expuestos); registros de auditoría de gestión de secretos; registros de acceso al almacenamiento de artefactos | Mínimo 24 meses; puede extenderse según los requisitos de la autoridad de protección de datos |
| Manipulación del pipeline (modificación no autorizada de la configuración del pipeline) | Historial de cambios de configuración del pipeline; registros de acceso a la administración del pipeline; registros de commit para archivos de pipeline como código; registros de aprobación para cambios de pipeline | Mínimo 24 meses |
| Fallo de despliegue que causa interrupción del servicio | Registros de despliegue incluyendo detalles de errores; registros de reversión; registros de cambios; resultados de pruebas previas al despliegue; resultados de comprobaciones de salud posteriores al despliegue | Mínimo 18 meses |
Lista de verificación para auditores: preparación para incidentes en entornos CI/CD
Utilice esta lista de verificación para evaluar si el entorno CI/CD de una organización está preparado para respaldar las obligaciones de notificación de incidentes de NIS2:
Generación de evidencia
- ☐ Los registros del pipeline capturan el ciclo de vida completo: activación, compilación, análisis, aprobación, despliegue y resultado
- ☐ Cada despliegue está vinculado a un conjunto específico de cambios de código y aprobaciones
- ☐ Los resultados de los análisis de seguridad se registran y conservan independientemente de las interfaces de las herramientas de pipeline
- ☐ Los registros de procedencia de artefactos (entradas de compilación, sumas de verificación, firmas) se generan para cada versión
- ☐ Las marcas de tiempo en todos los componentes del pipeline están sincronizadas con una fuente de tiempo común y fiable
Integridad de la evidencia
- ☐ Los registros del pipeline se almacenan en un almacenamiento de solo adición o inmutable
- ☐ La integridad de los registros puede verificarse (p. ej., mediante sumas de verificación o encadenamiento criptográfico)
- ☐ El acceso al almacenamiento de registros está restringido y auditado por separado
- ☐ Los administradores del pipeline no pueden eliminar ni modificar los registros históricos
Retención de evidencia
- ☐ Existe una política de retención documentada que cubre la evidencia del pipeline CI/CD
- ☐ Los periodos de retención cumplen o superan los mínimos recomendados (24 meses como línea base)
- ☐ La retención se aplica automáticamente — no depende de intervención manual
- ☐ La evidencia permanece accesible y legible durante el periodo de retención (longevidad del formato)
Integración con la respuesta a incidentes
- ☐ El plan de respuesta a incidentes hace referencia explícita a la evidencia del pipeline CI/CD y cómo acceder a ella
- ☐ Los roles y responsabilidades para la recopilación de evidencia del pipeline durante incidentes están definidos
- ☐ La organización ha probado su capacidad para recuperar y analizar evidencia del pipeline bajo condiciones de incidente
- ☐ Existen rutas de escalada para incidentes que se originan en el pipeline CI/CD o lo afectan
Preparación para informes
- ☐ La organización puede producir una cronología de despliegue para cualquier servicio dentro del plazo de alerta temprana de 24 horas
- ☐ Los procedimientos de análisis de causa raíz incluyen la revisión de registros del pipeline como paso estándar
- ☐ Las plantillas de informes para las autoridades competentes incluyen secciones para evidencia relacionada con el pipeline
Recursos relacionados
Para la biblioteca completa de recursos de cumplimiento de NIS2, visite nuestro NIS2 Compliance Hub.
Para una descripción general de los principios de arquitectura de seguridad de NIS2 y cómo se aplican a la entrega de software, consulte NIS2 Security Architecture Explained.
Relacionado para auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- NIS2 Security Architecture
- Continuous Compliance via CI/CD
- How Auditors Review CI/CD
¿Nuevo en la auditoría CI/CD? Comience con nuestra Guía para Auditores.
