SDLC Seguro desde la Perspectiva del Auditor — Qué Verificar en Cada Fase

El SDLC Seguro como Marco de Control

El Ciclo de Vida de Desarrollo de Software Seguro (Secure SDLC) se presenta a menudo como una metodología de desarrollo — una secuencia de prácticas que los equipos de ingeniería siguen para construir software más seguro. Para los auditores y oficiales de cumplimiento, sin embargo, debe evaluarse como algo más fundamental: un marco de control.

Cada fase del SDLC representa un punto de control donde deben ocurrir actividades de seguridad específicas, debe generarse evidencia específica y deben verificarse resultados específicos. Cuando una organización afirma operar un SDLC Seguro, los auditores deben ir más allá de la documentación de procesos y evaluar si los controles están realmente operando en cada fase.

Esta guía recorre cada fase del SDLC desde la perspectiva del auditor, especificando qué debe ocurrir, qué evidencia solicitar, cómo se ve una buena práctica y qué debe generar preocupación.

Fase PLAN

Qué Debe Ocurrir

Las consideraciones de seguridad se integran en la planificación del proyecto antes de que comience cualquier desarrollo. Esto incluye el modelado de amenazas para identificar posibles vectores de ataque, la definición de requisitos de seguridad junto con los requisitos funcionales y la clasificación de la aplicación según el marco de clasificación de riesgos de la organización.

Evidencia a Solicitar

Documentación del modelo de amenazas (diagramas de flujo de datos, identificación de amenazas, decisiones de mitigación)
Requisitos de seguridad documentados en el backlog del proyecto o repositorio de requisitos
Registro de clasificación de riesgos de aplicaciones con aprobación
Registros de participación de seguridad en las sesiones de planificación

Cómo Se Ve una Buena Práctica

Se crean modelos de amenazas para todas las aplicaciones de Nivel 1 y Nivel 2 y se actualizan cuando cambia la arquitectura
Los requisitos de seguridad son trazables — cada amenaza identificada en el modelo tiene un requisito correspondiente o un riesgo aceptado
La clasificación impulsa los requisitos de control descendentes (frecuencia de pruebas, flujos de trabajo de aprobación)
El personal de seguridad participa en las actividades de planificación, evidenciado por los registros de reuniones

Cómo Se Ve una Mala Práctica

No existen modelos de amenazas, o se crearon una vez y nunca se actualizaron
Los requisitos de seguridad son genéricos («la aplicación debe ser segura») en lugar de específicos y verificables
La clasificación de la aplicación falta o se realizó sin aportación de seguridad o cumplimiento
La seguridad no participa hasta las pruebas o el despliegue

Fase CODE

Qué Debe Ocurrir

Los desarrolladores siguen estándares de codificación segura documentados. Los cambios de código se revisan en busca de problemas de seguridad — ya sea mediante revisión por pares con revisores con conciencia de seguridad o mediante Static Application Security Testing (SAST) automatizado. El análisis de secretos evita que las credenciales, claves API y tokens se confirmen en los repositorios.

Evidencia a Solicitar

Documento de estándares de codificación segura, aprobado y versionado
Registros de revisión de código que muestren comentarios relacionados con seguridad y sus resoluciones
Resultados de análisis SAST integrados en el flujo de trabajo de desarrollo
Configuración de análisis de secretos y registros de alertas
Registros de formación para desarrolladores sobre prácticas de codificación segura

Cómo Se Ve una Buena Práctica

SAST se ejecuta automáticamente en cada pull request o confirmación de código, con resultados visibles para los desarrolladores
Los registros de revisión de código muestran hallazgos de seguridad siendo identificados y abordados — no solo revisión funcional
El análisis de secretos bloquea las confirmaciones que contienen credenciales, con un proceso documentado para rotar los secretos expuestos
Los desarrolladores reciben formación anual (mínimo) en codificación segura relevante para su pila tecnológica

Cómo Se Ve una Mala Práctica

SAST se ejecuta manualmente o solo antes de las versiones, lo que significa que las vulnerabilidades se acumulan
Existen revisiones de código pero nunca incluyen retroalimentación relacionada con la seguridad
No hay análisis de secretos, o las alertas se ignoran
Los estándares de codificación segura están desactualizados o no están alineados con las tecnologías en uso

