Introducción: Por qué A.14 es el control fundamental para CI/CD
El Anexo A.14 — Adquisición, desarrollo y mantenimiento de sistemas — es el dominio de control más relevante para las organizaciones que operan pipelines CI/CD. Rige directamente cómo se desarrollan, modifican, prueban y aceptan los sistemas en producción. Para auditores y responsables de cumplimiento, A.14 es donde encontrará la mayor densidad de requisitos de control específicos de CI/CD y, a menudo, la mayor densidad de no conformidades.
Este análisis profundo examina cada subcontrol de A.14 en el contexto de los pipelines CI/CD, proporcionando orientación clara sobre qué aspecto tiene el cumplimiento, qué evidencia se requiere y qué constituye una señal de alerta durante la auditoría.
A.14.1 — Requisitos de seguridad de los sistemas de información
A.14.1.1 — Análisis y especificación de requisitos de seguridad de la información
Qué significa para CI/CD: Antes de que se desarrolle o adquiera cualquier sistema, deben definirse los requisitos de seguridad. En un contexto CI/CD, esto significa que los requisitos de seguridad se especifican antes de que comience el desarrollo y son rastreables a través del pipeline — desde la definición de requisitos hasta la verificación del despliegue.
Evidencia que demuestra cumplimiento:
- Requisitos de seguridad documentados en historias de usuario, criterios de aceptación o especificaciones de requisitos de seguridad dedicadas
- Trazabilidad desde los requisitos de seguridad hasta los casos de prueba aplicados por el pipeline
- Registros que muestran que los requisitos de seguridad fueron revisados y aprobados antes de que comenzara el desarrollo
Cómo se ve el incumplimiento: Los requisitos de seguridad están ausentes, son informales o se agregan de forma retroactiva después del desarrollo. No existe vínculo entre los requisitos declarados y la verificación automatizada en el pipeline.
A.14.1.2 — Seguridad de los servicios de aplicaciones en redes públicas
Qué significa para CI/CD: Las aplicaciones desplegadas a través de pipelines CI/CD en entornos de acceso público deben tener controles para la integridad de datos, la confidencialidad y el no repudio. El propio pipeline debe verificar que las configuraciones TLS, los controles de seguridad de API y los mecanismos de autenticación estén correctamente configurados antes del despliegue.
Evidencia que demuestra cumplimiento:
- Etapas del pipeline que verifican la configuración TLS y la validez de los certificados
- Comprobaciones automatizadas de cabeceras de seguridad y seguridad de transporte
- Registros de verificación de configuración de seguridad antes del despliegue público
Cómo se ve el incumplimiento: Aplicaciones desplegadas en redes públicas sin verificación automatizada de configuración de seguridad. Sin comprobaciones previas al despliegue para la seguridad de transporte.
A.14.1.3 — Protección de transacciones en servicios de aplicaciones
Qué significa para CI/CD: Donde las aplicaciones manejan transacciones, el pipeline debe incluir la verificación de que los controles de integridad de transacciones (transmisión completa, validación de enrutamiento, integridad del mensaje, confidencialidad) están implementados y probados.
Evidencia que demuestra cumplimiento:
- Suites de pruebas de integración que cubren escenarios de integridad de transacciones ejecutadas en el pipeline
- Registros de resultados de pruebas de seguridad de transacciones conservados con el historial de ejecución del pipeline
Cómo se ve el incumplimiento: Aplicaciones que manejan transacciones desplegadas sin pruebas de integración de controles de seguridad de transacciones.
A.14.2 — Seguridad en los procesos de desarrollo y soporte
A.14.2.1 — Política de desarrollo seguro
Qué significa para CI/CD: La organización debe tener una política documentada que rija las prácticas de desarrollo seguro. En entornos CI/CD, esta política debe abordar los procesos automatizados de compilación y despliegue, los controles de seguridad del pipeline y la integración de pruebas de seguridad en el pipeline de entrega.
Evidencia que demuestra cumplimiento:
- Política de desarrollo seguro aprobada que cubre explícitamente los procesos CI/CD
- Registros de revisión de políticas que muestran actualizaciones regulares
- Evidencia de comunicación de la política a todos los usuarios y administradores del pipeline
- Registros de formación del personal involucrado en la gestión del pipeline
Cómo se ve el incumplimiento: La política de desarrollo seguro existe pero no hace referencia a pipelines CI/CD ni a procesos automatizados. La política no ha sido revisada desde la adopción de CI/CD.
A.14.2.2 — Procedimientos de control de cambios en sistemas
Qué significa para CI/CD: Este es un control fundamental para CI/CD. Todos los cambios en los sistemas deben seguir procedimientos formales de control de cambios. En CI/CD, el pipeline es el mecanismo de control de cambios — pero debe aplicar procedimientos documentados que incluyan requisitos de aprobación, evaluación de impacto, verificación de pruebas y capacidad de reversión.
Evidencia que demuestra cumplimiento:
- Procedimientos de control de cambios que referencian el pipeline CI/CD como mecanismo de aplicación
- Configuraciones del pipeline que muestran puertas de aprobación obligatorias antes del despliegue en producción
- Rastros de auditoría de todos los cambios incluyendo quién inició, quién aprobó, qué se probó y el resultado del despliegue
- Evidencia de que los procedimientos de cambios de emergencia están definidos y se siguen (con aprobación retrospectiva)
Cómo se ve el incumplimiento: Los desarrolladores pueden enviar cambios directamente a producción omitiendo el pipeline. Sin puertas de aprobación en el pipeline. Los cambios de emergencia no tienen proceso de revisión retrospectiva.
A.14.2.3 — Revisión técnica de aplicaciones tras cambios en la plataforma operativa
Qué significa para CI/CD: Cuando la plataforma subyacente cambia (actualizaciones del sistema operativo, actualizaciones de middleware, cambios de infraestructura), las aplicaciones deben revisarse y probarse. Los pipelines CI/CD deben activar pruebas de regresión cuando cambian las dependencias de la plataforma.
Evidencia que demuestra cumplimiento:
- Procedimiento documentado para la evaluación del impacto de cambios de plataforma
- Registros de ejecuciones de pruebas de regresión activadas por cambios de plataforma
- Evidencia de que las imágenes base del pipeline y las dependencias de la plataforma están bajo control de versiones con seguimiento de cambios
Cómo se ve el incumplimiento: Se realizan cambios de plataforma sin activar pruebas de regresión de aplicaciones. Sin seguimiento de versiones de dependencias de plataforma en el pipeline.
A.14.2.4 — Restricciones sobre cambios en paquetes de software
Qué significa para CI/CD: Las modificaciones a paquetes de software suministrados por proveedores o de terceros deben controlarse y limitarse. En CI/CD, esto cubre las modificaciones a componentes de código abierto, dependencias bifurcadas e integraciones de terceros personalizadas.
Evidencia que demuestra cumplimiento:
- Política que define cuándo se permite la modificación de paquetes de terceros
- Registros de aprobación de cualquier modificación a paquetes de terceros
- Controles de pipeline que detectan y marcan paquetes modificados (verificación de integridad, validación de suma de verificación)
- Notificaciones al proveedor y evaluaciones de impacto en el soporte para paquetes modificados
Cómo se ve el incumplimiento: Los paquetes de terceros se bifurcan o modifican habitualmente sin aprobación formal. Sin verificación de integridad en el pipeline para modificaciones de paquetes.
A.14.2.5 — Principios de ingeniería de sistemas seguros
Qué significa para CI/CD: La organización debe establecer, documentar y aplicar principios de ingeniería segura a todo el desarrollo de sistemas. El pipeline CI/CD debe aplicar estos principios a través de comprobaciones automatizadas — revisiones de arquitectura, validación de patrones de seguridad y verificación de cumplimiento.
Evidencia que demuestra cumplimiento:
- Principios de ingeniería segura documentados aplicables a los sistemas entregados por CI/CD
- Comprobaciones aplicadas por el pipeline que validan la adherencia a los principios de ingeniería
- Registros de revisión de arquitectura para nuevos sistemas que entran en el pipeline
- Evidencia de que los principios de ingeniería segura se revisan y actualizan periódicamente
Cómo se ve el incumplimiento: Los principios de ingeniería segura existen en papel pero no se aplican a través del pipeline. Sin verificación automatizada de patrones de arquitectura de seguridad.
A.14.2.6 — Entorno de desarrollo seguro
Qué significa para CI/CD: Los entornos de desarrollo — incluidos los entornos de compilación CI/CD — deben estar asegurados y protegidos. Los agentes de compilación, los repositorios de artefactos y las plataformas de orquestación del pipeline son entornos de desarrollo que requieren controles de seguridad apropiados.
Evidencia que demuestra cumplimiento:
- Controles de seguridad aplicados a los entornos de compilación CI/CD (segmentación de red, control de acceso, hardening)
- Evidencia de aislamiento del entorno de compilación (agentes de compilación efímeros, aislamiento de contenedores)
- Registros de control de acceso para la infraestructura de desarrollo y compilación
- Estándares de hardening aplicados a la infraestructura de la plataforma CI/CD
Cómo se ve el incumplimiento: Los entornos de compilación comparten infraestructura con producción sin aislamiento. Los agentes de compilación son de larga duración con estado acumulado y sin reconstrucción periódica. Sin estándares de hardening para la infraestructura CI/CD.
A.14.2.7 — Desarrollo externalizado
Qué significa para CI/CD: Cuando el desarrollo está externalizado, la organización debe supervisar y monitorizar la actividad. En CI/CD, esto significa que los desarrolladores externos deben utilizar el pipeline de la organización (no el suyo propio), y sus contribuciones están sujetas a los mismos controles automatizados y procesos de aprobación.
Evidencia que demuestra cumplimiento:
- Requisitos contractuales para que los desarrolladores externos utilicen el pipeline CI/CD de la organización
- Registros de control de acceso que muestran que los desarrolladores externos tienen acceso apropiado (limitado) al pipeline
- Evidencia de requisitos de revisión de código para contribuciones externas
- Registros de monitorización de la actividad del pipeline de los desarrolladores externos
Cómo se ve el incumplimiento: Los desarrolladores externos utilizan sus propios procesos de compilación y despliegue. Las contribuciones externas omiten los controles estándar del pipeline o los requisitos de revisión de código.
A.14.2.8 — Pruebas de seguridad del sistema
Qué significa para CI/CD: Las pruebas de seguridad deben realizarse durante el desarrollo. Los pipelines CI/CD deben integrar pruebas de seguridad automatizadas — análisis estático, análisis de vulnerabilidades de dependencias, pruebas dinámicas — como etapas obligatorias del pipeline que no pueden omitirse.
Evidencia que demuestra cumplimiento:
- Configuraciones del pipeline que muestran etapas de pruebas de seguridad obligatorias
- Resultados de pruebas de seguridad conservados con cada ejecución del pipeline
- Evidencia de que los fallos en las pruebas de seguridad bloquean el avance hacia producción
- Registros de actualizaciones de herramientas de pruebas de seguridad y mantenimiento de reglas
Cómo se ve el incumplimiento: Las pruebas de seguridad existen pero son opcionales o solo orientativas. Los resultados de las pruebas no se conservan. Los fallos en las pruebas de seguridad pueden anularse sin justificación documentada.
A.14.2.9 — Pruebas de aceptación del sistema
Qué significa para CI/CD: Deben establecerse programas y criterios de pruebas de aceptación. El pipeline CI/CD debe aplicar los criterios de aceptación antes del despliegue en producción — incluidas puertas de aceptación funcionales, de rendimiento y de seguridad.
Evidencia que demuestra cumplimiento:
- Criterios de aceptación definidos para cada etapa de despliegue
- Configuraciones del pipeline que aplican las puertas de aceptación
- Registros de resultados de pruebas de aceptación para cada despliegue en producción
- Evidencia de que los criterios de aceptación son revisados y aprobados por las partes interesadas apropiadas
Cómo se ve el incumplimiento: Sin criterios de aceptación formales definidos. El pipeline permite el despliegue sin verificación de aceptación. Las pruebas de aceptación son manuales y se aplican de forma inconsistente.
Tabla de mapeo de subcontroles de A.14
| Subcontrol A.14 | Implementación CI/CD | Evidencia requerida | Señales de alerta |
|---|---|---|---|
| A.14.1.1 Requisitos de seguridad | Requisitos de seguridad rastreados hasta los casos de prueba del pipeline | Especificaciones de requisitos; registros de trazabilidad; mapeos de casos de prueba | Sin requisitos de seguridad definidos antes del inicio del desarrollo |
| A.14.1.2 Servicios en redes públicas | Comprobaciones de configuración de seguridad previas al despliegue | Resultados de verificación automatizada de TLS y cabeceras de seguridad | Despliegues públicos sin verificación de configuración de seguridad |
| A.14.1.3 Protección de transacciones | Pruebas de integridad de transacciones en el pipeline | Resultados de pruebas de integración que cubren escenarios de transacciones | Sistemas de transacciones desplegados sin pruebas de integridad |
| A.14.2.1 Política de desarrollo seguro | Política que rige las prácticas de seguridad CI/CD | Política aprobada; registros de revisión; evidencia de comunicación | La política no menciona CI/CD; sin revisión desde la adopción del pipeline |
| A.14.2.2 Control de cambios | Pipeline como mecanismo de aplicación del control de cambios | Configuraciones de puertas de aprobación; rastros de auditoría de cambios; registros de cambios de emergencia | Posibilidad de envíos directos a producción; sin puertas de aprobación |
| A.14.2.3 Revisión tras cambios de plataforma | Pruebas de regresión activadas por cambios en dependencias de plataforma | Registros de cambios de plataforma; resultados de pruebas de regresión | Actualizaciones de plataforma sin pruebas de regresión de aplicaciones |
| A.14.2.4 Restricciones sobre cambios de paquetes | Verificación de integridad para paquetes de terceros | Aprobaciones de modificación de paquetes; resultados de comprobaciones de integridad | Paquetes bifurcados sin aprobación; sin comprobaciones de integridad |
| A.14.2.5 Principios de ingeniería segura | Comprobaciones de arquitectura y patrones de seguridad aplicadas por el pipeline | Principios documentados; resultados de verificación automatizada | Principios solo en papel; sin aplicación por el pipeline |
| A.14.2.6 Entorno de desarrollo seguro | Entornos de compilación reforzados y aislados | Registros de hardening; evidencia de aislamiento; registros de acceso | Infraestructura compartida; agentes de compilación persistentes; sin hardening |
| A.14.2.7 Desarrollo externalizado | Los desarrolladores externos utilizan el pipeline de la organización | Contratos; registros de acceso; registros de monitorización; registros de revisión de código | Desarrolladores externos que omiten el pipeline; sin monitorización |
| A.14.2.8 Pruebas de seguridad | Etapas obligatorias de pruebas de seguridad automatizadas | Configuraciones del pipeline; resultados de pruebas; registros de mantenimiento de herramientas | Pruebas de seguridad opcionales; resultados no conservados; omisiones fáciles |
| A.14.2.9 Pruebas de aceptación | Puertas de aceptación aplicadas por el pipeline | Criterios de aceptación; configuraciones de puertas; resultados de pruebas por despliegue | Sin criterios de aceptación; pruebas solo manuales; aplicación inconsistente |
Cómo A.14 se conecta con otros controles del Anexo A
A.14 no opera de forma aislada. La gobernanza eficaz de CI/CD requiere comprender cómo A.14 se intersecta con otros dominios de control:
- A.9 (Control de acceso) — El control de cambios A.14.2.2 depende de los controles de acceso de A.9 para asegurar que solo el personal autorizado pueda aprobar y activar despliegues. Los fallos en el control de acceso socavan todo el marco de control de cambios.
- A.12 (Seguridad de las operaciones) — Los requisitos de entorno de desarrollo seguro de A.14.2.6 se alinean con los procedimientos operativos de A.12. Los requisitos de registro bajo A.12 proporcionan el rastro de auditoría necesario para verificar el cumplimiento del control de cambios de A.14.
- A.15 (Relaciones con proveedores) — Las restricciones de paquetes de A.14.2.4 y el desarrollo externalizado de A.14.2.7 se conectan directamente con la gestión de proveedores de A.15. Los componentes de terceros en el pipeline son tanto una preocupación de desarrollo (A.14) como una preocupación de riesgo de proveedores (A.15).
Lista de verificación para auditores para A.14
Al auditar el cumplimiento de A.14 en entornos CI/CD, verifique lo siguiente:
- ☐ La política de desarrollo seguro aborda explícitamente los pipelines CI/CD y los procesos automatizados
- ☐ Los requisitos de seguridad se definen antes del desarrollo y son rastreables hasta la verificación del pipeline
- ☐ Los procedimientos de control de cambios referencian el pipeline CI/CD como mecanismo de aplicación
- ☐ El pipeline incluye puertas de aprobación obligatorias antes del despliegue en producción
- ☐ Todas las ejecuciones del pipeline producen rastros de auditoría inmutables (quién, qué, cuándo, resultado)
- ☐ Las etapas de pruebas de seguridad son obligatorias y no pueden omitirse sin justificación documentada
- ☐ Los fallos en las pruebas de seguridad bloquean el avance del despliegue
- ☐ Los criterios de aceptación están definidos, aprobados y aplicados por el pipeline
- ☐ Los entornos de compilación están aislados, reforzados y con control de acceso
- ☐ El desarrollo externalizado está sujeto a los mismos controles del pipeline que el desarrollo interno
- ☐ Las modificaciones de paquetes de terceros están formalmente aprobadas y verificadas en cuanto a integridad
- ☐ Los cambios de plataforma activan pruebas de regresión
- ☐ Existen procedimientos de cambios de emergencia con requisitos de revisión retrospectiva
- ☐ La evidencia se conserva según la política de retención de la organización
Lectura adicional
Relacionado para auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- Continuous Compliance via CI/CD
- Audit Readiness Checklist
- Core CI/CD Security Controls
¿Nuevo en la auditoría CI/CD? Comience con nuestra Guía para Auditores.
