Tras revisar implementaciones de CI\/CD en entornos regulados \u2014 servicios financieros, sanidad, infraestructuras cr\u00edticas y empresas tecnol\u00f3gicas sujetas a SOC 2, ISO 27001, DORA, NIS2 y PCI DSS \u2014 ciertos hallazgos de auditor\u00eda aparecen con notable consistencia. No son casos excepcionales. Son fallos sist\u00e9micos de gobernanza que los auditores encuentran repetidamente, en organizaciones de todos los tama\u00f1os y niveles de madurez.<\/p>\n
Este art\u00edculo presenta los diez hallazgos de auditor\u00eda m\u00e1s frecuentes en pipelines CI\/CD, redactado para auditores, oficiales de cumplimiento y gestores de riesgos. Para cada hallazgo, describimos qu\u00e9 es, por qu\u00e9 importa desde una perspectiva regulatoria, c\u00f3mo suele aparecer durante una auditor\u00eda y qu\u00e9 aspecto deber\u00eda tener la remediaci\u00f3n. Los equipos de cumplimiento deben usar esto como lista de verificaci\u00f3n de autoevaluaci\u00f3n previa a la auditor\u00eda para identificar y abordar debilidades antes de que lo haga un auditor externo.<\/p>\n
M\u00faltiples 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\u00edficas.<\/p>\n
La responsabilidad individual es un principio fundamental del control de acceso. Cuando las acciones no pueden rastrearse hasta una persona espec\u00edfica, la investigaci\u00f3n de incidentes se vuelve imposible y se elimina la disuasi\u00f3n contra el mal uso. Los controles de segregaci\u00f3n de funciones carecen de sentido si m\u00faltiples personas operan bajo la misma identidad.<\/p>\n
Los registros del pipeline muestran la misma cuenta de servicio ejecutando compilaciones, despliegues y acciones administrativas en m\u00faltiples equipos. Las revisiones de acceso revelan credenciales de cuenta de servicio compartidas entre varios empleados. No existe ning\u00fan mapeo entre las acciones de la cuenta de servicio y los operadores individuales.<\/p>\n
Implementar cuentas de usuario individuales para todas las interacciones con el pipeline. Donde las cuentas de servicio sean t\u00e9cnicamente necesarias, implementar controles que vinculen las acciones de la cuenta de servicio con el individuo que las inici\u00f3 (por ejemplo, mediante disparadores de pipeline vinculados a usuarios autenticados). Realizar una revisi\u00f3n de privilegios y aplicar principios de m\u00ednimo privilegio.<\/p>\n
Existen puertas de aprobaci\u00f3n 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\u00f3n. La segregaci\u00f3n de funciones no se aplica.<\/p>\n
Las puertas de aprobaci\u00f3n son el mecanismo principal para aplicar la segregaci\u00f3n 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\u00f1o, no simplemente una debilidad operativa.<\/p>\n
La configuraci\u00f3n del pipeline muestra que los usuarios con roles de \u00abadministrador\u00bb o \u00abmantenedor\u00bb pueden omitir los requisitos de aprobaci\u00f3n. Los registros de despliegue muestran casos en los que el mismo individuo confirm\u00f3 el c\u00f3digo y aprob\u00f3 el despliegue. Existen procedimientos de omisi\u00f3n de emergencia pero carecen de controles de gobernanza o revisi\u00f3n posterior.<\/p>\n
Aplicar puertas de aprobaci\u00f3n que no puedan eludirse excepto mediante un proceso de cambio de emergencia gestionado. Implementar reglas de segregaci\u00f3n de funciones que impidan la autoaprobaci\u00f3n. Registrar y revisar todos los casos en que no se siguen los procesos de aprobaci\u00f3n est\u00e1ndar.<\/p>\n
Los registros de ejecuci\u00f3n del pipeline no se conservan m\u00e1s all\u00e1 de una ventana operativa corta (por ejemplo, 30 d\u00edas), o se almacenan en sistemas donde el personal operativo puede modificarlos o eliminarlos.<\/p>\n
Los registros del pipeline son evidencia primaria para la gesti\u00f3n de cambios, la autorizaci\u00f3n de despliegues y los controles de pruebas de seguridad. Sin una retenci\u00f3n adecuada, las organizaciones no pueden demostrar a los auditores que los controles estaban operando durante per\u00edodos anteriores. Los registros mutables socavan la integridad de la evidencia: un auditor no puede confiar en evidencia que podr\u00eda haber sido alterada.<\/p>\n
Las solicitudes de registros del pipeline de hace seis meses no arrojan resultados. El almacenamiento de registros est\u00e1 en el mismo sistema donde los operadores tienen acceso de escritura. No existe ning\u00fan mecanismo de verificaci\u00f3n de integridad de registros (sin sumas de verificaci\u00f3n, sin almacenamiento inmutable).<\/p>\n
Implementar pol\u00edticas de retenci\u00f3n de registros alineadas con los requisitos regulatorios. Almacenar registros en almacenamiento inmutable o de escritura \u00fanica. Implementar mecanismos de verificaci\u00f3n de integridad de registros. Garantizar que la retenci\u00f3n de registros cubra el per\u00edodo de auditor\u00eda completo m\u00e1s los requisitos regulatorios de retenci\u00f3n.<\/p>\n
Las credenciales, claves API, certificados u otros secretos est\u00e1n integrados directamente en repositorios de c\u00f3digo fuente o archivos de configuraci\u00f3n del pipeline, en lugar de gestionarse mediante una capacidad dedicada de gesti\u00f3n de secretos.<\/p>\n
Los secretos codificados son accesibles para cualquier persona con acceso al repositorio, no pueden rotarse sin cambios de c\u00f3digo y persisten en el historial de control de versiones incluso despu\u00e9s de su eliminaci\u00f3n. Esto crea una exposici\u00f3n de credenciales no controlada y hace que la gesti\u00f3n de credenciales \u2014 rotaci\u00f3n, revocaci\u00f3n, registro de acceso \u2014 sea pr\u00e1cticamente imposible.<\/p>\n
Los an\u00e1lisis del repositorio revelan secretos en el c\u00f3digo o en los archivos de configuraci\u00f3n. El historial de control de versiones contiene credenciales aunque se hayan eliminado de las versiones actuales. No se utiliza ninguna soluci\u00f3n de gesti\u00f3n de secretos, o se utiliza pero no se ha adoptado de forma universal.<\/p>\n
Eliminar todos los secretos codificados de repositorios y configuraciones de pipeline. Implementar una capacidad centralizada de gesti\u00f3n de secretos. Rotar todas las credenciales expuestas. Implementar la detecci\u00f3n autom\u00e1tica de secretos en los pipelines para prevenir ocurrencias futuras.<\/p>\n
Las herramientas de an\u00e1lisis de seguridad (SAST, DAST, SCA, an\u00e1lisis de contenedores) est\u00e1n integradas en los pipelines, pero sus resultados no condicionan los despliegues. Se identifican vulnerabilidades altas o cr\u00edticas, pero el c\u00f3digo avanza a producci\u00f3n independientemente.<\/p>\n
Ejecutar an\u00e1lisis 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\u00f3n tiene conciencia<\/em> de las vulnerabilidades pero elige no abordarlas \u2014 lo que puede ser peor que no analizar en absoluto, ya que demuestra la aceptaci\u00f3n consciente de un riesgo no gestionado.<\/p>\n Los informes de an\u00e1lisis muestran hallazgos cr\u00edticos durante per\u00edodos prolongados sin remediaci\u00f3n. Las configuraciones del pipeline muestran que los an\u00e1lisis se ejecutan, pero los resultados no afectan al progreso del pipeline. No existen umbrales definidos para qu\u00e9 resultados de an\u00e1lisis deben bloquear el despliegue.<\/p>\n Definir umbrales de seguridad claros que condicionen el progreso del pipeline. Implementar puertas de pol\u00edtica que bloqueen el despliegue cuando los hallazgos superen los umbrales de severidad definidos. Establecer un proceso de excepci\u00f3n gestionado para los hallazgos que se acepten, con aceptaci\u00f3n del riesgo documentada por la autoridad correspondiente.<\/p>\n La organizaci\u00f3n no genera Software Bills of Materials (SBOMs) ni mantiene un inventario completo de componentes de terceros y de c\u00f3digo abierto utilizados en sus aplicaciones.<\/p>\n Sin un SBOM, la organizaci\u00f3n no puede identificar qu\u00e9 aplicaciones se ven afectadas cuando se divulga una vulnerabilidad en un componente de terceros (como ocurri\u00f3 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\u00f3n de riesgos de la cadena de suministro no pueden cumplirse.<\/p>\n No existen archivos SBOM para las aplicaciones desplegadas. Cuando se pregunta \u00ab\u00bfcu\u00e1les de sus aplicaciones utilizan el componente X?\u00bb, la organizaci\u00f3n no puede responder con prontitud. No se integra ning\u00fan an\u00e1lisis automatizado de dependencias en los pipelines.<\/p>\n Implementar la generaci\u00f3n autom\u00e1tica de SBOM como parte del pipeline CI\/CD. Utilizar formatos est\u00e1ndar (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.<\/p>\n Los desarrolladores u operadores pueden acceder directamente a los entornos de producci\u00f3n y realizar cambios fuera del pipeline CI\/CD, eludiendo todos los controles del pipeline, incluidas las puertas de aprobaci\u00f3n, los an\u00e1lisis de seguridad y el registro de auditor\u00eda.<\/p>\n Si se pueden realizar cambios en producci\u00f3n fuera del pipeline gestionado, todo el marco de control queda socavado. Cada control integrado en el pipeline \u2014 aprobaciones, an\u00e1lisis, registro, segregaci\u00f3n de funciones \u2014 puede eludirse simplemente realizando cambios directamente. El pipeline se convierte en algo opcional, no obligatorio.<\/p>\n Los registros de acceso a producci\u00f3n muestran inicios de sesi\u00f3n directos por parte del personal de desarrollo u operaciones. Los cambios en producci\u00f3n no se corresponden con los registros de despliegue del pipeline. Las configuraciones del entorno de producci\u00f3n difieren de lo que el pipeline despleg\u00f3 por \u00faltima vez.<\/p>\n Restringir el acceso a producci\u00f3n a cuentas de servicio autorizadas controladas por el pipeline. Implementar acceso justo a tiempo para escenarios de emergencia con registro completo y revisi\u00f3n posterior al acceso. Monitorizar y alertar sobre cualquier cambio directo en producci\u00f3n fuera del pipeline.<\/p>\n Los hallazgos de an\u00e1lisis de seguridad se suprimen, exoneran o marcan como \u00abaceptados\u00bb sin documentaci\u00f3n formal de aceptaci\u00f3n del riesgo. No existe ning\u00fan registro de qui\u00e9n acept\u00f3 el riesgo, cu\u00e1l fue la justificaci\u00f3n o cu\u00e1ndo caduca la aceptaci\u00f3n.<\/p>\n La aceptaci\u00f3n del riesgo es una opci\u00f3n leg\u00edtima de tratamiento del riesgo, pero solo cuando es una decisi\u00f3n consciente, documentada y autorizada. Las supresiones no gestionadas no son aceptaci\u00f3n del riesgo; son ignorancia del riesgo. Crean bolsas ocultas de riesgo no gestionado que los auditores identificar\u00e1n y se\u00f1alar\u00e1n.<\/p>\n Las configuraciones de an\u00e1lisis de seguridad contienen listas de supresi\u00f3n sin documentaci\u00f3n asociada. Los hallazgos suprimidos incluyen vulnerabilidades de severidad cr\u00edtica o alta. No existe ning\u00fan flujo de trabajo de aprobaci\u00f3n para agregar hallazgos a las listas de supresi\u00f3n. Las supresiones no tienen fecha de vencimiento ni ciclo de revisi\u00f3n.<\/p>\n Implementar un proceso formal de aceptaci\u00f3n del riesgo que requiera justificaci\u00f3n documentada, aprobaci\u00f3n de la autoridad correspondiente, fechas de vencimiento definidas y revisi\u00f3n peri\u00f3dica. Revisar retrospectivamente todas las supresiones existentes y documentar la aceptaci\u00f3n del riesgo o eliminar la supresi\u00f3n.<\/p>\n Los entornos de desarrollo, staging (o pruebas) y producci\u00f3n no est\u00e1n 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.<\/p>\n La segregaci\u00f3n de entornos es un control fundamental que protege los sistemas de producci\u00f3n 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 \u2014pero no comprometan\u2014 a la producci\u00f3n. Sin ella, el riesgo de cambios no controlados, filtraci\u00f3n de datos y contaminaci\u00f3n del entorno aumenta sustancialmente.<\/p>\n La revisi\u00f3n de infraestructura revela recursos compartidos entre entornos. Las mismas credenciales funcionan tanto en desarrollo como en producci\u00f3n. El personal de desarrollo tiene acceso administrativo a los entornos de producci\u00f3n. Los datos de producci\u00f3n se utilizan en desarrollo o pruebas sin anonimizaci\u00f3n.<\/p>\n Implementar l\u00edmites claros de entorno con infraestructura, credenciales y controles de acceso separados. Restringir el acceso a producci\u00f3n al personal operativo autorizado y a las cuentas de servicio del pipeline. Implementar anonimizaci\u00f3n de datos o datos sint\u00e9ticos para entornos que no sean de producci\u00f3n.<\/p>\n Los controles se aplican de forma inconsistente en toda la organizaci\u00f3n. Algunos equipos tienen pipelines bien gestionados con puertas de aprobaci\u00f3n, an\u00e1lisis de seguridad y retenci\u00f3n de evidencia, mientras que otros equipos operan con controles m\u00ednimos o inexistentes.<\/p>\n El cumplimiento es una obligaci\u00f3n organizacional, no una opci\u00f3n a nivel de equipo. La aplicaci\u00f3n inconsistente de controles significa que la postura de cumplimiento de la organizaci\u00f3n es tan s\u00f3lida como su pipeline m\u00e1s d\u00e9bil. Tambi\u00e9n sugiere una brecha de gobernanza: la ausencia de un est\u00e1ndar empresarial para los controles de pipeline y la falta de un mecanismo para hacer cumplir ese est\u00e1ndar.<\/p>\n La comparaci\u00f3n de configuraciones de pipeline entre equipos revela variaciones significativas en la implementaci\u00f3n de controles. Algunos pipelines carecen de puertas de aprobaci\u00f3n, an\u00e1lisis de seguridad o retenci\u00f3n de evidencia que otros s\u00ed tienen. No existe ning\u00fan est\u00e1ndar de gobernanza de pipeline a nivel organizacional, o existe pero no se aplica.<\/p>\n Definir un est\u00e1ndar de gobernanza de pipeline a nivel organizacional que especifique los controles m\u00ednimos requeridos. Implementar mecanismos para hacer cumplir el est\u00e1ndar (plantillas de pipeline, pol\u00edtica como c\u00f3digo, an\u00e1lisis de cumplimiento de configuraciones de pipeline). Realizar una evaluaci\u00f3n de brechas en todos los pipelines y remediar las no conformidades.<\/p>\n Entender c\u00f3mo los auditores descubren estos hallazgos ayuda a los equipos de cumplimiento a prepararse de manera m\u00e1s efectiva:<\/p>\n Los hallazgos individuales son preocupantes, pero las combinaciones de hallazgos revelan problemas de gobernanza m\u00e1s profundos. Cuando el Hallazgo 1 (cuentas de servicio compartidas) y el Hallazgo 2 (puertas de aprobaci\u00f3n 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\u00e1lisis sin puertas) y el Hallazgo 8 (supresiones no gestionadas) coexisten, el programa de pruebas de seguridad de la organizaci\u00f3n es efectivamente decorativo.<\/p>\n Los auditores deben buscar estos patrones, ya que indican si los hallazgos son debilidades aisladas que pueden remediarse individualmente o s\u00edntomas de una brecha de madurez de gobernanza m\u00e1s amplia que requiere una respuesta m\u00e1s integral.<\/p>\n Utilice esta lista como lista de verificaci\u00f3n de autoevaluaci\u00f3n previa a la auditor\u00eda<\/strong>. Para cada hallazgo:<\/p>\n La identificaci\u00f3n y remediaci\u00f3n proactiva de estos hallazgos comunes demuestra madurez de gobernanza y reduce significativamente el riesgo de resultados adversos de auditor\u00eda.<\/p>\n Para obtener m\u00e1s orientaci\u00f3n sobre la preparaci\u00f3n de auditor\u00edas CI\/CD e identificaci\u00f3n de se\u00f1ales de alerta, consulte:<\/p>\nReferencias Regulatorias<\/h3>\n
\n
Evidencia T\u00edpica del Hallazgo<\/h3>\n
Expectativa de Remediaci\u00f3n<\/h3>\n
Severidad: Alta<\/h3>\n
\nHallazgo 6: Sin Generaci\u00f3n de SBOM ni Inventario de Componentes de Terceros<\/h2>\n
Descripci\u00f3n<\/h3>\n
Por Qu\u00e9 Importa<\/h3>\n
Referencias Regulatorias<\/h3>\n
\n
Evidencia T\u00edpica del Hallazgo<\/h3>\n
Expectativa de Remediaci\u00f3n<\/h3>\n
Severidad: Media-Alta<\/h3>\n
\nHallazgo 7: Acceso Directo a Producci\u00f3n Sin Gesti\u00f3n de Cambios<\/h2>\n
Descripci\u00f3n<\/h3>\n
Por Qu\u00e9 Importa<\/h3>\n
Referencias Regulatorias<\/h3>\n
\n
Evidencia T\u00edpica del Hallazgo<\/h3>\n
Expectativa de Remediaci\u00f3n<\/h3>\n
Severidad: Cr\u00edtica<\/h3>\n
\nHallazgo 8: Supresiones de Vulnerabilidades Sin Documentaci\u00f3n de Aceptaci\u00f3n del Riesgo<\/h2>\n
Descripci\u00f3n<\/h3>\n
Por Qu\u00e9 Importa<\/h3>\n
Referencias Regulatorias<\/h3>\n
\n
Evidencia T\u00edpica del Hallazgo<\/h3>\n
Expectativa de Remediaci\u00f3n<\/h3>\n
Severidad: Alta<\/h3>\n
\nHallazgo 9: Sin Segregaci\u00f3n entre Entornos de Desarrollo, Staging y Producci\u00f3n<\/h2>\n
Descripci\u00f3n<\/h3>\n
Por Qu\u00e9 Importa<\/h3>\n
Referencias Regulatorias<\/h3>\n
\n
Evidencia T\u00edpica del Hallazgo<\/h3>\n
Expectativa de Remediaci\u00f3n<\/h3>\n
Severidad: Alta<\/h3>\n
\nHallazgo 10: Aplicaci\u00f3n Inconsistente de Controles entre Equipos o Pipelines<\/h2>\n
Descripci\u00f3n<\/h3>\n
Por Qu\u00e9 Importa<\/h3>\n
Referencias Regulatorias<\/h3>\n
\n
Evidencia T\u00edpica del Hallazgo<\/h3>\n
Expectativa de Remediaci\u00f3n<\/h3>\n
Severidad: Media-Alta<\/h3>\n
\nResumen: Hallazgos, Impacto Regulatorio y Prioridad de Remediaci\u00f3n<\/h2>\n
\n\n
\n \nHallazgo<\/th>\n DORA<\/th>\n NIS2<\/th>\n ISO 27001<\/th>\n SOC 2<\/th>\n PCI DSS<\/th>\n Severidad<\/th>\n Prioridad de Remediaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n \n 1. Cuentas de servicio compartidas<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Alta<\/td>\n Inmediata<\/td>\n<\/tr>\n \n 2. Puertas de aprobaci\u00f3n eludibles<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Alta<\/td>\n Inmediata<\/td>\n<\/tr>\n \n 3. Sin retenci\u00f3n de registros \/ registros mutables<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Alta<\/td>\n Inmediata<\/td>\n<\/tr>\n \n 4. Secretos codificados<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Cr\u00edtica<\/td>\n Inmediata<\/td>\n<\/tr>\n \n 5. An\u00e1lisis de seguridad sin puertas<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Alta<\/td>\n Alta<\/td>\n<\/tr>\n \n 6. Sin SBOM \/ inventario de componentes<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Parcial<\/td>\n Media-Alta<\/td>\n Alta<\/td>\n<\/tr>\n \n 7. Acceso directo a producci\u00f3n<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Cr\u00edtica<\/td>\n Inmediata<\/td>\n<\/tr>\n \n 8. Supresi\u00f3n de vulnerabilidades no gestionada<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Alta<\/td>\n Alta<\/td>\n<\/tr>\n \n 9. Sin segregaci\u00f3n de entornos<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Alta<\/td>\n Alta<\/td>\n<\/tr>\n \n 10. Controles inconsistentes entre equipos<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Media-Alta<\/td>\n Media<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n C\u00f3mo Suelen Aparecer Estos Hallazgos Durante las Auditor\u00edas<\/h2>\n
\n
Reconocimiento de Patrones: Lo que Revelan las Combinaciones de Hallazgos<\/h2>\n
Recomendaciones para los Equipos de Cumplimiento<\/h2>\n
\n
Recursos Relacionados<\/h2>\n
\n
Relacionado para Auditores<\/h3>\n