Fase BUILD

Qué Debe Ocurrir

El proceso de compilación incluye Software Composition Analysis (SCA) para identificar vulnerabilidades en dependencias de terceros y de código abierto. Se genera un Software Bill of Materials (SBOM) para cada compilación para mantener un inventario de todos los componentes. Los artefactos de compilación se firman para garantizar la integridad y prevenir la manipulación.

Evidencia a Solicitar

Resultados de análisis SCA para compilaciones recientes, mostrando las vulnerabilidades identificadas y su disposición
Registros SBOM para las versiones de producción
Configuración de firma de artefactos y registros de verificación
Política para umbrales de vulnerabilidades aceptables en dependencias

Cómo Se Ve una Buena Práctica

SCA se ejecuta en cada compilación con políticas definidas para bloquear compilaciones que contengan vulnerabilidades críticas o de alta severidad
Los SBOMs se generan automáticamente y se almacenan junto a los registros de versiones
La firma de artefactos se aplica — los artefactos sin firmar no pueden desplegarse en producción
Existe un proceso para el parcheo de emergencia de vulnerabilidades críticas de dependencias

Cómo Se Ve una Mala Práctica

SCA no está integrado en el proceso de compilación o se ejecuta solo periódicamente
Sin generación de SBOM — la organización no puede identificar qué componentes están en producción
Sin firma de artefactos — no hay forma de verificar que los artefactos desplegados coincidan con las compilaciones aprobadas
Las vulnerabilidades críticas conocidas en dependencias están presentes en producción sin aceptación documentada

Fase TEST

Qué Debe Ocurrir

Dynamic Application Security Testing (DAST) se realiza contra aplicaciones en ejecución para identificar vulnerabilidades que el análisis estático no puede detectar (fallos de autenticación, problemas de configuración, vulnerabilidades de inyección en tiempo de ejecución). Las pruebas de penetración por personal cualificado proporcionan una perspectiva adversarial. Los entornos de prueba están aislados de la producción para evitar la filtración de datos.

Evidencia a Solicitar

Resultados de análisis DAST y registros de remediación
Informes de pruebas de penetración con alcance, metodología, hallazgos y estado de remediación
Evidencia de aislamiento de entornos (diagramas de red, controles de acceso)
Registros que muestren que la frecuencia de pruebas se alinea con el nivel de riesgo de la aplicación

Cómo Se Ve una Buena Práctica

DAST es automatizado y se ejecuta con la frecuencia especificada por la clasificación de riesgos de la aplicación
Las pruebas de penetración son realizadas por testers independientes cualificados (internos o externos) con un alcance definido
Los entornos de prueba no contienen datos de producción, o los datos de producción están adecuadamente enmascarados
Los hallazgos de las pruebas se rastrean hasta la remediación verificada

Cómo Se Ve una Mala Práctica

DAST no se realiza, o los resultados se ignoran
Las pruebas de penetración son realizadas por el mismo equipo que construyó la aplicación, sin independencia
Los entornos de prueba contienen datos de producción sin enmascarar
Los hallazgos de pruebas permanecen abiertos indefinidamente sin escalada

Fase RELEASE

Qué Debe Ocurrir

Las versiones están sujetas a flujos de trabajo de aprobación que verifican que se han completado todas las actividades de seguridad requeridas. Las puertas de política en el pipeline de entrega garantizan que se cumplan los requisitos de seguridad antes de que el código pueda avanzar a producción. Las decisiones de versión se documentan como parte de la gestión de cambios.

Evidencia a Solicitar

Registros de aprobación de versiones que muestren la firma de seguridad donde sea necesario
Resultados de puertas de política del pipeline de entrega (registros de aprobación/fallo con marcas de tiempo)
Registros de gestión de cambios que vinculen las versiones con los resultados de las pruebas de seguridad
Registros de excepciones para cualquier versión que haya omitido las puertas de política

Cómo Se Ve una Buena Práctica

