Propósito: Por qué importa un marco de madurez
Los reguladores y auditores no esperan la perfección. Esperan un progreso demostrable. Un marco de evaluación de madurez proporciona la base estructurada para que una organización comprenda dónde se encuentra, identifique brechas, priorice mejoras y — de manera crítica — demuestre a los reguladores que avanza en la dirección correcta.
Sin un marco de madurez, las organizaciones se enfrentan a dos problemas comunes:
- Sobreestimación: Los equipos creen que sus prácticas DevSecOps son más maduras de lo que realmente son, lo que genera sorpresas desagradables durante las auditorías
- Inversión sin foco: Los esfuerzos de mejora se dispersan en lugar de dirigirse a las áreas que más importan para el cumplimiento regulatorio y la reducción del riesgo
Este marco está diseñado para responsables de cumplimiento, auditores y gestores de riesgo — no para ingenieros. Se centra en qué evaluar, qué evidencias buscar y cómo interpretar los hallazgos en un contexto regulatorio.
Niveles de madurez definidos
Nivel 1: Inicial / Ad-hoc
La seguridad se aborda de forma reactiva e incoherente. No existen procesos formales para integrar la seguridad en los pipelines de entrega de software. Las actividades de seguridad dependen de la iniciativa individual en lugar de la política organizacional.
Características:
- Sin integración formal de seguridad en los pipelines CI/CD
- Pruebas de seguridad manuales y ad-hoc (si las hay)
- Sin políticas de seguridad documentadas para la entrega de software
- Respuesta reactiva a incidentes — problemas encontrados en producción, no durante el desarrollo
- Sin recopilación sistemática de evidencias para fines de cumplimiento
Nivel 2: Definido
Se dispone de herramientas y procesos básicos de seguridad, y las políticas están documentadas. Sin embargo, la aplicación es incoherente y persisten brechas significativas en la cobertura y la generación de evidencias.
Características:
- Herramientas básicas de análisis de seguridad integradas en algunos pipelines
- Políticas de seguridad documentadas pero aplicadas de forma incoherente
- Algunos roles y responsabilidades definidos para las actividades de seguridad
- Gestión de vulnerabilidades existente pero con cobertura incompleta
- La recopilación de evidencias es manual e incompleta
Nivel 3: Gestionado
Los controles de seguridad están integrados en los pipelines como puertas de política aplicadas. Los controles se aplican de manera coherente, los roles están claramente definidos y las evidencias se generan sistemáticamente para apoyar el cumplimiento.
Características:
- Puertas de seguridad aplicadas por política en todos los pipelines de producción
- Aplicación coherente de controles en todos los equipos
- Generación y retención automatizada de evidencias
- Matriz RACI definida para actividades DevSecOps
- Informes periódicos de métricas a la dirección
- Proceso de gestión de excepciones con aprobaciones documentadas
Nivel 4: Optimizado
El cumplimiento continuo se logra a través de la automatización. Los controles de seguridad se refinan continuamente en función de métricas e inteligencia sobre amenazas. La organización demuestra gestión predictiva del riesgo y mejora continua.
Características:
- Monitorización de cumplimiento continuo y recopilación automatizada de evidencias
- Ciclos de mejora impulsados por métricas con resultados documentados
- Gestión predictiva del riesgo mediante análisis de tendencias
- Controles avanzados de seguridad e integridad de la cadena de suministro
- Informes a nivel de consejo con clara alineación del apetito de riesgo
- Reevaluación periódica de la madurez con progresión demostrada
Dimensiones de evaluación
La evaluación de madurez cubre diez dimensiones. Cada dimensión se evalúa de forma independiente, ya que las organizaciones suelen tener una madurez desigual entre áreas.
Matriz de evaluación
| Dimensión | Nivel 1 (Inicial) | Nivel 2 (Definido) | Nivel 3 (Gestionado) | Nivel 4 (Optimizado) |
|---|---|---|---|---|
| Integración de pruebas de seguridad | Sin pruebas de seguridad automatizadas | SAST o SCA básico en algunos pipelines | SAST, DAST y SCA en todos los pipelines de producción con puertas aplicadas | Pruebas exhaustivas incluyendo IAST, análisis de contenedores, análisis de IaC; ajuste continuo para reducir falsos positivos |
| Aplicación de políticas | Sin políticas formales para la seguridad del pipeline | Políticas documentadas pero aplicadas manualmente | Políticas aplicadas como puertas automatizadas; la omisión requiere aprobación documentada | Política como código con control de versiones, verificación automática de cumplimiento y refinamiento continuo de políticas |
| Gobernanza de accesos | Acceso ad-hoc sin revisión regular | Política de acceso documentada; cierto acceso basado en roles | Acceso basado en roles aplicado; revisiones periódicas de accesos; acceso privilegiado gestionado | Acceso justo a tiempo; certificación de acceso automatizada; monitorización continua de anomalías de acceso |
| Gestión de secretos | Secretos en código o archivos de configuración | Almacén centralizado de secretos para algunas aplicaciones | Todos los secretos gestionados centralmente; políticas de rotación aplicadas; sin secretos en el código (verificado por análisis) | Rotación automatizada; secretos dinámicos; rastro de auditoría completo; detección de brechas de secretos |
| Integridad de artefactos | Sin controles sobre la procedencia de artefactos | Repositorio básico de artefactos con algunos controles de acceso | Artefactos firmados; procedencia verificada; imágenes base aprobadas aplicadas | Integridad completa de la cadena de suministro (SLSA Nivel 3+); verificación automatizada de procedencia; generación y monitorización de SBOM |
| Gestión de vulnerabilidades | Sin seguimiento sistemático de vulnerabilidades | Vulnerabilidades rastreadas pero sin SLAs; remediación incoherente | Remediación impulsada por SLA; priorización basada en riesgos; informes periódicos | Gestión predictiva de vulnerabilidades; remediación automatizada para patrones conocidos; monitorización continua de SLA |
| Preparación ante incidentes | Sin plan de respuesta a incidentes para eventos de seguridad del pipeline | Plan básico de respuesta a incidentes existente; no probado | Plan de respuesta a incidentes probado; roles definidos; proceso de revisión post-incidente | Detección automatizada de incidentes en pipelines; respuesta impulsada por guías de actuación; ejercicios regulares; mejora continua a partir de lecciones aprendidas |
| Evidencias de cumplimiento | Sin recopilación sistemática de evidencias | Recopilación manual de evidencias; cobertura incompleta | Generación automatizada de evidencias; evidencias mapeadas a requisitos de control; política de retención aplicada | Monitorización continua de cumplimiento; paneles de evidencias en tiempo real; informes regulatorios automatizados |
| Gobernanza de terceros | Sin visibilidad sobre el riesgo de componentes de terceros | Inventario básico de dependencias; revisión ocasional | SBOM completo; proceso de evaluación de riesgos de terceros; políticas de componentes aprobados | Monitorización continua de terceros; puntuación automática de riesgos; requisitos de seguridad de proveedores aplicados contractual y técnicamente |
| Cultura y formación | Sin formación en seguridad para los equipos de desarrollo | Formación anual de concienciación en seguridad; orientación ad-hoc sobre codificación segura | Formación específica por rol; programa de defensores de seguridad; efectividad de la formación medida | Cultura de aprendizaje continuo; formación en seguridad gamificada; intercambio de conocimientos entre equipos; formación vinculada a la mejora de la madurez |
Cuestionario de autoevaluación
Para cada dimensión, responda las siguientes preguntas para determinar su nivel aproximado de madurez. Si la respuesta a todas las preguntas de un nivel es «sí», la organización ha alcanzado ese nivel para la dimensión.
Integración de pruebas de seguridad
- ¿Están integradas en los pipelines CI/CD herramientas de análisis de seguridad automatizadas? (Nivel 2)
- ¿Se ejecutan análisis SAST, DAST y SCA en todos los pipelines destinados a producción? (Nivel 3)
- ¿Los fallos en los análisis de seguridad bloquean los despliegues salvo aprobación explícita? (Nivel 3)
- ¿Se ajustan continuamente las herramientas de análisis en función del análisis de falsos positivos y la inteligencia sobre amenazas? (Nivel 4)
Aplicación de políticas
- ¿Están formalmente documentadas las políticas de seguridad para la entrega de software? (Nivel 2)
- ¿Se aplican las políticas como puertas automatizadas en los pipelines (no solo documentadas)? (Nivel 3)
- ¿Requiere cada omisión de política una aprobación documentada de una persona autorizada? (Nivel 3)
- ¿Se gestionan las políticas como código, con control de versiones y sujetas a gestión de cambios? (Nivel 4)
Gobernanza de accesos
- ¿Existe una política de control de acceso documentada para las plataformas CI/CD? (Nivel 2)
- ¿Se aplica el control de acceso basado en roles en todas las plataformas del pipeline? (Nivel 3)
- ¿Se realizan revisiones de acceso al menos trimestralmente con resultados documentados? (Nivel 3)
- ¿Se implementa el acceso privilegiado justo a tiempo o con tiempo limitado? (Nivel 4)
Gestión de secretos
- ¿Se utiliza una solución centralizada de gestión de secretos? (Nivel 2)
- ¿Se gestionan centralmente todos los secretos de aplicaciones y pipelines, sin secretos en el código? (Nivel 3)
- ¿Están definidas y aplicadas las políticas de rotación de secretos? (Nivel 3)
- ¿Se usan secretos dinámicos de corta duración donde sea posible? (Nivel 4)
Gestión de vulnerabilidades
- ¿Se rastrean las vulnerabilidades de los análisis de seguridad en un sistema central? (Nivel 2)
- ¿Están definidos los SLAs de remediación por gravedad y se aplican de manera coherente? (Nivel 3)
- ¿Se informa periódicamente a la dirección sobre el estado de la remediación de vulnerabilidades? (Nivel 3)
- ¿Se analizan las tendencias de remediación para identificar problemas sistémicos e impulsar acciones preventivas? (Nivel 4)
Evidencias de cumplimiento
- ¿Se recopilan algunas evidencias de cumplimiento de los procesos CI/CD? (Nivel 2)
- ¿La generación de evidencias está automatizada y mapeada a requisitos de control específicos? (Nivel 3)
- ¿Se retienen las evidencias de acuerdo con una política de retención definida? (Nivel 3)
- ¿Se monitoriza continuamente la postura de cumplimiento con paneles en tiempo real? (Nivel 4)
Enfoque del análisis de brechas
Una vez completada la autoevaluación, el análisis de brechas debe seguir un enfoque priorizado por riesgo:
- Mapear la madurez actual por dimensión — crear un mapa de calor que muestre del Nivel 1 al Nivel 4 para cada una de las diez dimensiones
- Identificar los requisitos mínimos regulatorios — determinar el nivel mínimo de madurez requerido por las regulaciones aplicables (ver más abajo)
- Priorizar brechas — centrarse primero en las dimensiones donde la madurez actual está por debajo del mínimo regulatorio
- Evaluar esfuerzo y dependencias — algunas mejoras requieren capacidades fundamentales (por ejemplo, no se puede alcanzar el Nivel 3 en evidencias de cumplimiento sin el Nivel 3 en integración de pruebas de seguridad)
- Definir la hoja de ruta de mejora — secuenciar las mejoras de forma lógica, con hitos claros y responsables
Expectativas mínimas regulatorias
| Marco regulatorio | Madurez mínima típica | Justificación |
|---|---|---|
| DORA (servicios financieros) | Nivel 3 en todas las dimensiones | DORA exige gestión sistemática de riesgos ICT, controles probados, capacidades de respuesta a incidentes y gobernanza de terceros — todas características del Nivel 3 |
| NIS2 (infraestructuras críticas) | Nivel 3 en todas las dimensiones | El Artículo 21 de NIS2 exige medidas «apropiadas y proporcionadas» que cubran la cadena de suministro, la gestión de incidentes y la continuidad del negocio — alcanzable en el Nivel 3 |
| ISO 27001 | Nivel 2-3 según el alcance | ISO 27001 exige políticas documentadas y evidencias de la efectividad de los controles. El Nivel 2 puede ser suficiente para la certificación inicial; el Nivel 3 para un SGSI maduro |
| SOC 2 | Nivel 2-3 según los criterios | Los Criterios de Servicios de Confianza de SOC 2 requieren controles diseñados y en funcionamiento. El Nivel 3 proporciona la base de evidencias más sólida |
| PCI DSS (alcance CDE) | Nivel 3 para pipelines que afectan al CDE | Los requisitos de PCI DSS para la gestión de cambios, el control de acceso y la gestión de vulnerabilidades se alinean con las características del Nivel 3 |
Plantilla de hoja de ruta
Utilice la siguiente plantilla para estructurar la hoja de ruta de mejora. Cada fila representa una iniciativa de mejora vinculada a una dimensión y brecha de madurez específica.
| Dimensión | Nivel actual | Nivel objetivo | Acciones clave | Plazo | Responsable | Dependencias |
|---|---|---|---|---|---|---|
| Pruebas de seguridad | 2 | 3 | Ampliar SAST/DAST/SCA a todos los pipelines de producción; implementar puertas aplicadas | Q2 2026 | Responsable de DevSecOps | Finalización del inventario de pipelines |
| Aplicación de políticas | 1 | 3 | Documentar políticas; implementar como puertas automatizadas; establecer proceso de excepciones | Q3 2026 | Arquitecto de seguridad | Pruebas de seguridad en Nivel 3 |
| Evidencias de cumplimiento | 1 | 3 | Implementar recopilación automatizada de evidencias; mapear al marco de control; definir retención | Q3 2026 | Responsable de cumplimiento | Aplicación de políticas en Nivel 3 |
| Gobernanza de accesos | 2 | 3 | Aplicar RBAC; implementar revisiones trimestrales; gestionar acceso privilegiado | Q2 2026 | Responsable del equipo de plataforma | Ninguna |
| Gestión de vulnerabilidades | 2 | 3 | Definir SLAs por gravedad; implementar seguimiento; establecer informes de gestión | Q2 2026 | Responsable de DevSecOps | Pruebas de seguridad en Nivel 2+ |
Esto es ilustrativo. Cada organización debe completarlo en función de sus propios resultados de evaluación.
Qué deben verificar los auditores
Evaluaciones de madurez documentadas
- ¿Ha realizado la organización una evaluación formal de madurez DevSecOps?
- ¿Está documentada la evaluación con evidencias que respalden la calificación de cada dimensión?
- ¿Fue la evaluación realizada por alguien independiente del equipo DevSecOps (o al menos validada de forma independiente)?
- ¿Está la evaluación fechada y bajo control de versiones?
Planes de mejora
- ¿Existe una hoja de ruta de mejora documentada vinculada a la evaluación de madurez?
- ¿Están las acciones de mejora asignadas a responsables específicos con fechas objetivo?
- ¿Está la hoja de ruta priorizada en función de los requisitos regulatorios y el riesgo?
- ¿Existe asignación presupuestaria que respalde el plan de mejora?
Evidencia de progreso
- ¿Se ha repetido la evaluación de madurez (al menos anualmente)?
- ¿Existe evidencia de mejora de la madurez a lo largo del tiempo?
- Donde la madurez no ha mejorado, ¿existe una explicación documentada y un plan revisado?
- ¿Se rastrean y comunican a la dirección los hitos de mejora?
Señales de alerta para auditores y responsables de cumplimiento
| Señal de alerta | Por qué importa | Hallazgo probable |
|---|---|---|
| Nunca se ha realizado ninguna evaluación de madurez | La organización no puede demostrar conocimiento de su propia postura de seguridad | Deficiencia de gobernanza — sin línea base para la mejora |
| La madurez es estancada durante varios períodos de evaluación | Los planes de mejora no son eficaces o no tienen recursos | Preocupación sobre el compromiso de la dirección — DORA Art. 5 / NIS2 Art. 20 |
| La madurez autoevaluada no coincide con las evidencias | La evaluación no es fiable — posible sobreestimación de controles | Brecha en el diseño o efectividad operativa de controles |
| Sin hoja de ruta de mejora a pesar de brechas identificadas | La evaluación sin acción no aporta valor | Deficiencia en la gestión del riesgo |
| Madurez por debajo del Nivel 3 para entidad regulada por DORA/NIS2 | Por debajo de las expectativas mínimas regulatorias | Riesgo de incumplimiento que requiere remediación urgente |
| Evaluación realizada únicamente por el equipo DevSecOps sin validación independiente | Sesgo de autoevaluación — puede sobreestimar la madurez | Preocupación sobre la objetividad |
Próximos pasos
Una evaluación de madurez no es un ejercicio único. Es la base de un ciclo de mejora continua que los reguladores y auditores esperan ver. Las organizaciones deben:
- Realizar una evaluación inicial utilizando este marco, idealmente con validación independiente
- Documentar los resultados y compartirlos con la dirección y la función de cumplimiento
- Desarrollar una hoja de ruta de mejora priorizada alineada con los requisitos regulatorios
- Reevaluar al menos anualmente, conservando las evaluaciones históricas como evidencia de progreso
- Informar sobre las tendencias de madurez al consejo como parte del ciclo de informes de postura de seguridad
Para más orientación, consulte nuestros recursos sobre gobernanza del programa DevSecOps, arquitectura de seguridad y preparación para auditorías y gobernanza.
Relacionado para auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- Controles de seguridad principales de CI/CD
- Informe ejecutivo de auditoría
- Arquitectura de cumplimiento dual
¿Nuevo en la auditoría de CI/CD? Comience con nuestra Guía para auditores.
