El examen AZ-400 evalúa si sabes qué herramienta colocar en qué etapa del pipeline de seguridad. Los pilares clave son las diferencias entre SAST, SCA y DAST; los componentes de GitHub Advanced Security (GHAS); los dos modos de Dependabot; y el papel del conector de Microsoft Defender for DevOps. El principio shift-left — incorporar la seguridad desde el momento en que se escribe el código, no tratarla como una compuerta final — impregna casi todas las preguntas de este dominio.
Categorías de Escaneo de Seguridad — SAST, DAST, SCA, IaC
Imagina el control de seguridad de un aeropuerto. El equipaje documentado pasa por rayos X en el check-in, el equipaje de mano se revisa en la puerta y los auxiliares vigilan la cabina durante el vuelo. Cada punto apunta a una amenaza distinta en una etapa diferente. El escaneo de seguridad en DevSecOps funciona igual: ninguna herramienta lo detecta todo sola.
SAST (Static Application Security Testing): Analiza el código fuente sin ejecutarlo. Detecta SQL Injection, XSS, credenciales incrustadas y vulnerabilidades a nivel de código. Se ejecuta durante el build. CodeQL es el ejemplo principal. DAST (Dynamic Application Security Testing): Envía peticiones HTTP reales a una aplicación en ejecución para detectar vulnerabilidades desde la perspectiva de un atacante. Requiere un entorno de staging desplegado, por lo que se ubica después de la etapa de CD. SCA (Software Composition Analysis): Analiza CVE conocidos y cumplimiento de licencias en bibliotecas open-source. Parsea archivos como y contra el GitHub Advisory Database. Dependabot es el ejemplo principal. Escaneo de IaC: Detecta configuraciones incorrectas en ARM, Bicep y Terraform antes del despliegue — puertos abiertos, cifrado deshabilitado, permisos excesivos. Checkov, tfsec y Template Analyzer cubren esto. Escaneo de imágenes de contenedor: Detecta CVE en paquetes del SO y dependencias incluidos en una imagen Docker. Se necesita tanto en el push de la imagen como en runtime.
SAST cubre defectos en el código que escribiste; SCA cubre vulnerabilidades en bibliotecas que importaste; DAST cubre debilidades que solo aparecen en tiempo de ejecución. Son complementarias, no intercambiables.
!4 categorías de análisis de seguridad: SAST, DAST, SCA, IaC
GitHub Advanced Security — CodeQL y Secret Scanning
Imagina una planta de producción alimentaria con tres etapas: materias primas analizadas en la recepción, línea de producción monitorizada continuamente, productos terminados inspeccionados antes del envío. GitHub Advanced Security (GHAS) aplica el mismo modelo por capas. CodeQL analiza el código, secret scanning vigila las filtraciones de credenciales y dependency review inspecciona cada nueva biblioteca incorporada mediante un pull request.
CodeQL es el motor SAST principal de GHAS. Convierte el código fuente en una base de datos relacional y busca patrones de vulnerabilidades con un lenguaje de consulta llamado QL. El flujo sigue tres pasos: Init (inicializar la base de datos CodeQL), Autobuild (detectar el lenguaje y compilar Co Java) y Analyze (ejecutar los paquetes de consultas y emitir un archivo SARIF). Un único archivo activa todo. Los resultados aparecen en la pestaña Security de GitHub como code scanning alerts y como comentarios en línea en los pull requests.
Un punto operativo clave: para que funcione la comparación de code scanning en los PR, deben existir resultados de CodeQL en la rama base (). Sin ellos, CodeQL devuelve . La solución es añadir un disparador push en la rama principal para ejecutar CodeQL al menos una vez.
Secret scanning opera en dos modos. Secret scanning alerts detecta patrones de credenciales ya confirmados. El secret scanning partner program monitoriza repositorios públicos en busca de tokens de más de 100 proveedores y, al detectar uno, notifica al emisor vía API para activar la revocación automática. Push protection (exclusivo de GHAS) bloquea el push en el servidor antes de que la credencial llegue. Distinción para el examen: → secret scanning partner program; → push protection.
Dependabot — Actualizaciones de Seguridad y de Versión
Dos tipos de mantenimiento de vehículos: cuando se detecta un defecto grave, el fabricante contacta de inmediato para una reparación urgente (actualizaciones de seguridad); la inspección anual sigue un calendario fijo sin importar problemas (actualizaciones de versión). Dependabot gestiona ambos modos de forma independiente, y confundirlos es un error frecuente en el examen.
Las Dependabot alerts se activan cuando se registra o actualiza un nuevo CVE en el GitHub Advisory Database o el NVD. Un push o la creación de un pull request no son disparadores directos. La gravedad sigue CVSSv3: Critical, High, Medium y Low.
Las Dependabot security updates responden a las alertas abriendo un PR que actualiza el paquete vulnerable a una versión corregida y activa CI para verificar compatibilidad. Las Dependabot version updates actualizan las dependencias según un calendario, independientemente de la seguridad. Se configuran en con ecosistemas (npm, Maven, NuGet, pip) y cadencia (diaria, semanal). Ambos modos se activan de forma independiente.
Una advertencia práctica: omitir genera decenas de PRs acumulados. Los equipos acaban ignorando todos los PRs de Dependabot, incluidas las correcciones críticas. Cadencia semanal y alcance limitado a dependencias clave mantienen una relación señal/ruido saludable.
Microsoft Defender for DevOps y el Escaneo de Contenedores
Imagina cámaras de vigilancia cubriendo toda una ciudad con feed en un único centro de control. Microsoft Defender for DevOps ofrece esa visibilidad consolidada sobre repositorios, pipelines e infraestructura en la nube, todo en el panel de Defender for Cloud. Conecta una organización de Azure DevOps o GitHub mediante el conector DevOps Security y añade la tarea de Microsoft Security DevOps (MSDO) al pipeline.
MSDO agrupa Credential Scanner (credenciales expuestas), Binskim (análisis de binarios) y Template Analyzer (configuraciones incorrectas en ARM y Bicep). Los hallazgos fluyen a Defender for Cloud. Microsoft Defender for Containers cubre dos fases: un escaneo de CVE cuando se hace push a Azure Container Registry (ACR) y varredura continua del runtime de AKS. GHAS cubre código y repositorio; Defender for Cloud cubre infraestructura y runtime; el conector une ambos.
Integración en el Pipeline — Gates, Fail-Fast y Baselines
Piensa en el sistema de control de acceso por capas de un edificio: la entrada del vestíbulo solo requiere un toque de tarjeta, la sala de servidores exige autenticación biométrica y las áreas clasificadas bloquean el acceso por completo. Los gates de escaneo de seguridad en un pipeline de CI/CD funcionan igual: la respuesta a un hallazgo debe escalar con su gravedad, no tratar todos los casos de la misma manera.
El patrón recomendado: los hallazgos Critical y High fallan la build de inmediato (fail-fast). Los hallazgos Medium generan una advertencia pero permiten continuar. Los hallazgos Low e informational se registran solo en el informe de escaneo. CodeQL, SonarCloud y Mend Bolt soportan políticas basadas en umbrales de gravedad.
La configuración de una baseline es esencial cuando se introduce el escaneo de seguridad por primera vez en una base de código heredada. Bloquear todos los hallazgos de baja gravedad existentes paralizaría al equipo al instante. La opción del code scanning de GitHub implementa esto con elegancia: solo los hallazgos introducidos por nuevos commits generan un bloqueo, dejando el backlog acumulado para un sprint de remediación específico.
El escaneo de cumplimiento de Azure Policy se integra en un release pipeline añadiendo la tarea tras el paso de despliegue. Esto activa una evaluación bajo demanda sin esperar el ciclo predeterminado de 24 horas. Las políticas Audit registran el incumplimiento sin bloquear; las políticas Deny impiden directamente el despliegue de recursos no conformes.
Resumen para el Examen
"Vulnerabilidades a nivel de código, sin ejecución" -- SAST (CodeQL) "App en ejecución, peticiones HTTP, perspectiva del atacante" -- DAST (OWASP ZAP) "CVE de dependencias open-source y cumplimiento de licencias" -- SCA (Dependabot, Mend Bolt) "Bloquear push con credenciales antes de que llegue al repo" -- GHAS Push Protection "Notificar al emisor y revocar automáticamente tras el commit" -- Secret Scanning Partner Program "Disparado por actualización de Advisory DB, no por push ni PR" -- Dependabot alerts "Mantener dependencias al día, sin relación con seguridad" -- Dependabot version updates "Configuraciones incorrectas en ARM / Bicep / Terraform antes del despliegue" -- Template Analyzer / Checkov / tfsec "ACR push + AKS runtime, escaneo de contenedor en dos fases" -- Microsoft Defender for Containers "Azure DevOps + GitHub resultados de seguridad en un único panel" -- Microsoft Defender for DevOps "Imagen firmada / Content Trust / ACR" -- Solo ACR Premium SKU "Feedback temprano en la fase de PR, dónde ubicar SAST" -- Build pipeline (no Release pipeline)
Shift-left = escaneo de seguridad desde el primer commit; GHAS = la plataforma de seguridad integrada a nivel de repositorio.