Las puertas de política son automatizadas y se aplican — el pipeline impide la versión si no se cumplen los criterios de seguridad
La firma de seguridad se requiere para las aplicaciones de Nivel 1 y Nivel 2, con aprobación documentada
Las omisiones de puertas requieren aprobación formal de excepción y se rastrean
Los registros de versiones están vinculados a resultados de análisis y pruebas específicos

Cómo Se Ve una Mala Práctica

No existen puertas de política — las pruebas de seguridad son solo consultivas
Las puertas existen pero se omiten con frecuencia sin aprobación formal
Las aprobaciones de versiones hacen referencia a pruebas de seguridad pero no vinculan a resultados específicos
Los procedimientos de versión de emergencia se usan de forma rutinaria, eludiendo los controles normales

Fase DEPLOY

Qué Debe Ocurrir

Los despliegues se registran con suficiente detalle para establecer qué se desplegó, cuándo, por quién y en qué entorno. La configuración se valida contra las líneas base de seguridad. Los entornos de producción coinciden con las configuraciones que fueron probadas.

Evidencia a Solicitar

Registros de despliegue con marcas de tiempo, identificadores de artefactos, identidad del desplegador y entorno objetivo
Registros de validación de configuración (comprobaciones de línea base de seguridad)
Evidencia de paridad de entornos entre pruebas y producción
Registros de reversiones donde se revirtieron despliegues

Cómo Se Ve una Buena Práctica

Los despliegues son automatizados, registrados y auditables — los despliegues manuales a producción están prohibidos o requieren aprobación excepcional
La detección de desviación de configuración identifica y alerta sobre las desviaciones de las líneas base de seguridad
La infraestructura como código o equivalente garantiza la paridad de entornos
Los despliegues fallidos y las reversiones se documentan con la causa raíz

Cómo Se Ve una Mala Práctica

Despliegues manuales sin rastro de auditoría
Sin validación de configuración — los ajustes de seguridad se asumen en lugar de verificarse
Diferencias significativas entre los entornos de prueba y producción
El acceso al despliegue se otorga ampliamente sin restricciones basadas en roles

Fase MONITOR

Qué Debe Ocurrir

Las aplicaciones de producción se monitorizan en busca de eventos de seguridad, comportamiento anómalo y nuevas vulnerabilidades. Los mecanismos de protección en tiempo de ejecución detectan y responden a las amenazas activas. Un proceso de divulgación de vulnerabilidades permite a los investigadores externos informar sobre los problemas de manera responsable.

Evidencia a Solicitar

Configuración de monitorización de seguridad y registros de alertas
Registros de detección y respuesta a incidentes relacionados con aplicaciones
Política de divulgación de vulnerabilidades (accesible públicamente)
Registros de vulnerabilidades reportadas a través de canales de divulgación y su resolución
Registros de despliegue de herramientas de seguridad en tiempo de ejecución

Cómo Se Ve una Buena Práctica

La monitorización de seguridad a nivel de aplicación está activa, con alertas enrutadas al equipo de operaciones de seguridad
Los procedimientos de respuesta a incidentes abordan específicamente los incidentes a nivel de aplicación (no solo infraestructura)
Se publica una política de divulgación de vulnerabilidades y los informes se priorizan y rastrean
Las vulnerabilidades recién divulgadas en dependencias desencadenan una reevaluación mediante SCA

Cómo Se Ve una Mala Práctica

Sin monitorización a nivel de aplicación — solo hay monitorización de infraestructura
Sin proceso de divulgación de vulnerabilidades — los informes externos no tienen canal de recepción
Los incidentes de seguridad que involucran aplicaciones se gestionan de forma ad-hoc sin procedimientos documentados
Sin proceso para responder a vulnerabilidades de dependencias recién divulgadas

Resumen: Controles, Evidencia y Señales de Alerta por Fase

