Las pruebas estáticas de seguridad de aplicaciones (SAST) constituyen un control de seguridad fundamental en los entornos regulados de entrega de software. Para los auditores, los responsables de cumplimiento y los reguladores, la pregunta crítica no es qué herramienta SAST ha seleccionado una organización, sino si los controles SAST son eficaces, exigibles, evidenciables y están gobernados.
En los entornos regulados, SAST no es una decisión de herramientas: es una decisión arquitectónica y de gobernanza que afecta directamente a la capacidad de la organización para demostrar prácticas de desarrollo seguro ante auditores y reguladores.
Esta guía ofrece un marco estructurado para evaluar la eficacia de los controles SAST dentro de las canalizaciones CI/CD, centrándose en la cobertura, la exigibilidad, las puertas de política, la gestión de excepciones, la generación de evidencia y la alineación regulatoria.
Por qué los controles SAST importan para la auditoría y la gobernanza
SAST analiza el código fuente en busca de vulnerabilidades de seguridad antes de que las aplicaciones se compilen o desplieguen. Cuando se implementa correctamente, SAST proporciona una detección temprana de debilidades de codificación, reduciendo el coste y el riesgo de que las vulnerabilidades lleguen a producción.
Desde la perspectiva de la gobernanza, SAST cumple múltiples funciones:
- Aporta evidencia de detección proactiva de vulnerabilidades dentro del ciclo de vida de desarrollo.
- Demuestra que la seguridad está integrada en los procesos de entrega, y no se aplica de forma retrospectiva.
- Genera registros auditables de qué se analizó, cuándo, qué se encontró y cómo se resolvieron los hallazgos.
- Respalda el cumplimiento regulatorio al mapearse con los requisitos de desarrollo seguro de múltiples marcos.
Las organizaciones que tratan SAST como una herramienta opcional o consultiva —en lugar de como un control exigible— crean brechas de gobernanza significativas que los auditores identificarán.
Marco de evaluación SAST para auditores
Al evaluar los controles SAST de una organización, los auditores deben examinar seis áreas clave:
1. Cobertura: porcentaje de código analizado
Determine si el análisis SAST cubre de forma adecuada el código de la organización:
- ¿Qué porcentaje de los repositorios activos está sujeto al análisis SAST?
- ¿Todos los lenguajes de la pila tecnológica están cubiertos por la herramienta SAST?
- ¿Los repositorios recién creados se incorporan automáticamente al análisis?
- ¿Existe un inventario de los repositorios excluidos con una justificación documentada?
2. Exigibilidad: ¿se actúa sobre los resultados?
Evalúe si los hallazgos de SAST influyen en las decisiones de desarrollo y despliegue:
- ¿Los análisis SAST se ejecutan automáticamente en las canalizaciones CI/CD?
- ¿Los hallazgos generan tareas accionables en los sistemas de seguimiento de incidencias?
- ¿Existe evidencia de que los hallazgos se clasifican, asignan y remedian?
- ¿Los desarrolladores son responsables de resolver los hallazgos dentro de plazos definidos?
3. Puertas de política: ¿los hallazgos críticos bloquean el despliegue?
Verifique que las puertas de política imponen estándares mínimos de seguridad:
- ¿Los hallazgos críticos o de gravedad alta bloquean las fusiones o los despliegues?
- ¿Los umbrales de las puertas se definen en la política y se aplican en las configuraciones de la canalización?
- ¿Se pueden eludir las puertas? Si es así, ¿la elusión se registra, se justifica y se aprueba?
- ¿Existe segregación de funciones entre los desarrolladores y quienes aprueban las excepciones a las puertas?
4. Gestión de excepciones: ¿están gobernadas las supresiones?
Evalúe cómo se gestionan los falsos positivos y los riesgos aceptados:
- ¿Existe un proceso formal para suprimir los hallazgos de SAST?
- ¿Las supresiones requieren una justificación documentada y la aprobación de la dirección o del equipo de seguridad?
- ¿Las supresiones tienen una vigencia limitada y están sujetas a revisión periódica?
- ¿La proporción de supresiones se controla y se comunica como métrica de gobernanza?
5. Evidencia y rastro de auditoría
Evalúe la calidad y la exhaustividad de la evidencia de SAST:
- ¿Los resultados de los análisis se conservan conforme a una política de retención definida?
- ¿La ejecución de los análisis puede rastrearse hasta commits, solicitudes de incorporación de cambios o versiones específicas?
- ¿Los hallazgos se mapean con estándares reconocidos (CWE, OWASP Top 10)?
- ¿Se dispone de datos históricos para el análisis de tendencias y los informes de mejora continua?
6. Propiedad y gobernanza
Confirme que SAST opera bajo una gobernanza definida:
- ¿Existe un responsable definido para la política y la configuración de SAST?
- ¿Las políticas de análisis están bajo control de versiones y se revisan periódicamente?
- ¿Existe visibilidad centralizada en todos los equipos y repositorios?
- ¿Los roles y las responsabilidades están documentados (quién analiza, quién clasifica, quién aprueba las excepciones)?
Tabla de evaluación de controles SAST
La siguiente tabla ofrece una referencia estructurada para los auditores que evalúan los controles SAST:
| Área de evaluación | Evidencia que solicitar | Criterios de aprobación | Indicadores de fallo |
|---|---|---|---|
| Cobertura del análisis | Lista de repositorios analizados frente al total de repositorios activos; informe de cobertura de lenguajes | Más del 90 % de los repositorios activos analizados; todos los lenguajes principales cubiertos | Repositorios significativos excluidos; lenguajes no soportados en la pila de producción |
| Frecuencia del análisis | Registros de la canalización CI/CD; marcas de tiempo de ejecución de los análisis | Los análisis se ejecutan en cada solicitud de incorporación de cambios y antes de cada versión; sin lagunas que superen los umbrales definidos | Solo análisis ad hoc; los análisis no se activan con los cambios de código |
| Puertas de política | Ficheros de configuración de la canalización; definiciones de umbrales de las puertas; registros de despliegue | Los hallazgos críticos y altos bloquean la fusión o el despliegue; las puertas están bajo control de versiones | Sin puertas; los hallazgos son solo consultivos; las puertas pueden eludirse de forma silenciosa |
| Remediación de hallazgos | Registros de seguimiento de incidencias; informes de cumplimiento de los ANS de remediación | Los hallazgos críticos se remedian dentro de los ANS definidos; existe un seguimiento sistemático | Los hallazgos no se rastrean; no hay ANS definidos; gran acumulación de hallazgos críticos sin atender |
| Gestión de excepciones | Registros de supresiones; flujos de aprobación; registros de revisión de excepciones; informes de la proporción de supresiones | Las supresiones requieren justificación y aprobación; tienen vigencia limitada; la proporción se controla | Supresiones masivas sin revisión; sin caducidad; la proporción de supresiones aumenta sin justificación |
| Retención de evidencia | Informes históricos de análisis; política de retención de datos; registros de trazabilidad | Los resultados se conservan conforme a la política; son trazables hasta los commits y las versiones | Sin política de retención; los resultados se sobrescriben; sin vínculo con versiones de código específicas |
| Mapeo con estándares | Informes de clasificación de hallazgos; documentación de mapeo CWE/OWASP | Los hallazgos se mapean con CWE y OWASP; clasificación coherente entre análisis | Solo clasificaciones propietarias; sin mapeo con estándares reconocidos |
| Propiedad y gobernanza | Matriz RACI; documentos de política SAST; definiciones de roles; registros de revisión | Propiedad clara; políticas bajo control de versiones y revisadas periódicamente | Sin propiedad definida; configuración ad hoc; sin documentación de gobernanza |
Mapeo regulatorio: controles SAST
Los controles SAST se mapean con requisitos de múltiples marcos regulatorios y de cumplimiento:
| Marco | Requisito relevante | Cómo se aplican los controles SAST |
|---|---|---|
| DORA (Ley de Resiliencia Operativa Digital) | Artículo 8: gestión del riesgo de las TIC; Artículo 9: protección y prevención | SAST aporta evidencia de detección proactiva de vulnerabilidades dentro del ciclo de vida de desarrollo. Demuestra que el código se analiza en busca de debilidades de seguridad antes del despliegue, como parte de la gestión del riesgo de las TIC. |
| NIS2 (Directiva de Seguridad de las Redes y de la Información) | Artículo 21: medidas de gestión del riesgo de ciberseguridad | SAST respalda el requisito de gestión de vulnerabilidades y prácticas de desarrollo seguro. Demuestra una detección sistemática de vulnerabilidades a nivel de código como parte de la gestión del riesgo. |
| ISO 27001:2022 | Anexo A 8.25: ciclo de vida de desarrollo seguro; A 8.28: codificación segura | SAST es un control central dentro del ciclo de vida de desarrollo seguro y respalda directamente los requisitos de codificación segura. Aporta evidencia de la revisión sistemática del código en busca de debilidades de seguridad. |
| SOC 2 (Tipo II) | CC7.1: detección de cambios; CC8.1: gestión de cambios | SAST aporta evidencia de que los cambios de código se analizan en busca de vulnerabilidades de seguridad antes del despliegue. Respalda la detección de cambios de código inseguros dentro del proceso de gestión de cambios. |
| PCI DSS 4.0 | Requisito 6.3: se identifican y abordan las vulnerabilidades de seguridad; 6.5: se gestionan los cambios | SAST satisface el requisito de identificar vulnerabilidades de seguridad en el código personalizado. Demuestra que el código se revisa en busca de vulnerabilidades como parte del proceso de desarrollo. |
Métricas clave que los auditores deben solicitar
Al evaluar la eficacia de los controles SAST, los auditores deben solicitar las siguientes métricas y valorarlas en su contexto:
| Métrica | Qué mide | Qué buscar | Señales de alerta |
|---|---|---|---|
| Tasa de cobertura del análisis | Porcentaje de repositorios activos analizados con regularidad | De forma constante por encima del 90 %; los nuevos repositorios se incorporan automáticamente | Por debajo del 80 %; tendencia decreciente; incorporación solo manual |
| Cumplimiento del ANS de remediación de hallazgos críticos | Porcentaje de hallazgos críticos remediados dentro del ANS definido | Cumplimiento superior al 95 %; escalado claro para los ANS incumplidos | Por debajo del 80 %; sin ANS definido; sin proceso de escalado |
| Proporción de supresiones | Porcentaje del total de hallazgos que se suprimen o se marcan como aceptados | Estable o decreciente; cada supresión justificada de forma individual | Tendencia creciente; supresiones masivas; la proporción supera el 20 % sin justificación clara |
| Tendencia de la tasa de falsos positivos | Cómo cambia la tasa de falsos positivos a lo largo del tiempo a medida que se ajustan las reglas | Tendencia decreciente; evidencia de ajuste activo de reglas y de ciclos de retroalimentación | Estable o creciente; sin ajustes; los desarrolladores desconfían de los resultados |
| Tiempo medio de remediación (MTTR) | Tiempo medio desde la detección de un hallazgo hasta su remediación verificada | Dentro de los umbrales de los ANS definidos; con tendencia decreciente | Superando los ANS; sin seguimiento; hallazgos abiertos durante periodos prolongados |
| Tasa de aplicación de las puertas | Porcentaje de despliegues que pasaron por las puertas SAST frente a los que las eludieron | Aplicación superior al 98 %; las elusiones son escasas, se registran y se aprueban | Elusiones frecuentes; sin registro; las elusiones no se revisan |
Hallazgos habituales en las auditorías de SAST
A partir de los patrones observados en entornos regulados, las siguientes deficiencias de los controles SAST se identifican con frecuencia durante las auditorías:
1. Cobertura incompleta del código
Las organizaciones analizan un subconjunto de repositorios —normalmente los incorporados durante el despliegue inicial—, mientras que los repositorios más nuevos, los microservicios o los repositorios que utilizan lenguajes no soportados quedan excluidos. Sin incorporación automatizada, la cobertura se degrada a medida que el código crece.
2. SAST se ejecuta pero no bloquea
Los análisis se ejecutan en las canalizaciones, pero los resultados son solo informativos. Los hallazgos críticos no bloquean las fusiones ni los despliegues, lo que convierte a SAST en un ejercicio de generación de informes y no en un control preventivo. Esta es una de las deficiencias de diseño de control más significativas.
3. Prácticas de supresión sin gobernanza
Los desarrolladores suprimen hallazgos directamente en el código o la configuración sin justificación documentada, aprobación ni caducidad. Con el tiempo, la proporción de supresiones crece y la organización pierde visibilidad sobre el riesgo real del código. En algunos casos, las supresiones se utilizan para eludir las puertas por completo.
4. Sin seguimiento de la remediación
Los hallazgos se comunican, pero no se derivan de forma sistemática a los sistemas de seguimiento de incidencias. No hay evidencia de que los hallazgos se clasificaran, asignaran, priorizaran o resolvieran dentro de plazos definidos. Esto hace imposible demostrar la eficacia operativa del control.
5. Sin retención de evidencia
Los resultados de los análisis se sobrescriben con cada ejecución de la canalización y no se conservan datos históricos. Cuando los auditores solicitan evidencia de la actividad de SAST durante el periodo de auditoría, la organización no puede aportarla. Esta es una brecha de evidencia fundamental.
6. Política incoherente entre equipos
Distintos equipos de desarrollo utilizan diferentes configuraciones de SAST, umbrales de gravedad o frecuencias de análisis. La ausencia de una política centralizada implica que los resultados de la auditoría varían según el equipo que se revise, y la organización no puede demostrar una aplicación coherente del control.
7. Sin ciclo de retroalimentación para el ajuste de reglas
La herramienta SAST produce una tasa elevada de falsos positivos, pero no existe ningún proceso para ajustar las reglas a partir de la retroalimentación de los desarrolladores. Esto erosiona la confianza, aumenta las supresiones y, en última instancia, lleva a que los desarrolladores se desvinculen de la herramienta, socavando la eficacia del control.
Cómo revisan realmente los auditores los controles SAST
Las deficiencias anteriores no se descubren por casualidad. Salen a la luz porque los auditores siguen un proceso de revisión repetible, y a menudo existe una brecha considerable entre cómo creen los equipos de seguridad que funciona esa revisión y cómo se lleva a cabo en realidad. En los entornos regulados, los auditores no evalúan SAST como un producto de seguridad, sino como un control operativo dentro del ciclo de vida de entrega de software. Comprender la secuencia que siguen es la forma más fiable de anticipar los hallazgos antes de que se planteen.
El punto de partida del auditor: SAST es un control, no una herramienta
Los auditores rara vez comienzan con «¿Qué herramienta SAST utilizan?». Parten de una pregunta más exigente:
«¿Cómo evitan que se publique código inseguro y cómo pueden demostrarlo?»
Desde la perspectiva de la auditoría, SAST se evalúa como un control preventivo, integrado en las canalizaciones CI/CD, que opera de forma coherente a lo largo del tiempo y está respaldado por gobernanza y evidencia. El proveedor concreto importa mucho menos que la forma en que el control opera en la práctica.
Paso 1: alcance y definición del control
Los auditores buscan primero entender qué se supone que debe lograr el control SAST. Normalmente preguntan:
- ¿Qué aplicaciones están dentro del alcance?
- ¿En qué etapas se ejecuta SAST?
- ¿Qué riesgos aborda SAST?
- ¿Qué riesgos quedan explícitamente fuera del alcance?
Si la organización no puede articular con claridad el objetivo del control, SAST ya se considera débil. Una señal de alerta habitual es una respuesta vaga del tipo «ejecutamos SAST en la mayoría de los proyectos».
Paso 2: exigibilidad en las canalizaciones CI/CD
A continuación, los auditores examinan cómo se exige SAST, preguntando si se ejecuta automáticamente en CI/CD, si puede bloquear una compilación o un despliegue y si los umbrales se definen y se aplican de forma coherente. Desde la perspectiva de la auditoría, un análisis SAST que se ejecuta pero no exige nada es una actividad de detección, no un control preventivo, y los controles preventivos tienen más peso en las evaluaciones de riesgo. Para confirmar la exigibilidad, los auditores suelen solicitar ver:
- las definiciones de la canalización,
- los registros de los trabajos,
- evidencia de compilaciones fallidas debido a hallazgos de SAST.
Paso 3: gobernanza y segregación de funciones
Después, los auditores evalúan quién controla SAST: quién puede cambiar reglas o políticas, quién puede suprimir hallazgos y si los desarrolladores pueden anular controles sin supervisión. Las preguntas típicas incluyen si los cambios de política se aprueban, si las supresiones están justificadas y tienen vigencia limitada, y si existe segregación entre los roles de desarrollo y de seguridad. Los cambios de reglas sin control o las supresiones permanentes se consideran elusiones del control, no flexibilidad operativa.
Paso 4: calidad y trazabilidad de la evidencia
La evidencia es central para los resultados de la auditoría. Los auditores esperan que la evidencia de SAST tenga marca de tiempo, sea atribuible a una ejecución concreta de la canalización, esté vinculada a un commit o una versión, y se conserve conforme a la política. Los paneles por sí solos son insuficientes; los auditores suelen pedir resultados de análisis exportados, informes históricos y una correlación demostrable entre los hallazgos y las acciones de remediación. Si la evidencia no puede reproducirse ni verificarse de forma independiente, se considera poco fiable.
Paso 5: tratamiento de las excepciones y los falsos positivos
Los falsos positivos no son un fallo; los falsos positivos no gestionados sí lo son. Los auditores examinan cómo se identifican los falsos positivos, quién aprueba las supresiones, cuánto tiempo permanecen válidas y si se revisan periódicamente. Un hallazgo de auditoría recurrente capta el problema con precisión:
«Los hallazgos de SAST se suprimen sin justificación documentada ni revisión.»
Esta única debilidad socava la credibilidad de todo el control.
Paso 6: coherencia a lo largo del tiempo
A los auditores les interesa menos un único análisis «bueno» que la coherencia del control. Evalúan si SAST se ejecuta en cada canalización relevante, si las políticas se aplican de manera uniforme y si la exigibilidad se ha desactivado alguna vez durante periodos críticos de entrega. Las lagunas de evidencia —como la ausencia de análisis durante las fases de máxima actividad de publicación— generan dudas sobre la fiabilidad del control, incluso cuando la herramienta está por lo demás bien configurada.
Paso 7: integración con el SDLC seguro
Por último, los auditores evalúan SAST en su contexto. Comprueban si forma parte de un SDLC seguro más amplio, si los hallazgos influyen en las decisiones de riesgo y si los resultados de SAST se correlacionan con otros controles, como el análisis de composición de software, DAST y la protección en tiempo de ejecución. SAST de forma aislada se considera débil; SAST integrado en un SDLC gobernado se considera eficaz.
En qué rara vez se centran los auditores
Contrariamente a lo que suele suponerse, los auditores normalmente no se concentran en el recuento exacto de vulnerabilidades, la complejidad avanzada de las reglas, los complementos para el IDE o las afirmaciones de marketing del proveedor. Les importa la fiabilidad del control, no la sofisticación de las funciones, y por eso las organizaciones que invierten mucho en herramientas y poco en gobernanza tan a menudo se sorprenden con los resultados de su auditoría.
Cómo prepararse para una revisión de auditoría de SAST
Las organizaciones que superan las auditorías de SAST suelen documentar con claridad los objetivos del control, aplicar las políticas automáticamente en CI/CD, restringir las capacidades de anulación, conservar la evidencia de forma centralizada y revisar las excepciones periódicamente. La preparación es operativa, no cosmética: el objetivo es demostrar que la organización puede evitar de forma fiable que el código inseguro llegue a producción, y probarlo a lo largo de todo el periodo de auditoría.
Lista de verificación de la gobernanza
Los auditores que revisan los controles SAST deben verificar lo siguiente:
- Existe una política SAST aprobada que define el alcance, la frecuencia, los umbrales y la propiedad
- La cobertura del análisis incluye todos los repositorios y lenguajes dentro del alcance
- Los análisis están automatizados e integrados en las canalizaciones CI/CD
- Las puertas de política imponen las decisiones de despliegue en función de la gravedad de los hallazgos
- Los hallazgos se rastrean hasta su remediación o hasta una aceptación de riesgo documentada
- Las supresiones están gobernadas, justificadas, aprobadas, con vigencia limitada y controladas
- La evidencia se conserva con trazabilidad hasta commits y versiones específicas
- Los roles y las responsabilidades están claramente definidos (análisis, clasificación, aprobación de excepciones)
- Las métricas clave (cobertura, cumplimiento de ANS, proporción de supresiones, tendencia de falsos positivos) se comunican con regularidad
Conclusión
Evaluar los controles SAST en entornos regulados exige que los auditores vayan más allá de comprobar si una herramienta está instalada. El foco debe estar en si SAST se aplica de forma coherente en todo el código, si los hallazgos se exigen y se remedian, si las excepciones están gobernadas y si la evidencia se conserva y es trazable.
En los entornos regulados, SAST no consiste en encontrar errores, sino en demostrar que la organización identifica, gestiona y remedia de forma sistemática las debilidades de seguridad a nivel de código como parte de un control exigible y evidenciado.
Las organizaciones que lo consiguen están mucho mejor posicionadas para satisfacer los requisitos regulatorios de DORA, NIS2, ISO 27001, SOC 2 y PCI DSS.
Contenido relacionado
- Mejores herramientas SAST para canalizaciones CI/CD empresariales (edición 2026)
- Matriz de evaluación de RFP para herramientas SAST
- Gobernanza de herramientas SAST: lista de selección, RFP y qué deben verificar los auditores
Preguntas frecuentes: auditoría de los controles SAST
¿Qué deben evaluar primero los auditores al valorar los controles SAST?
Empiece por la cobertura y la exigibilidad. Verifique que el análisis SAST cubre el código de la organización y que los hallazgos críticos bloquean el despliegue mediante puertas de política definidas.
¿Cuál es la deficiencia de control SAST más habitual en las auditorías?
La deficiencia más habitual es que SAST se ejecute solo en modo consultivo: los análisis se ejecutan, pero los hallazgos no bloquean los despliegues, lo que hace que el control sea ineficaz como medida preventiva.
¿Qué marcos regulatorios exigen SAST o análisis estático de código?
DORA, NIS2, ISO 27001, SOC 2 y PCI DSS incluyen requisitos que se mapean con las prácticas de desarrollo seguro y la detección de vulnerabilidades a nivel de código. SAST aporta evidencia directa del cumplimiento de estos requisitos.
