Evidencias SAST y DAST para PUI 2026: Guía Semgrep y ZAP

¿Qué son SAST, DAST y SCA en el contexto PUI?

Las evidencias SAST y DAST para PUI son tres tipos de análisis de seguridad de software exigidos por la Plataforma Única de Identidad (PUI) antes de validar la conexión de cualquier institución (SAST, DAST y SCA). Cada uno examina un aspecto distinto del software que expone los endpoints obligatorios para la búsqueda de personas desaparecidas.

Las evidencias de los tres tipos forman el paquete técnico de ciberseguridad que toda institución debe entregar a la ATDT. Sin reportes limpios (sin vulnerabilidades críticas, altas, medias ni bajas) la conexión no es autorizada y el proceso de aprobación se reinicia.

¿Cuáles son los 4 endpoints PUI que el DAST debe cubrir?

El DAST dentro del paquete SAST y DAST para PUI cubre cuatro endpoints autenticados que la institución expone para que la plataforma del gobierno pueda activar reportes de búsqueda, validar la conexión y desactivar reportes cuando una persona es localizada. Cualquier reporte DAST que no demuestre la ejecución autenticada de estos cuatro endpoints es rechazado.

Las pruebas dinámicas deben ser autenticadas: el escaneo no se ejecuta como anónimo, se realiza con el token JWT obtenido del /login. Las inyecciones (XSS, SQL Injection) deben enfocarse en los campos de entrada de /activar-reporte y /desactivar-reporte, que son los que reciben datos del exterior.

¿Qué herramientas SAST, DAST y SCA son aceptadas?

La ATDT acepta cualquier herramienta que cumpla con los criterios de trazabilidad e inventario de reglas aplicadas. No hay un proveedor obligatorio. En la práctica las opciones más usadas son éstas:

El criterio clave es que el reporte muestre qué reglas se aplicaron, qué archivos fueron analizados y qué resultados se obtuvieron. Una herramienta cara con dashboards bonitos no garantiza una entrega aprobada si no permite extraer esa información.

¿Qué formatos de reporte son aceptados?

El formato preferido para SAST es SARIF (Static Analysis Results Interchange Format) cuando la herramienta lo soporta. Permite ver con detalle las reglas ejecutadas y los hallazgos individuales. Alternativas válidas son JSON y PDF con detalle visible de reglas aplicadas más capturas del escaneo.

Para DAST con OWASP ZAP, los dos archivos obligatorios son:

• Traditional PDF Report: documento legible con secciones Alert Count, Insights, Instance Chart y Alert Details.
• Traditional XML Report with requests and responses: archivo XML que contiene cada petición ejecutada con su respuesta completa, base auditable de la evidencia.

Si se usan herramientas diferentes a ZAP, hay que entregar un conjunto equivalente que muestre los mismos elementos: autenticación, peticiones realizadas, reglas aplicadas y resultados.

¿Qué información general debe incluir cada entrega?

La portada de cada reporte (SAST, DAST, SCA) debe llevar metadatos verificables. Esta información permite a la ATDT trazar la evidencia al código y al ambiente exactos:

• Nombre de la institución y módulo o repositorio analizado.
• Fecha y hora exacta de ejecución de cada escaneo.
• Versión de código (commit hash) y rama del repositorio.
• Herramienta utilizada con su versión específica (ej. Semgrep 1.163.0, ZAP 2.17, Postman 12.12.2).
• Reglas o presets aplicados: security audit, secrets, OWASP Top Ten, OWASP API, entre otros.
• Inventario: número total de archivos revisados y recuento por lenguaje.
• URLs analizadas en el caso del DAST.

Esta información no es opcional. Sin ella el reporte no se considera trazable y vuelve al ciclo de revisión.

¿Cómo preparar el SAST con Semgrep?

Semgrep es la herramienta más usada para SAST y DAST para PUI por su facilidad de exportar reportes en SARIF y su inventario claro de archivos analizados. El estándar técnico contempla dos fases consecutivas que se ejecutan dentro de la carpeta raíz del proyecto:

Fase 1: Escaneo inicial (inventario)

Esta fase genera un reporte JSON con la fecha y hora exactas. Funciona como inventario de archivos analizados y prueba de que el escaneo se ejecutó:

semgrep scan --config auto --json > reporte-semgrep_$(date +%Y-%m-%d_%H_%M_%S).json

Fase 2: Escaneo completo (profundo)

Esta fase aplica el conjunto completo de reglas de seguridad: security-audit, secrets, OWASP Top Ten. El resultado se exporta en formato SARIF detallado:

semgrep scan \
  --config auto \
  --config p/security-audit \
  --config p/secrets \
  --config p/owasp-top-ten \
  --sarif \
  --output full-report_$(date +%Y-%m-%d_%H_%M_%S).sarif