Fase	Control Clave	Artefacto de Evidencia	Dónde Encontrarlo	Señal de Alerta
PLAN	Modelado de amenazas	Documento del modelo de amenazas	Wiki, repositorio de diseño, registro de riesgos	Sin modelos de amenazas o nunca actualizados
CODE	SAST / revisión de código	Resultados de análisis, registros de revisión	Registros del pipeline CI/CD, herramienta de revisión de código	SAST no integrado o resultados ignorados
BUILD	SCA / SBOM	Resultados de análisis de dependencias, archivos SBOM	Sistema de compilación, repositorio de artefactos	Sin inventario de componentes para producción
TEST	DAST / pruebas de penetración	Informes de análisis, informes de pentesting	Herramientas de pruebas de seguridad, archivo de informes	Sin pruebas dinámicas o sin independencia
RELEASE	Puertas de política / aprobación	Resultados de puertas, registros de aprobación	Registros del pipeline, sistema de gestión de cambios	Puertas omitidas sin aprobación
DEPLOY	Registro de despliegues	Registros de despliegue, comprobaciones de configuración	Plataforma de despliegue, herramientas de monitorización	Despliegues manuales sin rastro de auditoría
MONITOR	Monitorización en tiempo de ejecución	Registros de alertas, registros de incidentes	SIEM, plataforma de monitorización, sistema de tickets	Sin monitorización a nivel de aplicación

Hallazgos Comunes de Auditoría en las Fases del SDLC

Basándose en los resultados típicos de auditoría en organizaciones reguladas, los hallazgos más frecuentes incluyen:

Cobertura inconsistente: Los controles de seguridad se aplican a algunas aplicaciones pero no a otras, sin justificación documentada para la diferencia
Brechas de evidencia: Los controles se describen en la política, pero la evidencia de ejecución está incompleta o falta — particularmente para el modelado de amenazas y la revisión de código de seguridad
Trazabilidad rota: No es posible rastrear desde una versión de producción hasta los resultados de pruebas de seguridad específicos que la aprobaron
Hallazgos obsoletos: Las vulnerabilidades identificadas en las pruebas permanecen abiertas durante meses o años sin remediación, escalada o aceptación formal del riesgo
Proceso sin aplicación: La organización tiene un documento de SDLC Seguro pero no tiene puertas automatizadas ni verificación independiente de que se sigue
Fase MONITOR descuidada: Inversión significativa en seguridad previa a la producción pero sin monitorización en tiempo de ejecución ni gestión de vulnerabilidades para aplicaciones de producción

Evaluación de la Madurez del SDLC

Los auditores pueden usar un modelo de madurez para caracterizar qué tan bien está implementado el SDLC Seguro. Esto ayuda a enmarcar los hallazgos y las recomendaciones de manera proporcional.

Nivel de Madurez	Características	Implicaciones de Auditoría
Ad-Hoc (Nivel 1)	Las actividades de seguridad se realizan de manera inconsistente, dependen de la iniciativa individual y no están documentadas en políticas. Sin automatización.	Brechas de control fundamentales. Los hallazgos serán numerosos y significativos. Recomendar establecer políticas y gobernanza de línea base.
Definido (Nivel 2)	Existen políticas y procedimientos. Las actividades de seguridad están documentadas y asignadas. Las herramientas están en su lugar pero pueden no aplicarse de manera consistente.	Los controles existen pero la efectividad operativa puede ser débil. Enfocarse en verificar la ejecución consistente y la calidad de la evidencia.
Gestionado (Nivel 3)	Los controles de seguridad se aplican de manera consistente, se automatizan donde es posible y se monitorizan mediante métricas. La gobernanza es activa.	Los controles operan de manera efectiva. El enfoque de auditoría se desplaza hacia casos límite, excepciones y mejora continua.
Optimizado (Nivel 4)	Mejora continua basada en métricas. Identificación proactiva de amenazas. La seguridad está completamente integrada en la cultura de desarrollo y las herramientas. Automatización avanzada.	Alta confianza en el entorno de control. El enfoque de auditoría en la sostenibilidad, la adaptación a nuevas amenazas y la gobernanza de capacidades avanzadas.

Lectura Adicional

Para orientación relacionada, consulte:

Relacionado para Auditores

Glosario — Definiciones en lenguaje sencillo de términos técnicos
Cómo los Auditores Revisan CI/CD
Cumplimiento Continuo mediante CI/CD
Controles Básicos de Seguridad CI/CD

¿Nuevo en la auditoría de CI/CD? Empiece con nuestra Guía para Auditores.