Introducción: Patrones desde el Terreno de la Auditoría
Tras revisar implementaciones de CI/CD en entornos regulados — servicios financieros, sanidad, infraestructuras críticas y empresas tecnológicas sujetas a SOC 2, ISO 27001, DORA, NIS2 y PCI DSS — ciertos hallazgos de auditoría aparecen con notable consistencia. No son casos excepcionales. Son fallos sistémicos de gobernanza que los auditores encuentran repetidamente, en organizaciones de todos los tamaños y niveles de madurez.
Este artículo presenta los diez hallazgos de auditoría más frecuentes en pipelines CI/CD, redactado para auditores, oficiales de cumplimiento y gestores de riesgos. Para cada hallazgo, describimos qué es, por qué importa desde una perspectiva regulatoria, cómo suele aparecer durante una auditoría y qué aspecto debería tener la remediación. Los equipos de cumplimiento deben usar esto como lista de verificación de autoevaluación previa a la auditoría para identificar y abordar debilidades antes de que lo haga un auditor externo.
Hallazgo 1: Cuentas de Servicio Compartidas con Privilegios de Administrador
Descripción
Múltiples personas o equipos utilizan cuentas de servicio compartidas con privilegios elevados (a menudo administrativos) para ejecutar operaciones de pipeline. Las acciones individuales no pueden atribuirse a personas específicas.
Por Qué Importa
La responsabilidad individual es un principio fundamental del control de acceso. Cuando las acciones no pueden rastrearse hasta una persona específica, la investigación de incidentes se vuelve imposible y se elimina la disuasión contra el mal uso. Los controles de segregación de funciones carecen de sentido si múltiples personas operan bajo la misma identidad.
Referencias Regulatorias
- DORA: El artículo 9 exige controles de identificación y autenticación para sistemas ICT
- ISO 27001: Anexo A.9.2 — Gestión de acceso de usuarios, incluida la identificación única de usuarios
- SOC 2: CC6.1 — Seguridad de acceso lógico; responsabilidad individual
- PCI DSS: Requisito 8 — Asignar ID único a cada persona con acceso informático
Evidencia Típica del Hallazgo
Los registros del pipeline muestran la misma cuenta de servicio ejecutando compilaciones, despliegues y acciones administrativas en múltiples equipos. Las revisiones de acceso revelan credenciales de cuenta de servicio compartidas entre varios empleados. No existe ningún mapeo entre las acciones de la cuenta de servicio y los operadores individuales.
Expectativa de Remediación
Implementar cuentas de usuario individuales para todas las interacciones con el pipeline. Donde las cuentas de servicio sean técnicamente necesarias, implementar controles que vinculen las acciones de la cuenta de servicio con el individuo que las inició (por ejemplo, mediante disparadores de pipeline vinculados a usuarios autenticados). Realizar una revisión de privilegios y aplicar principios de mínimo privilegio.
Severidad: Alta
Hallazgo 2: Puertas de Aprobación que Pueden Eludirse o Autoaprobarse
Descripción
Existen puertas de aprobación en el pipeline, pero pueden ser eludidas por usuarios con privilegios suficientes, o el mismo individuo que inicia un cambio puede aprobar su propio despliegue a producción. La segregación de funciones no se aplica.
Por Qué Importa
Las puertas de aprobación son el mecanismo principal para aplicar la segregación de funciones en entornos CI/CD. Si pueden eludirse o autoaprobarse, el control es ineficaz independientemente de si existe en papel. Esto representa un fallo de diseño, no simplemente una debilidad operativa.
Referencias Regulatorias
- DORA: Artículo 9 — Procedimientos de gestión de cambios ICT con aprobación adecuada
- NIS2: Las medidas de gestión de riesgos deben incluir controles de autorización adecuados
- ISO 27001: Anexo A.12.1.2 — Gestión de cambios; Anexo A.6.1.2 — Segregación de funciones
- SOC 2: CC8.1 — Controles de gestión de cambios
Evidencia Típica del Hallazgo
La configuración del pipeline muestra que los usuarios con roles de «administrador» o «mantenedor» pueden omitir los requisitos de aprobación. Los registros de despliegue muestran casos en los que el mismo individuo confirmó el código y aprobó el despliegue. Existen procedimientos de omisión de emergencia pero carecen de controles de gobernanza o revisión posterior.
Expectativa de Remediación
Aplicar puertas de aprobación que no puedan eludirse excepto mediante un proceso de cambio de emergencia gestionado. Implementar reglas de segregación de funciones que impidan la autoaprobación. Registrar y revisar todos los casos en que no se siguen los procesos de aprobación estándar.
Severidad: Alta
Hallazgo 3: Sin Retención de Registros del Pipeline o Registros en Sistemas Mutables
Descripción
Los registros de ejecución del pipeline no se conservan más allá de una ventana operativa corta (por ejemplo, 30 días), o se almacenan en sistemas donde el personal operativo puede modificarlos o eliminarlos.
Por Qué Importa
Los registros del pipeline son evidencia primaria para la gestión de cambios, la autorización de despliegues y los controles de pruebas de seguridad. Sin una retención adecuada, las organizaciones no pueden demostrar a los auditores que los controles estaban operando durante períodos anteriores. Los registros mutables socavan la integridad de la evidencia: un auditor no puede confiar en evidencia que podría haber sido alterada.
Referencias Regulatorias
- DORA: Artículo 12 — Requisitos de registro para operaciones ICT; expectativa de retención de 5 años
- PCI DSS: Requisito 10 — Rastrear y monitorizar todos los accesos; retención mínima de 1 año
- ISO 27001: Anexo A.12.4 — Registro y monitorización
- SOC 2: CC7.2 — Monitorización del sistema
Evidencia Típica del Hallazgo
Las solicitudes de registros del pipeline de hace seis meses no arrojan resultados. El almacenamiento de registros está en el mismo sistema donde los operadores tienen acceso de escritura. No existe ningún mecanismo de verificación de integridad de registros (sin sumas de verificación, sin almacenamiento inmutable).
Expectativa de Remediación
Implementar políticas de retención de registros alineadas con los requisitos regulatorios. Almacenar registros en almacenamiento inmutable o de escritura única. Implementar mecanismos de verificación de integridad de registros. Garantizar que la retención de registros cubra el período de auditoría completo más los requisitos regulatorios de retención.
Severidad: Alta
Hallazgo 4: Secretos Codificados en Código o Configuraciones de Pipeline
Descripción
Las credenciales, claves API, certificados u otros secretos están integrados directamente en repositorios de código fuente o archivos de configuración del pipeline, en lugar de gestionarse mediante una capacidad dedicada de gestión de secretos.
Por Qué Importa
Los secretos codificados son accesibles para cualquier persona con acceso al repositorio, no pueden rotarse sin cambios de código y persisten en el historial de control de versiones incluso después de su eliminación. Esto crea una exposición de credenciales no controlada y hace que la gestión de credenciales — rotación, revocación, registro de acceso — sea prácticamente imposible.
Referencias Regulatorias
- DORA: Artículo 9 — Protección de activos y datos ICT
- ISO 27001: Anexo A.9.4.3 — Gestión de contraseñas; Anexo A.10 — Controles criptográficos
- PCI DSS: Requisito 2 — No usar valores predeterminados del proveedor; Requisito 8 — Gestión de credenciales
- SOC 2: CC6.1 — Controles de acceso lógico
Evidencia Típica del Hallazgo
Los análisis del repositorio revelan secretos en el código o en los archivos de configuración. El historial de control de versiones contiene credenciales aunque se hayan eliminado de las versiones actuales. No se utiliza ninguna solución de gestión de secretos, o se utiliza pero no se ha adoptado de forma universal.
Expectativa de Remediación
Eliminar todos los secretos codificados de repositorios y configuraciones de pipeline. Implementar una capacidad centralizada de gestión de secretos. Rotar todas las credenciales expuestas. Implementar la detección automática de secretos en los pipelines para prevenir ocurrencias futuras.
Severidad: Crítica
Hallazgo 5: Resultados de Análisis de Seguridad Ignorados — Sin Puertas de Política que Bloqueen el Despliegue
Descripción
Las herramientas de análisis de seguridad (SAST, DAST, SCA, análisis de contenedores) están integradas en los pipelines, pero sus resultados no condicionan los despliegues. Se identifican vulnerabilidades altas o críticas, pero el código avanza a producción independientemente.
Por Qué Importa
Ejecutar análisis de seguridad sin actuar sobre los resultados es teatro de seguridad. Crea la apariencia de pruebas de seguridad sin proporcionar la sustancia. Desde una perspectiva de gobernanza, la organización tiene conciencia de las vulnerabilidades pero elige no abordarlas — lo que puede ser peor que no analizar en absoluto, ya que demuestra la aceptación consciente de un riesgo no gestionado.
Referencias Regulatorias
- DORA: Artículo 8 — Identificación, protección y prevención de riesgos ICT
- NIS2: Artículo 21 — Gestión y divulgación de vulnerabilidades
- ISO 27001: Anexo A.12.6 — Gestión técnica de vulnerabilidades
- PCI DSS: Requisito 6 — Desarrollar y mantener sistemas seguros
Evidencia Típica del Hallazgo
Los informes de análisis muestran hallazgos críticos durante períodos prolongados sin remediación. Las configuraciones del pipeline muestran que los análisis se ejecutan, pero los resultados no afectan al progreso del pipeline. No existen umbrales definidos para qué resultados de análisis deben bloquear el despliegue.
Expectativa de Remediación
Definir umbrales de seguridad claros que condicionen el progreso del pipeline. Implementar puertas de política que bloqueen el despliegue cuando los hallazgos superen los umbrales de severidad definidos. Establecer un proceso de excepción gestionado para los hallazgos que se acepten, con aceptación del riesgo documentada por la autoridad correspondiente.
Severidad: Alta
Hallazgo 6: Sin Generación de SBOM ni Inventario de Componentes de Terceros
Descripción
La organización no genera Software Bills of Materials (SBOMs) ni mantiene un inventario completo de componentes de terceros y de código abierto utilizados en sus aplicaciones.
Por Qué Importa
Sin un SBOM, la organización no puede identificar qué aplicaciones se ven afectadas cuando se divulga una vulnerabilidad en un componente de terceros (como ocurrió con Log4Shell, Spring4Shell e incidentes similares de cadena de suministro). La respuesta a incidentes se convierte en una conjetura, y los requisitos regulatorios para la gestión de riesgos de la cadena de suministro no pueden cumplirse.
Referencias Regulatorias
- DORA: Artículo 28 — Gestión de riesgos de terceros ICT
- NIS2: Artículo 21 — Seguridad de la cadena de suministro
- ISO 27001: Anexo A.15 — Relaciones con proveedores
- SOC 2: CC9.2 — Gestión de riesgos de proveedores terceros
Evidencia Típica del Hallazgo
No existen archivos SBOM para las aplicaciones desplegadas. Cuando se pregunta «¿cuáles de sus aplicaciones utilizan el componente X?», la organización no puede responder con prontitud. No se integra ningún análisis automatizado de dependencias en los pipelines.
Expectativa de Remediación
Implementar la generación automática de SBOM como parte del pipeline CI/CD. Utilizar formatos estándar (CycloneDX o SPDX). Mantener un repositorio central de SBOMs para todas las aplicaciones desplegadas. Implementar procesos para cruzar nuevas divulgaciones de vulnerabilidades con el inventario de SBOM.
Severidad: Media-Alta
Hallazgo 7: Acceso Directo a Producción Sin Gestión de Cambios
Descripción
Los desarrolladores u operadores pueden acceder directamente a los entornos de producción y realizar cambios fuera del pipeline CI/CD, eludiendo todos los controles del pipeline, incluidas las puertas de aprobación, los análisis de seguridad y el registro de auditoría.
Por Qué Importa
Si se pueden realizar cambios en producción fuera del pipeline gestionado, todo el marco de control queda socavado. Cada control integrado en el pipeline — aprobaciones, análisis, registro, segregación de funciones — puede eludirse simplemente realizando cambios directamente. El pipeline se convierte en algo opcional, no obligatorio.
Referencias Regulatorias
- DORA: Artículo 9 — Controles de gestión de cambios ICT y despliegue
- ISO 27001: Anexo A.12.1.2 — Gestión de cambios; Anexo A.14.2.2 — Control de cambios del sistema
- SOC 2: CC8.1 — Gestión de cambios
- PCI DSS: Requisito 6.5 — Procedimientos de control de cambios
Evidencia Típica del Hallazgo
Los registros de acceso a producción muestran inicios de sesión directos por parte del personal de desarrollo u operaciones. Los cambios en producción no se corresponden con los registros de despliegue del pipeline. Las configuraciones del entorno de producción difieren de lo que el pipeline desplegó por última vez.
Expectativa de Remediación
Restringir el acceso a producción a cuentas de servicio autorizadas controladas por el pipeline. Implementar acceso justo a tiempo para escenarios de emergencia con registro completo y revisión posterior al acceso. Monitorizar y alertar sobre cualquier cambio directo en producción fuera del pipeline.
Severidad: Crítica
Hallazgo 8: Supresiones de Vulnerabilidades Sin Documentación de Aceptación del Riesgo
Descripción
Los hallazgos de análisis de seguridad se suprimen, exoneran o marcan como «aceptados» sin documentación formal de aceptación del riesgo. No existe ningún registro de quién aceptó el riesgo, cuál fue la justificación o cuándo caduca la aceptación.
Por Qué Importa
La aceptación del riesgo es una opción legítima de tratamiento del riesgo, pero solo cuando es una decisión consciente, documentada y autorizada. Las supresiones no gestionadas no son aceptación del riesgo; son ignorancia del riesgo. Crean bolsas ocultas de riesgo no gestionado que los auditores identificarán y señalarán.
Referencias Regulatorias
- DORA: Artículo 8 — Identificación y tratamiento de riesgos ICT
- ISO 27001: Cláusula 6.1.3 — Tratamiento del riesgo; aceptación documentada del riesgo por los propietarios del riesgo
- SOC 2: CC3.2 — Evaluación y gestión de riesgos
- NIS2: Artículo 21 — Medidas de gestión de riesgos
Evidencia Típica del Hallazgo
Las configuraciones de análisis de seguridad contienen listas de supresión sin documentación asociada. Los hallazgos suprimidos incluyen vulnerabilidades de severidad crítica o alta. No existe ningún flujo de trabajo de aprobación para agregar hallazgos a las listas de supresión. Las supresiones no tienen fecha de vencimiento ni ciclo de revisión.
Expectativa de Remediación
Implementar un proceso formal de aceptación del riesgo que requiera justificación documentada, aprobación de la autoridad correspondiente, fechas de vencimiento definidas y revisión periódica. Revisar retrospectivamente todas las supresiones existentes y documentar la aceptación del riesgo o eliminar la supresión.
Severidad: Alta
Hallazgo 9: Sin Segregación entre Entornos de Desarrollo, Staging y Producción
Descripción
Los entornos de desarrollo, staging (o pruebas) y producción no están adecuadamente segregados. Pueden compartir infraestructura, credenciales, datos o segmentos de red, o el personal de desarrollo puede tener un acceso equivalente en todos los entornos.
Por Qué Importa
La segregación de entornos es un control fundamental que protege los sistemas de producción de cambios no autorizados, evita que las actividades de desarrollo afecten a los servicios en vivo y garantiza que las pruebas se realicen en condiciones que se aproximen —pero no comprometan— a la producción. Sin ella, el riesgo de cambios no controlados, filtración de datos y contaminación del entorno aumenta sustancialmente.
Referencias Regulatorias
- DORA: Artículo 9 — Separación de entornos ICT
- ISO 27001: Anexo A.12.1.4 — Separación de entornos de desarrollo, pruebas y operaciones
- PCI DSS: Requisito 6.5 — Separación de entornos de desarrollo/pruebas y producción
- SOC 2: CC6.1 — Controles de acceso lógico entre entornos
Evidencia Típica del Hallazgo
La revisión de infraestructura revela recursos compartidos entre entornos. Las mismas credenciales funcionan tanto en desarrollo como en producción. El personal de desarrollo tiene acceso administrativo a los entornos de producción. Los datos de producción se utilizan en desarrollo o pruebas sin anonimización.
Expectativa de Remediación
Implementar límites claros de entorno con infraestructura, credenciales y controles de acceso separados. Restringir el acceso a producción al personal operativo autorizado y a las cuentas de servicio del pipeline. Implementar anonimización de datos o datos sintéticos para entornos que no sean de producción.
Severidad: Alta
Hallazgo 10: Aplicación Inconsistente de Controles entre Equipos o Pipelines
Descripción
Los controles se aplican de forma inconsistente en toda la organización. Algunos equipos tienen pipelines bien gestionados con puertas de aprobación, análisis de seguridad y retención de evidencia, mientras que otros equipos operan con controles mínimos o inexistentes.
Por Qué Importa
El cumplimiento es una obligación organizacional, no una opción a nivel de equipo. La aplicación inconsistente de controles significa que la postura de cumplimiento de la organización es tan sólida como su pipeline más débil. También sugiere una brecha de gobernanza: la ausencia de un estándar empresarial para los controles de pipeline y la falta de un mecanismo para hacer cumplir ese estándar.
Referencias Regulatorias
- DORA: El marco de gestión de riesgos ICT debe cubrir toda la organización
- NIS2: Las medidas de gestión de riesgos deben ser completas y proporcionadas
- ISO 27001: El alcance del SGSI debe estar definido y los controles aplicados de manera consistente dentro del alcance
- SOC 2: Los controles deben aplicarse en todos los sistemas y procesos dentro del alcance
Evidencia Típica del Hallazgo
La comparación de configuraciones de pipeline entre equipos revela variaciones significativas en la implementación de controles. Algunos pipelines carecen de puertas de aprobación, análisis de seguridad o retención de evidencia que otros sí tienen. No existe ningún estándar de gobernanza de pipeline a nivel organizacional, o existe pero no se aplica.
Expectativa de Remediación
Definir un estándar de gobernanza de pipeline a nivel organizacional que especifique los controles mínimos requeridos. Implementar mecanismos para hacer cumplir el estándar (plantillas de pipeline, política como código, análisis de cumplimiento de configuraciones de pipeline). Realizar una evaluación de brechas en todos los pipelines y remediar las no conformidades.
Severidad: Media-Alta
Resumen: Hallazgos, Impacto Regulatorio y Prioridad de Remediación
| Hallazgo | DORA | NIS2 | ISO 27001 | SOC 2 | PCI DSS | Severidad | Prioridad de Remediación |
|---|---|---|---|---|---|---|---|
| 1. Cuentas de servicio compartidas | Sí | Sí | Sí | Sí | Sí | Alta | Inmediata |
| 2. Puertas de aprobación eludibles | Sí | Sí | Sí | Sí | Sí | Alta | Inmediata |
| 3. Sin retención de registros / registros mutables | Sí | Sí | Sí | Sí | Sí | Alta | Inmediata |
| 4. Secretos codificados | Sí | Sí | Sí | Sí | Sí | Crítica | Inmediata |
| 5. Análisis de seguridad sin puertas | Sí | Sí | Sí | Sí | Sí | Alta | Alta |
| 6. Sin SBOM / inventario de componentes | Sí | Sí | Sí | Sí | Parcial | Media-Alta | Alta |
| 7. Acceso directo a producción | Sí | Sí | Sí | Sí | Sí | Crítica | Inmediata |
| 8. Supresión de vulnerabilidades no gestionada | Sí | Sí | Sí | Sí | Sí | Alta | Alta |
| 9. Sin segregación de entornos | Sí | Sí | Sí | Sí | Sí | Alta | Alta |
| 10. Controles inconsistentes entre equipos | Sí | Sí | Sí | Sí | Sí | Media-Alta | Media |
Cómo Suelen Aparecer Estos Hallazgos Durante las Auditorías
Entender cómo los auditores descubren estos hallazgos ayuda a los equipos de cumplimiento a prepararse de manera más efectiva:
- Preguntas en entrevistas: «Explíqueme cómo llega un cambio de código a producción.» «¿Quién puede aprobar un despliegue?» «¿Cómo se gestionan los secretos?» Estas preguntas abiertas suelen revelar debilidades de control a través de las respuestas dadas, o la incapacidad de responder de manera consistente.
- Solicitudes de evidencia: «Muéstreme los registros del pipeline de hace tres meses.» «Proporcione el registro de aprobación para este despliegue específico.» «Muéstreme su SBOM para esta aplicación.» La incapacidad de producir evidencia con prontitud es en sí misma un hallazgo.
- Revisiones de configuración: Los auditores solicitan cada vez más acceso a las configuraciones del pipeline, los ajustes de control de acceso y las configuraciones de las herramientas de seguridad. Estas revisiones revelan si los controles existen en la práctica, no solo en la política.
- Referencias cruzadas: Comparar registros de despliegue con registros de aprobación, comparar configuraciones de producción con los resultados del pipeline y comparar resultados de análisis de seguridad con decisiones de despliegue. Las inconsistencias entre estas fuentes revelan fallos de control.
Reconocimiento de Patrones: Lo que Revelan las Combinaciones de Hallazgos
Los hallazgos individuales son preocupantes, pero las combinaciones de hallazgos revelan problemas de gobernanza más profundos. Cuando el Hallazgo 1 (cuentas de servicio compartidas) y el Hallazgo 2 (puertas de aprobación eludibles) aparecen juntos, indican una ausencia fundamental de gobernanza de acceso, no solo brechas de control aisladas. Del mismo modo, si el Hallazgo 5 (análisis sin puertas) y el Hallazgo 8 (supresiones no gestionadas) coexisten, el programa de pruebas de seguridad de la organización es efectivamente decorativo.
Los auditores deben buscar estos patrones, ya que indican si los hallazgos son debilidades aisladas que pueden remediarse individualmente o síntomas de una brecha de madurez de gobernanza más amplia que requiere una respuesta más integral.
Recomendaciones para los Equipos de Cumplimiento
Utilice esta lista como lista de verificación de autoevaluación previa a la auditoría. Para cada hallazgo:
- Determine si el hallazgo existe en su entorno.
- Si existe, evalúe su alcance: ¿está aislado a equipos o pipelines específicos, o es generalizado?
- Documente el estado actual de manera honesta — intentar ocultar problemas conocidos a los auditores invariablemente empeora las cosas.
- Desarrolle un plan de remediación con plazos realistas y responsabilidad clara.
- Si la remediación no puede completarse antes de la auditoría, prepare un plan de remediación documentado para presentar a los auditores, demostrando conciencia y compromiso con la resolución del problema.
La identificación y remediación proactiva de estos hallazgos comunes demuestra madurez de gobernanza y reduce significativamente el riesgo de resultados adversos de auditoría.
Recursos Relacionados
Para obtener más orientación sobre la preparación de auditorías CI/CD e identificación de señales de alerta, consulte:
- Señales de Alerta en Auditorías CI/CD: Lo que Genera Preocupación Inmediata en los Auditores
- Antes de que Llegue el Auditor: Lista de Verificación de Preparación para Auditorías CI/CD
- Marco de Gobernanza de Auditoría
Relacionado para Auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- Cómo los Auditores Revisan CI/CD
- Manual del Día de Auditoría
- Lista de Verificación de Preparación para Auditorías
¿Nuevo en la auditoría de CI/CD? Empiece con nuestra Guía para Auditores.
