AppSec Shift-Left: SAST, SCA y Escaneo de Secretos sin Frenar al Equipo

Cada vez que un CISO anuncia 'shift-left' un jueves, algun equipo de plataforma pasa el fin de semana quitando gates del pipeline. La promesa de detectar vulnerabilidades antes del merge es real, pero la ejecucion suele terminar en un SAST con 4 mil findings, un SCA quejandose de un CVE de 2017 en una libreria de test, y un escaner de secretos que falla porque alguien versiono un .env.example. El resultado es predecible: PRs ignorados, builds rotos, devs frustrados y seguridad convertida en burocracia. En Basilisk OffSec tratamos AppSec como producto interno, con SLA, metricas de friccion y un camino de adopcion escalonado que arranca en warning-only y termina con bloqueo quirurgico.

Antes de instalar cualquier herramienta, define que llamas 'critico'. Sin esa definicion, Semgrep, Snyk y CodeQL competiran por ver quien alarma mas. Usa el threat model del servicio como base: si aun no tienes uno, empieza por Threat Modeling con STRIDE en Sprints: Ejemplo Completo de un Microservicio y clasifica los activos en tres tiers. Para un microservicio tier-1 que procesa PII, cualquier CWE-89 o CWE-78 detectada via SAST debe romper el build. Para un job batch interno, quizas baste un reporte semanal. Este mapeo de severidad-por-contexto reduce entre 60-80% los falsos positivos relevantes, segun mediciones de nuestro pilot con 12 squads en 2025.

SAST por si solo no resuelve. Combina Semgrep (reglas custom en YAML, baratas de mantener) con CodeQL para flujos de datos mas profundos en Java y C#. Empieza en modo 'comment-only' en GitHub: el bot publica el hallazgo en el PR sin romper el check. Mide dos cosas durante 30 dias: tiempo medio entre comentario y fix, y tasa de 'wont-fix'. Si 'wont-fix' supera el 40%, tu baseline de reglas esta mal, no el equipo. Tras ese periodo, promueve solo las reglas con precision sobre 85% a gate bloqueante. Para casos avanzados como inyeccion web, complementa con aprendizaje practico en SQL Injection en la Practica: Explotar, Detectar y Mitigar en Lab Controlado y XSS Moderno: DOM, Stored y Reflected con Ejemplos Reales en Entorno de Pruebas para que los devs entiendan que esta alarmando el linter.

SCA es donde mas equipos tropiezan. Trivy, Grype y osv-scanner son buenos, pero todos apuntaran cientos de CVEs transitivas en dependencias que ni siquiera invocas. La unica metrica que importa es reachability. Usa Endor Labs, Socket o el propio osv-scanner con flag --experimental-call-analysis para filtrar CVEs en funciones no invocadas. Combina con SBOM firmado y politica de cuarentena, como describe Supply Chain Security: Firma con Sigstore y SBOM Real en CI/CD. Y no olvides typosquatting y namespace hijacking: un proxy interno (Artifactory, Nexus) con allowlist resuelve el 90% del problema, y Dependency Confusion y Typosquatting: Defensa Practica para Equipos Dev detalla las trampas que aun se escapan.

Secrets scanning es la victoria rapida que muchos hacen mal. Gitleaks y Trufflehog en pre-commit cazan la fuga antes del push, pero necesitas un segundo escaner server-side (GitHub Advanced Security o Gitleaks via Action) para cubrir bypass del hook local. El punto critico: si un secreto se detecta en un commit ya pusheado, considerarlo publicado. Fuerza rotacion, no reescribir historia. En 2025 vimos 3 incidentes donde equipos perdieron horas en git filter-repo mientras la clave AWS ya estaba siendo abusada. Ten un runbook automatizado que revoque la credencial en menos de 5 minutos y abra ticket de post-mortem.

Las metricas de friccion separan AppSec funcional de teatro de seguridad. Sigue cuatro KPIs por squad: tiempo medio del pipeline de seguridad (objetivo bajo 4 minutos), tasa de rerun por scanners flaky (objetivo bajo 5%), MTTR de findings criticos (objetivo bajo 7 dias) y NPS interno del equipo de producto sobre las herramientas. Si el NPS cae bajo cero, pausa la expansion e investiga. Combina con sesiones mensuales de purple team enfocadas en flujos reales, alineadas a Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue, para validar que lo que el SAST encuentra coincide con lo que el red team explota.

El takeaway practico es simple: no enciendas todo en bloqueo el dia uno. Empieza con warning, define criticidad por contexto, mide friccion, y solo promueve reglas con precision comprobada. En seis meses tendras un pipeline que los devs respetan porque rara vez se equivoca, y cuando alarma, vale la pena mirar. Eso es shift-left real, no shift-blame.