Una observación crítica: OWASP Top 10 por sí solo es insuficiente. Hay que añadir detección de secretos (p/secrets) y, cuando aplique, reglas de API (p/api). Sin esta combinación el reporte se rechaza por cobertura incompleta.

¿Cómo preparar el DAST con OWASP ZAP y Postman?

El DAST para PUI exige que las cuatro URLs autenticadas (/login, /activar-reporte, /desactivar-reporte, /activar-reporte-prueba) se ejerciten con un token JWT válido y se intercepten en ZAP para análisis de vulnerabilidades.

Configuración base

La configuración estándar usa Postman como cliente HTTP y ZAP como proxy interceptor. Ambos deben apuntar al mismo proxy local. En Postman se accede vía File > Settings > Proxy y en ZAP vía Tools > Options > Local Servers/Proxies. La dirección habitual es 127.0.0.1:8080.

Flujo de ejecución

1. Login: ejecutar POST a /login con credenciales. Validar respuesta 200 OK + token JWT.
2. Activar reporte: usar el token JWT como Bearer en headers. Ejecutar POST a /activar-reporte con payload de prueba. Validar 201 Created.
3. Desactivar reporte: con el mismo token, ejecutar POST a /desactivar-reporte. Validar 201 Created.
4. Activar reporte prueba: ejecutar POST a /activar-reporte-prueba. Validar 201 Created.
5. Active Scan: en ZAP, hacer clic derecho sobre la URL principal del sitio cargado y seleccionar Attack > Active Scan. Esperar a que llegue al 100%.
6. Generar reportes: vía Report > Generate Report > Traditional PDF Report. Repetir para Traditional XML Report with requests and responses.

La evidencia visual debe mostrar las peticiones interceptadas, los códigos 200 y 201 en la columna Code, el porcentaje de Active Scan del 1% al 100%, y los reportes finales generados.

¿Qué criterios de aceptación aplica la ATDT?

Una evidencia se considera válida cuando cumple estrictamente cinco criterios. Faltar a cualquiera regresa el reporte al inicio del ciclo de revisión:

1. Alcance correcto: la revisión cubre la totalidad de los archivos o endpoints relacionados con los servicios PUI. Otros componentes del software pueden omitirse.
2. Evidencia visual: capturas que muestren el comando ejecutado, las secciones Scan status y Scan summary completas, y que la imagen sea legible.
3. Entregables digitales: archivos JSON y SARIF (SAST) o PDF y XML (DAST) adjuntos íntegros, no sólo capturas.
4. Reglas aplicadas visibles: en caso de usar herramienta distinta a Semgrep o ZAP, evidencia clara de qué reglas se ejecutaron.
5. Reporte final sin vulnerabilidades: críticas, altas, medias y bajas remediadas. Si hubo hallazgos en escaneos previos hay que documentar que fueron corregidos antes del reenvío.

¿Cómo se entregan las evidencias en proveedores multitenant?

Los proveedores tecnológicos que operan múltiples instituciones bajo la misma base de código tienen un trato diferenciado. La ATDT no exige una entrega SAST por cada cliente: un solo paquete cubre a todos los tenants si la tecnología y el código son homogéneos.

Operadores como KYC PUI ya cuentan con la entrega aprobada multitenant, lo que les permite onboardear nuevas instituciones sin que cada una repita el ciclo completo de auditoría de software.

¿Cuánto tarda la revisión técnica?

El ciclo de revisión de evidencias varía según el volumen de instituciones en cola y la calidad de la entrega. Por experiencia el rango habitual está entre 1 y 2 semanas por reporte. Toda institución que entrega recibe respuesta, positiva o negativa.

Tras la aprobación, el flujo de activación tiene tres pasos consecutivos:

1. Ciberseguridad de la ATDT emite dictamen positivo y notifica a la institución por correo.
2. RENAPO recibe la solicitud de aceptación y la valida formalmente.
3. API operativa: una vez aceptado, los endpoints quedan listos para recibir activaciones y desactivaciones reales de reportes de búsqueda.

Si durante la inscripción cambian datos del webhook (URL de los endpoints), no se modifica la solicitud abierta. Hay que solicitar formalmente el rechazo de la solicitud anterior y reinscribir el nuevo webhook desde cero.

Errores frecuentes que rechazan la entrega

Estos son los motivos más comunes por los que una entrega es regresada al equipo técnico. Conocerlos antes de enviar evita semanas de retraso:

