Las pruebas estáticas de seguridad de aplicaciones (SAST) constituyen un control fundamental en la entrega segura de software. Sin embargo, la mera presencia de una herramienta SAST no equivale a un control eficaz. Los auditores, los responsables de cumplimiento y los reguladores deben evaluar si la gobernanza de la herramienta SAST de la organización —desde la selección hasta la operación continua— cumple los estándares exigidos por marcos como DORA, NIS2 e ISO 27001.
Esta guía ofrece un marco de verificación estructurado para evaluar la gobernanza de las herramientas SAST en entornos empresariales y regulados.
Lista de verificación del auditor: proceso de selección de la herramienta
Antes de evaluar las capacidades de la herramienta, los auditores deben verificar que la organización siguió un proceso de selección gobernado.
- ¿Cuenta la organización con un proceso de selección de herramientas documentado para las herramientas de seguridad?
- ¿Se ponderaron adecuadamente los criterios de gobernanza (auditabilidad, generación de evidencia, aplicación de políticas) durante la evaluación?
- ¿Se evaluaron varias herramientas frente a un conjunto coherente de requisitos?
- ¿Existe una justificación documentada de la decisión final de selección?
- ¿Fue aprobado el proceso de selección por las partes interesadas apropiadas (seguridad, ingeniería, cumplimiento)?
- ¿Existe evidencia de una revisión continua de la eficacia de la herramienta?
Lista de verificación de auditoría para la selección de la herramienta
Los puntos de verificación anteriores describen qué debe cubrir un proceso de selección gobernado. La lista siguiente los convierte en un instrumento de evaluación concreto y listo para la auditoría: veintiocho preguntas agrupadas por área de control que un auditor o un panel de evaluación puede aplicar directamente al valorar una herramienta de pruebas estáticas de seguridad de aplicaciones (SAST) para entornos CI/CD empresariales y regulados. Cada pregunta se responde con sí o no, y cualquier brecha material debe documentarse y aceptarse como riesgo mediante un proceso formal.
| # | Área de control | Pregunta de auditoría | Sí | No |
|---|---|---|---|---|
| 1 | Gobernanza | ¿La herramienta admite la aplicación basada en políticas (bloquear / advertir / solo informar)? | ☐ | ☐ |
| 2 | Gobernanza | ¿Pueden definirse políticas por aplicación, equipo o entorno? | ☐ | ☐ |
| 3 | Gobernanza | ¿Las políticas de seguridad están versionadas y son auditables? | ☐ | ☐ |
| 4 | Gobernanza | ¿Pueden personalizarse las reglas (gravedad, alcance, exclusiones)? | ☐ | ☐ |
| 5 | Integración CI/CD | ¿La herramienta se integra de forma nativa con las plataformas CI/CD empresariales? | ☐ | ☐ |
| 6 | Integración CI/CD | ¿Pueden ejecutarse los análisis automáticamente en las PR / fusiones / canalizaciones? | ☐ | ☐ |
| 7 | Integración CI/CD | ¿Puede bloquearse la canalización en función de condiciones de política? | ☐ | ☐ |
| 8 | Integración CI/CD | ¿Los resultados son accesibles mediante API o exportación (JSON, CSV, etc.)? | ☐ | ☐ |
| 9 | Experiencia del desarrollador | ¿Los hallazgos se mapean con claridad a las ubicaciones del código fuente? | ☐ | ☐ |
| 10 | Experiencia del desarrollador | ¿Se ofrece orientación de remediación para los hallazgos? | ☐ | ☐ |
| 11 | Experiencia del desarrollador | ¿Pueden suprimirse los falsos positivos con justificación? | ☐ | ☐ |
| 12 | Precisión | ¿La lógica de detección es explicable (no solo una caja negra)? | ☐ | ☐ |
| 13 | Precisión | ¿La tasa de falsos positivos es aceptable en código real? | ☐ | ☐ |
| 14 | Cobertura | ¿La herramienta cubre todos los lenguajes de producción dentro del alcance? | ☐ | ☐ |
| 15 | Cobertura | ¿Los conjuntos de reglas se mantienen y actualizan de forma activa? | ☐ | ☐ |
| 16 | Rendimiento | ¿Los tiempos de análisis son compatibles con las restricciones de ejecución de CI/CD? | ☐ | ☐ |
| 17 | Rendimiento | ¿La herramienta escala en muchos repositorios / equipos? | ☐ | ☐ |
| 18 | Informes | ¿La herramienta ofrece tendencias históricas y antigüedad de las vulnerabilidades? | ☐ | ☐ |
| 19 | Informes | ¿Pueden generarse informes con fines de auditoría (no solo paneles)? | ☐ | ☐ |
| 20 | Evidencia | ¿Los hallazgos tienen marca de tiempo y son atribuibles a una ejecución de la canalización? | ☐ | ☐ |
| 21 | Evidencia | ¿Puede conservarse la evidencia conforme a políticas de retención definidas? | ☐ | ☐ |
| 22 | Cumplimiento | ¿La herramienta mapea los hallazgos con CWE / OWASP Top 10? | ☐ | ☐ |
| 23 | Cumplimiento | ¿Los resultados pueden respaldar auditorías de ISO 27001 / SOC 2 / DORA / NIS2? | ☐ | ☐ |
| 24 | Operaciones | ¿Se admite la administración centralizada? | ☐ | ☐ |
| 25 | Operaciones | ¿La carga operativa es aceptable a escala empresarial? | ☐ | ☐ |
| 26 | Proveedor | ¿Existe una hoja de ruta clara de soporte y actualizaciones? | ☐ | ☐ |
| 27 | Estrategia | ¿Puede la herramienta evolucionar de la mera visibilidad a un control exigible? | ☐ | ☐ |
| 28 | Estrategia | ¿La herramienta encaja en el modelo de SDLC seguro de la organización? | ☐ | ☐ |
Resumen del resultado de la auditoría
Una vez completada la lista de verificación, las respuestas individuales deben consolidarse en un pequeño número de áreas de decisión que un panel de selección pueda aprobar.
| Área de decisión | Valoración |
|---|---|
| Preparación de la gobernanza | ☐ Aprobado ☐ Condicional ☐ Rechazado |
| Idoneidad para CI/CD | ☐ Aprobado ☐ Condicional ☐ Rechazado |
| Riesgo de adopción por parte de los desarrolladores | ☐ Bajo ☐ Medio ☐ Alto |
| Preparación para la auditoría | ☐ Adecuada ☐ Parcial ☐ Insuficiente |
| Decisión general | ☐ Aprobado ☐ Aprobado con condiciones ☐ Rechazado |
Orientación para el auditor
Una herramienta SAST no debe aprobarse para CI/CD empresarial si:
- las políticas no pueden aplicarse automáticamente,
- los resultados no pueden exportarse como evidencia de auditoría,
- o los desarrolladores eluden sistemáticamente la herramienta.
1. Gobernanza y aplicación de políticas
Los auditores deben verificar que la herramienta SAST aplica las políticas de seguridad de forma coherente y que la configuración de las políticas está gobernada.
Puntos de verificación
- Verifique que la herramienta admite la aplicación basada en políticas (modos de bloqueo, advertencia o solo informe)
- Confirme que las políticas pueden definirse y diferenciarse por aplicación, equipo, entorno o perfil de riesgo
- Evalúe si la configuración de las políticas está versionada y es auditable: los cambios en las políticas deben ser trazables
- Verifique que la personalización de reglas (gravedad, alcance, exclusiones) está gobernada y documentada
- Confirme que la organización dispone de una vía que va de la mera visibilidad a la aplicación de puertas exigibles
Pregunta del auditor: ¿Puede la organización demostrar quién cambió las políticas SAST, cuándo y por qué?
2. Gobernanza de la integración CI/CD
Los auditores deben verificar que la herramienta SAST está integrada en la canalización de entrega de software como un control automatizado y exigible.
Puntos de verificación
- Verifique que los análisis SAST se ejecutan automáticamente en las solicitudes de incorporación de cambios, las fusiones a la rama principal y a intervalos programados
- Confirme que las condiciones de fallo de la canalización están definidas y se aplican en función de la política
- Evalúe si la herramienta opera a escala en todos los repositorios dentro del alcance sin intervención manual
- Verifique que los resultados de los análisis son accesibles mediante API o exportación estructurada para su agregación y revisión
- Confirme que la integración de SAST está monitorizada: los fallos y las lagunas en la ejecución se detectan y se escalan
Pregunta del auditor: ¿Puede la organización demostrar que SAST se ejecuta en cada ejecución relevante de la canalización y que las lagunas se detectan?
3. Gestión de hallazgos y calidad de la señal
La gobernanza de cómo se clasifican, suprimen y resuelven los hallazgos es tan importante como la capacidad de detección de la herramienta.
Puntos de verificación
- Verifique que los hallazgos se mapean con claridad a las ubicaciones del código e incluyen orientación de remediación accionable
- Confirme que la supresión de falsos positivos requiere justificación y aprobación
- Evalúe si las decisiones de aceptación de riesgo están documentadas con la autorización apropiada
- Verifique que la lógica de detección respalda estándares reconocidos (mapeos con CWE, OWASP)
- Confirme que el historial de supresiones y reclasificaciones se conserva y es auditable
Pregunta del auditor: ¿Puede la organización producir un rastro de auditoría completo de cualquier hallazgo suprimido o aceptado?
4. Gobernanza de la cobertura y el alcance
Los auditores deben verificar que la cobertura de SAST se alinea con el porfolio de aplicaciones y el perfil de riesgo de la organización.
Puntos de verificación
- Verifique que la herramienta cubre todos los lenguajes y marcos de producción dentro del alcance
- Evalúe si la profundidad del análisis es coherente entre lenguajes: no superficial para algunos y profunda para otros
- Confirme que los conjuntos de reglas se mantienen y actualizan de forma activa
- Verifique que las lagunas de cobertura se identifican, documentan y aceptan mediante un proceso formal de riesgo
Pregunta del auditor: ¿Puede la organización demostrar qué aplicaciones están cubiertas por SAST y cuáles no, y por qué?
5. Informes, evidencia y preparación para la auditoría
La generación de evidencia es un área de enfoque principal de la auditoría. Los auditores deben verificar que la herramienta SAST y los procesos que la rodean producen evidencia fiable y resistente a la manipulación.
Puntos de verificación
- Verifique que la herramienta ofrece análisis de tendencias históricas: antigüedad de las vulnerabilidades, seguimiento de la remediación e infracciones de política a lo largo del tiempo
- Confirme que los informes están listos para la auditoría: con marca de tiempo, atribuibles y reproducibles
- Evalúe si las políticas de retención están configuradas y alineadas con los requisitos regulatorios
- Verifique que la evidencia es exportable en formatos adecuados para la revisión regulatoria
- Confirme que la integridad de la evidencia está protegida: los resultados no pueden manipularse ni eliminarse sin que se detecte
Pregunta del auditor: ¿Puede la organización producir evidencia de SAST para cualquier versión dada, rastreando los hallazgos hasta el commit y la ejecución de la canalización específicos?
Ciclo de vida de la gobernanza de la herramienta
Los auditores deben evaluar si la organización gestiona las herramientas SAST como una capacidad gobernada con un ciclo de vida definido, y no como una decisión de compra puntual.
Las cinco etapas de la gobernanza de la herramienta:
- Selección: ¿Se seleccionó la herramienta mediante un proceso de evaluación formal y documentado con criterios de gobernanza?
- Despliegue: ¿Se desplegó la herramienta de forma coherente en todas las aplicaciones y canalizaciones dentro del alcance?
- Operación: ¿La herramienta se monitoriza, mantiene y produce resultados fiables de forma activa?
- Revisión: ¿Existe una revisión periódica de la eficacia, la cobertura y la idoneidad de la herramienta?
- Sustitución: ¿Existe un proceso definido para sustituir o retirar las herramientas que ya no cumplen los requisitos?
Cada etapa debe producir evidencia auditable. La ausencia de cualquier etapa indica una brecha de gobernanza.
Por qué fracasan la mayoría de los RFP de SAST
Las solicitudes de propuestas (RFP) son el mecanismo más habitual que utilizan las grandes organizaciones para seleccionar una herramienta SAST; sin embargo, en los entornos regulados muchos RFP de SAST fracasan, no en el momento de la compra, sino meses después, durante auditorías, incidentes o la realidad operativa. La causa rara vez es únicamente una mala elección de herramienta; suele ser un conjunto de defectos estructurales en cómo se definen, evalúan y validan los requisitos de SAST. Los siete patrones de fracaso que se describen a continuación son los que los auditores observan con más frecuencia, seguidos de lo que hacen de forma distinta las organizaciones disciplinadas.
Fracaso n.º 1: tratar SAST como una comparación de funciones
Muchos RFP se centran en gran medida en:
- el número de lenguajes soportados,
- las afirmaciones sobre detección de vulnerabilidades,
- los indicadores de velocidad de análisis,
- las integraciones con el IDE.
Aunque estos aspectos son relevantes, no son decisivos en los entornos regulados.
Los auditores no preguntan:
“¿Cuántas vulnerabilidades detecta su herramienta SAST?”
Preguntan:
“¿Cómo aplican las políticas de codificación segura y cómo lo demuestran a lo largo del tiempo?”
Cuando un RFP prioriza las listas de funciones por encima de la gobernanza y la aplicación, la herramienta seleccionada a menudo no cumple las expectativas regulatorias.
Fracaso n.º 2: ignorar la realidad de la aplicación en CI/CD
Un requisito frecuente en los RFP es:
“La herramienta debe integrarse con CI/CD.”
En la práctica, esto se interpreta de forma demasiado laxa.
Lo que importa no es la integración, sino la aplicación:
- ¿Puede la herramienta bloquear una canalización?
- ¿Puede aplicar automáticamente los umbrales de política?
- ¿Pueden controlarse y auditarse las excepciones?
Los RFP que no ponen a prueba explícitamente el comportamiento de interrupción de la compilación seleccionan herramientas que se ejecutan de forma pasiva, generan informes y acaban por ser ignoradas.
En los entornos regulados, un control de seguridad que no puede aplicar nada no es un control.
Fracaso n.º 3: subestimar la gobernanza y la segregación de funciones
Muchos RFP de SAST asumen que:
- los desarrolladores configuran las reglas,
- seguridad revisa los resultados,
- los auditores consumen los informes.
Sin mecanismos de gobernanza claros, este modelo se derrumba.
Las brechas de gobernanza habituales incluyen:
- ninguna separación de roles entre desarrolladores y seguridad,
- cambios de reglas sin aprobación ni trazabilidad,
- hallazgos suprimidos sin justificación.
Los auditores identifican rápidamente estas debilidades y concluyen que los controles SAST no son fiables.
Fracaso n.º 4: confundir los paneles con evidencia de auditoría
Las plataformas SAST modernas ofrecen paneles atractivos:
- puntuaciones de riesgo,
- tendencias,
- gráficos.
Sin embargo, los paneles no son evidencia de auditoría.
Los auditores requieren:
- resultados con marca de tiempo,
- trazabilidad hasta ejecuciones específicas de la canalización,
- vinculación con commits, aprobaciones y excepciones,
- retención histórica.
Los RFP que no exigen explícitamente evidencia exportable e inmutable conducen a herramientas que lucen bien internamente pero fallan bajo el escrutinio de una auditoría.
Fracaso n.º 5: pasar por alto la gobernanza de los falsos positivos
Los falsos positivos son inevitables en SAST.
El fallo se produce cuando los RFP no abordan:
- cómo se suprimen los falsos positivos,
- quién aprueba las supresiones,
- cuánto tiempo permanecen válidas las supresiones,
- si las supresiones son auditables.
En los entornos regulados, las supresiones no gestionadas se consideran elusiones del control.
Los RFP que ignoran este aspecto seleccionan herramientas que socavan la confianza en lugar de reforzarla.
Fracaso n.º 6: asumir que una sola herramienta resuelve todo el SDLC
Algunos RFP esperan implícitamente que SAST:
- asegure el comportamiento en tiempo de ejecución,
- detecte configuraciones incorrectas,
- prevenga los ataques a la cadena de suministro.
Esto no es realista.
Cuando SAST se vende en exceso como una solución de seguridad completa, las organizaciones:
- definen mal el alcance de los controles,
- dependen en exceso del análisis estático,
- no lo complementan con DAST, SCA o controles en tiempo de ejecución.
Los auditores interpretan esto como una comprensión deficiente del riesgo, no como seguridad avanzada.
Fracaso n.º 7: no validar la evidencia durante la PoC
Muchos RFP incluyen una prueba de concepto (PoC), pero:
- se centran únicamente en la precisión de la detección,
- ignoran la generación de evidencia en la canalización,
- no ponen a prueba escenarios de auditoría.
Una PoC adecuada en entornos regulados debería validar:
- la aplicación de políticas en CI/CD,
- los flujos de trabajo de excepciones,
- la exportación y la retención de evidencia.
Omitir este paso garantiza un fracaso en las etapas finales.
Qué hacen de forma distinta los RFP de SAST que tienen éxito
Las organizaciones que tienen éxito diseñan los RFP de SAST en torno a controles, no herramientas.
Exigen explícitamente:
- aplicación basada en políticas en CI/CD,
- gobernanza basada en roles y segregación de funciones,
- flujos de trabajo de excepciones auditables,
- evidencia exportable y conservada,
- alineación con el SDLC seguro y los objetivos de cumplimiento.
Lo más importante es que aceptan que ninguna herramienta SAST por sí sola garantiza el cumplimiento.
Un mejor planteamiento para los RFP de SAST
En lugar de preguntar:
“¿Cuál es la mejor herramienta SAST?”
Pregunte:
“¿Qué solución SAST puede operarse como un control CI/CD regulado?”
Este cambio de planteamiento mejora drásticamente los resultados.
Señales de alerta para los auditores
Los siguientes indicadores deberían generar preocupación durante una auditoría de la gobernanza de la herramienta SAST:
- Sin proceso de selección de herramientas documentado: la herramienta se adoptó sin una evaluación o comparación formal
- Sin criterios de gobernanza en la selección: la evaluación se centró únicamente en las funciones técnicas, sin considerar la auditabilidad, la generación de evidencia ni la aplicación de políticas
- Sin revisión periódica de la eficacia: la herramienta no se ha reevaluado desde su despliegue inicial
- Análisis ejecutados de forma manual o incoherente: SAST no está integrado en la canalización CI/CD como un control automatizado
- Sin retención de evidencia: los resultados de los análisis y los registros no se conservan con fines de auditoría
- Supresión incontrolada de hallazgos: los desarrolladores pueden suprimir vulnerabilidades sin supervisión de gobernanza ni justificación documentada
- Herramienta desactivada o eludida en silencio: las configuraciones de la canalización permiten omitir SAST sin aprobación
- Políticas no versionadas: los cambios en las reglas y las políticas de SAST no se rastrean ni son atribuibles
Alineación regulatoria
La gobernanza de la herramienta SAST se mapea directamente con los requisitos de los principales marcos regulatorios. Los auditores deben evaluar la alineación con los siguientes:
DORA (Ley de Resiliencia Operativa Digital)
- El artículo 9 exige marcos de gestión del riesgo de las TIC que incluyan pruebas de los sistemas TIC: SAST es un control primario para las pruebas a nivel de código
- Exige una aplicación de las pruebas proporcionada y basada en el riesgo: los auditores deben verificar que la cobertura de SAST se alinea con la criticidad
- Obliga a disponer de evidencia documentada de las actividades y los resultados de las pruebas
NIS2 (Directiva de Seguridad de las Redes y de la Información)
- Exige que las organizaciones implementen medidas de seguridad en la cadena de suministro y en los procesos de desarrollo
- La gobernanza de la herramienta SAST demuestra un enfoque proactivo del desarrollo seguro
- La evidencia de pruebas de seguridad continuas respalda el cumplimiento de las obligaciones de gestión del riesgo
ISO 27001
- Control A.8.25 del Anexo A (Ciclo de vida de desarrollo seguro): SAST es un control técnico clave
- Control A.8.29 del Anexo A (Pruebas de seguridad en el desarrollo y la aceptación): exige evidencia de pruebas de seguridad a lo largo del SDLC
- Exige procesos documentados, evidencia del funcionamiento del control y revisión periódica
Conclusión
Auditar la gobernanza de la herramienta SAST requiere ir más allá de comprobar si una herramienta está instalada. Los auditores deben evaluar todo el ciclo de vida de la gobernanza —desde la selección hasta la operación y la revisión continuas— y verificar que la organización produce la evidencia necesaria para demostrar la eficacia del control.
Las organizaciones que tratan la selección de la herramienta SAST como una decisión de compra puntual, en lugar de como una responsabilidad de gobernanza continua, probablemente tendrán brechas en la cobertura, la evidencia y la aplicación que las exponen a riesgos regulatorios y de seguridad.
Preguntas frecuentes: gobernanza de las herramientas SAST
¿Qué deben verificar primero los auditores al evaluar la gobernanza de la herramienta SAST?
Empiece por el proceso de selección de la herramienta. Verifique que tuvo lugar una evaluación documentada, que se incluyeron criterios de gobernanza (auditabilidad, generación de evidencia, aplicación de políticas) y que la decisión fue aprobada por las partes interesadas apropiadas.
¿Cómo se relaciona la gobernanza de la herramienta SAST con el cumplimiento de DORA y NIS2?
DORA exige evidencia documentada de las pruebas de los sistemas TIC, incluidos los controles a nivel de código. NIS2 exige medidas de seguridad en los procesos de desarrollo. Una herramienta SAST gobernada —con evidencia de ejecución coherente, aplicación de políticas y revisión periódica— respalda directamente el cumplimiento de ambos marcos.
¿Cuál es la brecha de gobernanza más habitual en la gestión de la herramienta SAST?
La ausencia de una revisión periódica de la eficacia. Muchas organizaciones despliegan una herramienta SAST y nunca reevalúan si sigue cumpliendo sus requisitos de seguridad, cumplimiento y operativos, lo que crea una brecha entre la existencia del control y su eficacia real.
Contenido relacionado
- SAST en entornos regulados: guía del auditor para evaluar los controles SAST
- Matriz de evaluación de RFP
- Mejores herramientas SAST para canalizaciones CI/CD empresariales (edición 2026)
