NIS2 Artículo 21(2)(d): Requisitos de seguridad de la cadena de suministro
El Artículo 21(2)(d) de NIS2 exige a las entidades esenciales e importantes que aborden la seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad en las relaciones entre cada entidad y sus proveedores directos o proveedores de servicios. Para las organizaciones que construyen y despliegan software a través de pipelines CI/CD, este requisito tiene implicaciones de gran alcance.
El pipeline CI/CD moderno es, por su naturaleza, una cadena de suministro. Cada compilación incorpora librerías de terceros, imágenes base, servicios externos y herramientas de múltiples proveedores. Un único componente comprometido en cualquier parte de esta cadena puede propagarse a través de pipelines automatizados hacia entornos de producción en cuestión de minutos. Los auditores deben, por tanto, evaluar no solo los controles propios de la organización, sino el marco de gobernanza que rodea cada elemento de terceros que entra en el pipeline de entrega.
Riesgos de terceros en entornos CI/CD
Comprender las categorías de riesgo de terceros en CI/CD es esencial para el alcance de una auditoría. Las siguientes áreas representan la superficie de riesgo principal:
Dependencias de código abierto
La mayoría de las aplicaciones modernas incorporan decenas o cientos de librerías de código abierto. Cada dependencia — y sus dependencias transitivas — representa una vulnerabilidad potencial o un vector de ataque. Los riesgos incluyen vulnerabilidades conocidas en paquetes desactualizados, paquetes maliciosos publicados bajo nombres similares (typosquatting) y cuentas de mantenedor comprometidas.
Plataforma CI/CD y herramientas SaaS
Las organizaciones frecuentemente dependen de plataformas SaaS de terceros para el control de código fuente, la ejecución de compilaciones, el almacenamiento de artefactos y la orquestación de despliegues. Estas plataformas tienen acceso privilegiado al código fuente, los secretos y los entornos de producción. Una brecha en cualquiera de estos proveedores podría comprometer todo el pipeline de entrega.
Runners de compilación compartidos y alojados
Los entornos de compilación que se comparten entre proyectos o están alojados por terceros introducen riesgos de contaminación cruzada, fuga de datos y aislamiento insuficiente. Si un runner de compilación se ve comprometido, todos los pipelines que lo utilizan se ven potencialmente afectados.
Imágenes base y registros de contenedores
Los despliegues basados en contenedores dependen de imágenes base que a menudo se obtienen de registros públicos. Estas imágenes pueden contener vulnerabilidades, componentes innecesarios que amplían la superficie de ataque o, en casos raros, contenido deliberadamente malicioso.
SCA y SBOM como herramientas de gobernanza de la cadena de suministro
Dos capacidades clave respaldan la gobernanza de la cadena de suministro en entornos CI/CD. Los auditores deben entender qué proporciona cada una y verificar que la organización las utiliza eficazmente.
Análisis de composición de software (SCA)
El SCA proporciona visibilidad sobre los componentes de terceros presentes en una aplicación. Desde una perspectiva de gobernanza, el SCA ofrece:
- Inventario de componentes: Una lista completa de todas las librerías de terceros y sus versiones utilizadas en cada compilación
- Identificación de vulnerabilidades: Mapeo de componentes frente a bases de datos de vulnerabilidades conocidas
- Cumplimiento de licencias: Identificación de obligaciones de licencia que puedan crear riesgos legales u operativos
- Aplicación de políticas: La capacidad de bloquear compilaciones que incluyan componentes prohibidos o de alto riesgo
Los auditores deben verificar que el SCA está integrado en el pipeline como una puerta obligatoria — no un paso de asesoramiento opcional — y que las violaciones de políticas resultan en despliegues bloqueados con procesos de excepción documentados.
Software Bill of Materials (SBOM)
Un SBOM es un inventario formal y legible por máquina de todos los componentes de un artefacto de software. Para la gobernanza de la cadena de suministro, los SBOM proporcionan:
- Transparencia: Un registro completo de lo que se incluye en cada artefacto desplegado
- Apoyo a la respuesta a incidentes: La capacidad de determinar rápidamente si una vulnerabilidad recién divulgada afecta a algún software desplegado
- Evidencia regulatoria: Prueba demostrable de conciencia y gestión de la cadena de suministro
- Responsabilidad del proveedor: Una base para responsabilizar a los proveedores de los componentes que suministran
Los auditores deben confirmar que los SBOM se generan para cada versión de producción, se almacenan con los periodos de retención apropiados y que la organización puede consultarlos para identificar los sistemas afectados cuando se divulgan nuevas vulnerabilidades.
Marco de evaluación de proveedores para proveedores de herramientas CI/CD
Las organizaciones deben evaluar la postura de seguridad de sus proveedores de herramientas CI/CD con el mismo rigor aplicado a cualquier proveedor de servicios críticos. El siguiente marco describe las áreas de evaluación clave:
Certificaciones y atestaciones de seguridad
- ¿Tiene el proveedor certificaciones relevantes (ISO 27001, SOC 2 Type II)?
- ¿Están los informes de auditoría actualizados y disponibles para su revisión?
- ¿Somete el proveedor regularmente sus sistemas a pruebas de penetración por evaluadores independientes?
Manejo de datos y aislamiento
- ¿Cómo aísla el proveedor los datos y entornos de compilación de los clientes?
- ¿Dónde se almacenan los datos y cumple esto con los requisitos de residencia de datos aplicables?
- ¿Qué cifrado se aplica a los datos en reposo y en tránsito?
Acceso y autenticación
- ¿El proveedor admite y aplica MFA para el acceso administrativo?
- ¿Qué acceso tiene el personal del proveedor a los entornos y datos de los clientes?
- ¿Los eventos de acceso privilegiado están registrados y disponibles para el cliente?
Notificación de incidentes
- ¿Cuáles son los compromisos y plazos de notificación de incidentes del proveedor?
- ¿Los SLAs contractuales se alinean con los plazos de reporte del Artículo 23 de NIS2?
- ¿Ha demostrado el proveedor la notificación de incidentes en la práctica?
Transparencia de la cadena de suministro
- ¿Divulga el proveedor sus propias dependencias de terceros y sub-procesadores?
- ¿Qué controles aplica el proveedor a su propia cadena de suministro?
- ¿Puede el proveedor proporcionar SBOM para sus productos?
Mapeo de riesgos, controles y evidencia de la cadena de suministro
| Riesgo de la cadena de suministro | Control | Evidencia para auditores |
|---|---|---|
| Dependencia de código abierto vulnerable | Análisis SCA obligatorio en tiempo de compilación con bloqueo basado en políticas de vulnerabilidades críticas/altas | Informes de análisis SCA por compilación; documentación de política de bloqueo; registros de excepción/exención con justificación y fechas de expiración |
| Inyección de paquetes maliciosos (typosquatting, dependency confusion) | Registro de paquetes aprobado con controles de espacio de nombres; fijación de dependencias y verificación de integridad | Configuración del registro aprobado; listas de permisos de paquetes; registros de verificación de integridad (validación de suma de verificación/firma) |
| Imagen base comprometida | Catálogo de imágenes base aprobadas; análisis de imágenes antes de su uso; firma y verificación de imágenes | Lista de imágenes aprobadas con fechas de revisión; informes de análisis de imágenes; registros de verificación de firmas |
| Brecha del proveedor de plataforma CI/CD | Evaluación de riesgos del proveedor; requisitos de seguridad contractuales; planificación de contingencia para el fallo del proveedor | Informes de evaluación de proveedores (actualizados en los últimos 12 meses); contratos con cláusulas de seguridad; planes de continuidad del negocio que cubren la pérdida de la plataforma CI/CD |
| Contaminación cruzada de runners compartidos | Entornos de compilación dedicados o efímeros; políticas de aislamiento de runners; limpieza del entorno tras la compilación | Documentación de arquitectura del entorno de compilación; atestaciones de configuración de aislamiento; registros de verificación de limpieza |
| Plugin o integración CI/CD comprometidos | Proceso de aprobación de plugins/integraciones; revisión periódica de plugins instalados; permisos de mínimo privilegio para integraciones | Registro de plugins aprobados; registros de revisión de plugins; matrices de permisos para integraciones |
| Falta de trazabilidad de componentes | Generación de SBOM para cada versión de producción; almacenamiento y capacidad de consulta de SBOM | SBOM de versiones recientes; evidencia de capacidad de consulta de SBOM (p. ej., respuesta a una consulta de vulnerabilidad de prueba); cumplimiento de la política de retención |
| Dependencia del proveedor que impide la migración de seguridad | Evaluación de estrategia multi-proveedor; evaluación de portabilidad de datos; planificación de salida | Análisis de dependencia de proveedores; documentación de capacidad de exportación de datos; plan de salida |
Señales de alerta que los auditores deben vigilar
Durante una evaluación de seguridad de la cadena de suministro de entornos CI/CD, los siguientes hallazgos deben generar preocupación inmediata:
- Sin política de gobernanza de dependencias: La organización no tiene una política documentada que rija el uso de componentes de terceros en las compilaciones. Esto sugiere una brecha fundamental en la conciencia de la cadena de suministro.
- El análisis SCA es solo orientativo: Los análisis de vulnerabilidades se ejecutan pero no bloquean los despliegues. Los desarrolladores pueden (y lo hacen) desplegar con vulnerabilidades críticas conocidas. Buscar evidencia de compilaciones que continúan a pesar de hallazgos de alta severidad.
- Sin generación de SBOM: La organización no puede producir un inventario de componentes para su software desplegado. Esto hace imposible evaluar la exposición a vulnerabilidades recién divulgadas.
- Evaluaciones de proveedores desactualizadas: Los proveedores de herramientas CI/CD fueron evaluados una vez (quizás durante la adquisición) pero no han sido reevaluados. Buscar fechas de evaluación con más de 12 meses de antigüedad.
- Acceso sin restricciones a registros públicos: Las compilaciones obtienen dependencias directamente de registros públicos sin un registro aprobado intermediario ni verificación de integridad. Esta es una exposición directa a ataques de dependency confusion y typosquatting.
- Sin gobernanza de imágenes base: Los equipos utilizan imágenes base arbitrarias de fuentes públicas sin análisis, aprobación ni fijación de versiones. Cada imagen no verificada es un potencial punto de entrada para compromisos.
- Runners compartidos sin evidencia de aislamiento: La organización utiliza infraestructura de compilación compartida pero no puede demostrar que las compilaciones están aisladas entre sí.
- Falta de requisitos de seguridad contractuales: Los acuerdos con los proveedores de herramientas CI/CD no contienen cláusulas de seguridad, obligaciones de notificación de incidentes ni derechos de auditoría.
- Sin proceso de gestión de excepciones: Cuando se omiten los controles de la cadena de suministro (p. ej., se acepta una dependencia vulnerable), no hay un proceso de excepción formal con justificación documentada, aceptación del riesgo y fecha de expiración.
- Plugins e integraciones sin revisión: Las plataformas CI/CD tienen numerosos plugins de terceros instalados sin evidencia de revisión de seguridad ni proceso de aprobación.
Lista de verificación del auditor para la cadena de suministro NIS2
Las secciones anteriores describen qué buscan los auditores y por qué. La lista de verificación siguiente convierte esas expectativas en una revisión estructurada de diez partes que refleja cómo examinan realmente los requisitos de la cadena de suministro de NIS2 los auditores y las autoridades de supervisión—poniendo el énfasis en la gobernanza, la aplicación técnica y la evidencia, más que en declaraciones de política de alto nivel. Utilícela para evaluar la preparación antes de una auditoría, o para guiar la preparación de evidencia una vez que la supervisión esté en marcha.
1. Alcance e identificación de proveedores
Enfoque del auditor
¿Están todos los proveedores relevantes identificados y dentro del alcance?
Lista de verificación
- ⬜ Existe un inventario de proveedores y se mantiene actualizado
- ⬜ El inventario incluye:
- proveedores de software
- plataformas CI/CD
- proveedores de cloud e infraestructura
- servicios ICT externalizados
- ⬜ Los proveedores están mapeados a los servicios o sistemas que soportan
- ⬜ El alcance de la cadena de suministro está formalmente documentado
Señales de alerta típicas
- Proveedores de CI/CD excluidos del alcance de proveedores
- Listas de proveedores incompletas o desactualizadas
2. Criticidad de proveedores y clasificación de riesgos
Enfoque del auditor
¿Se evalúan los riesgos de la cadena de suministro de forma proporcional?
Lista de verificación
- ⬜ Los proveedores están clasificados por criticidad
- ⬜ Los criterios de clasificación incluyen:
- impacto en los servicios esenciales
- nivel de acceso privilegiado
- sensibilidad de los datos
- sustituibilidad
- ⬜ Las evaluaciones de riesgos están documentadas y son repetibles
- ⬜ Los proveedores críticos están claramente identificados
Señales de alerta típicas
- Sin distinción entre proveedores críticos y no críticos
- Evaluaciones de riesgos realizadas de manera informal
3. Gobernanza y titularidad de proveedores
Enfoque del auditor
¿Quién es responsable del riesgo de proveedores?
Lista de verificación
- ⬜ Cada proveedor tiene un responsable interno claramente asignado
- ⬜ Los roles de gobernanza de proveedores están definidos
- ⬜ Se realizan revisiones periódicas de proveedores
- ⬜ Los riesgos relacionados con proveedores se escalan de forma adecuada
Señales de alerta típicas
- Titularidad de proveedores poco clara o implícita
- Sin evidencia de supervisión continua de proveedores
4. Controles de adquisición y contractuales
Enfoque del auditor
¿Son exigibles los requisitos de ciberseguridad?
Lista de verificación
- ⬜ Requisitos de ciberseguridad integrados en la adquisición
- ⬜ Los contratos incluyen:
- obligaciones de seguridad
- requisitos de notificación de incidentes
- cláusulas de cooperación
- ⬜ Cláusulas de seguridad aplicadas de forma coherente a los proveedores críticos
- ⬜ Las excepciones contractuales están documentadas y justificadas
Señales de alerta típicas
- Requisitos de seguridad aplicados de forma incoherente
- Sin trazabilidad entre los contratos y las evaluaciones de riesgos
5. Controles de la cadena de suministro en CI/CD
Enfoque del auditor
¿Cómo se aplica técnicamente el riesgo de la cadena de suministro?
Lista de verificación
- ⬜ Los pipelines de CI/CD son obligatorios para los cambios en producción
- ⬜ El acceso a las plataformas CI/CD está restringido (RBAC, MFA)
- ⬜ Las modificaciones de los pipelines están controladas y registradas
- ⬜ La segregación de funciones se aplica mediante aprobaciones
- ⬜ Las integraciones de terceros en CI/CD están gobernadas
Señales de alerta típicas
- Despliegues manuales o fuera de banda
- Cuentas de servicio CI/CD con privilegios excesivos
6. Controles de dependencias e integridad del software
Enfoque del auditor
¿Cómo se confía en lo que se despliega?
Lista de verificación
- ⬜ Existen inventarios de dependencias para las aplicaciones críticas
- ⬜ Se realiza el análisis de dependencias (SCA)
- ⬜ Las vulnerabilidades críticas desencadenan una remediación o una decisión
- ⬜ Los SBOM están disponibles para los sistemas críticos (cuando proceda)
- ⬜ Se garantizan la integridad y la procedencia de los artefactos
Señales de alerta típicas
- Sin visibilidad sobre las dependencias
- Incapacidad para rastrear los artefactos desplegados
7. Gestión del acceso de terceros
Enfoque del auditor
¿Tienen los proveedores acceso controlado?
Lista de verificación
- ⬜ Las cuentas de terceros y de servicio están inventariadas
- ⬜ El acceso sigue los principios de mínimo privilegio
- ⬜ El acceso privilegiado está aprobado y registrado
- ⬜ Se realizan revisiones periódicas de acceso
- ⬜ Existen procedimientos de revocación de acceso
Señales de alerta típicas
- Cuentas de proveedores de larga duración sin revisión
- Credenciales compartidas o no documentadas
8. Monitorización y detección
Enfoque del auditor
¿Puede detectar eventos relacionados con la cadena de suministro?
Lista de verificación
- ⬜ La actividad de los pipelines de CI/CD está monitorizada
- ⬜ Las alertas de vulnerabilidades de dependencias están monitorizadas
- ⬜ Las anomalías relacionadas con proveedores son detectables
- ⬜ Las alertas tienen rutas de escalado definidas
Señales de alerta típicas
- Existen registros pero no se revisan
- Sin alertas para problemas de CI/CD o de dependencias
9. Respuesta a incidentes y coordinación con proveedores
Enfoque del auditor
¿Está preparado para incidentes de proveedores?
Lista de verificación
- ⬜ Los planes de respuesta a incidentes incluyen escenarios de proveedores
- ⬜ Las rutas de escalado y notificación de proveedores están definidas
- ⬜ Capacidad para revocar el acceso de proveedores con rapidez
- ⬜ Se realizan simulaciones o pruebas de incidentes
- ⬜ Las revisiones posincidente están documentadas
Señales de alerta típicas
- Incidentes de proveedores gestionados de forma ad hoc
- Sin proceso de coordinación documentado
10. Retención de evidencia y auditabilidad
Enfoque del auditor
¿Puede producirse evidencia bajo demanda?
Lista de verificación
- ⬜ Los periodos de retención de evidencia están definidos
- ⬜ Los registros de CI/CD y de seguridad se conservan
- ⬜ La documentación de proveedores está archivada
- ⬜ La evidencia histórica puede recuperarse
Señales de alerta típicas
- Periodos de retención cortos
- Evidencia dispersa entre sistemas
Preguntas finales de evaluación del auditor
Antes de cerrar una auditoría, los supervisores suelen preguntarse:
- ¿Se comprenden claramente los riesgos de la cadena de suministro?
- ¿Se aplican los controles técnicamente, no solo documentados?
- ¿Es la evidencia fiable, completa y recuperable?
- ¿Se trata el CI/CD como parte del entorno regulado?
Si estas preguntas pueden responderse con confianza, la preparación de la cadena de suministro para NIS2 suele considerarse satisfactoria.
Recursos relacionados
Para un examen completo de los requisitos de seguridad de la cadena de suministro de NIS2 y sus implicaciones para CI/CD y la gestión de proveedores, consulte Análisis en profundidad de la seguridad de la cadena de suministro de NIS2: qué significa realmente para CI/CD y proveedores.
Relacionado para auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- DORA Artículo 28 explicado
- Comparación NIS2 vs DORA
- Controles básicos de seguridad de CI/CD
¿Nuevo en la auditoría de CI/CD? Comience con nuestra Guía para auditores.