• SonarQube dashboard "passed" sin reglas de seguridad visibles: el screenshot del "pasa" no es evidencia. Hay que mostrar qué reglas de security se ejecutaron.
• Solo OWASP Top 10 en el SAST: insuficiente sin detección de secretos. Añadir p/secrets y, si aplica, reglas de API.
• DAST sin autenticación: si las peticiones no llevan token JWT válido, los endpoints autenticados responden 401 y la prueba no demuestra cobertura.
• Reporte ZAP sin XML: el Traditional PDF Report solo no basta. Hay que incluir también el Traditional XML Report with requests and responses.
• Sin commit hash ni rama: la portada del reporte sin versión de código exacta impide trazabilidad.
• Capturas borrosas o parciales: si el comando ejecutado o las secciones Scan status / Scan summary no se leen, la evidencia visual no es válida.
• Vulnerabilidades pendientes: el reporte final debe estar limpio. Hallazgos pendientes con la nota "se corrigen después" no son aceptados.

Cambios futuros: cómo mantener vigentes las evidencias SAST y DAST para PUI

La aprobación inicial del paquete SAST y DAST para PUI no es permanente. Cualquier cambio significativo en el código o la incorporación de nuevos endpoints requiere repetir las pruebas. Las buenas prácticas para evitar revalidaciones costosas son:

• Integrar SAST, SCA y DAST en el pipeline CI/CD: cada commit pasa por escaneo automático.
• Mantener dependencias actualizadas: el SCA detecta versiones con CVE conocidos y obliga a actualizar.
• Versionar la documentación: cada reporte queda atado a un commit hash, fácil de recuperar para auditorías.
• Revalidación periódica: aunque no haya cambios, la ATDT puede solicitar reescaneos para confirmar que el código sigue limpio.

Preguntas frecuentes sobre evidencias SAST y DAST para PUI

¿Las evidencias SAST y DAST son obligatorias para conectar a la PUI?

Sí. Sin reportes SAST y DAST aprobados por la ATDT, RENAPO no autoriza la conexión. Es un paso técnico obligatorio definido en los lineamientos publicados en el DOF el 27 de noviembre de 2025 y en el Manual Técnico publicado el 23 de enero de 2026.

¿Cuáles son los 4 endpoints DAST obligatorios?

Los cuatro endpoints autenticados que el DAST debe ejercitar dentro del paquete SAST y DAST para PUI son /login, /activar-reporte, /desactivar-reporte y /activar-reporte-prueba. Cada uno requiere petición con token JWT válido y respuesta 200 OK o 201 Created según corresponda.

¿Puedo usar una herramienta distinta a Semgrep o OWASP ZAP?

Sí. La ATDT acepta cualquier herramienta que permita evidenciar reglas aplicadas, inventario de archivos y resultados. Si usa SonarQube, Kimera, Rapid7 u otra, hay que cumplir los mismos criterios de trazabilidad: información general, reportes detallados, capturas claras y reglas de escaneo visibles.

¿OWASP Top 10 cubre la prueba SAST por sí solo?

No. OWASP Top 10 por sí solo es insuficiente. Hay que ampliar con detección de secretos (p/secrets en Semgrep) y, cuando aplique, reglas de API (OWASP API Security Top 10). Se admite combinar presets para cobertura más completa.

¿El reporte "passed" de SonarQube es evidencia válida?

No por sí solo. El dashboard "passed" de SonarQube no demuestra qué reglas de seguridad se ejecutaron. Hay que incluir capturas que muestren las reglas activas y los resultados específicos, no únicamente el indicador de aprobación.

¿Cuánto tarda la ATDT en revisar una entrega?

El ciclo habitual es de 1 a 2 semanas por reporte. Si la entrega tiene errores, regresa al ciclo y se suma otra semana o dos. Por eso conviene preparar bien la primera versión: cada iteración cuesta tiempo de implementación.

Soy proveedor tecnológico multitenant, ¿debo entregar un SAST por cada cliente?

No, siempre que todas las instituciones compartan la misma base de código y tecnología. Un solo SAST cubre a todos los tenants. Para DAST se entrega uno completo y la ATDT puede solicitar un muestreo aleatorio (ej. 5 instituciones) para verificar consistencia.

¿Qué pasa si cambio el webhook durante la inscripción?

No se modifica la solicitud abierta. Hay que solicitar formalmente el rechazo de la solicitud actual y reinscribir el nuevo webhook desde cero. Este flujo agrega tiempo, así que conviene definir bien el endpoint antes de inscribirse.

¿Las evidencias se pueden hacer con un equipo interno o necesito un proveedor externo?

Se aceptan informes de equipos internos (por ejemplo del área de hacking ético de la propia institución) si cumplen los criterios de trazabilidad, reglas, capturas y resultados. No se exige proveedor externo.

¿Las evidencias SAST y DAST cubren toda la solución del proveedor o solo la parte PUI?

Solo la parte PUI. Para la entrega a la ATDT se evidencian los endpoints relacionados con la Plataforma Única de Identidad. El resto de la solución queda fuera del alcance de esta entrega específica, sin perjuicio de otras auditorías generales que la institución mantenga.