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 despliegue escalonado que arranca en warning-only y termina con bloqueo quirurgico. Esta guia recorre el camino completo: como definir criticidad, cablear SAST, SCA y escaneo de secretos para que ganen confianza, endurecer el propio pipeline y medir si el equipo realmente respeta el resultado.

Que significa 'critico' de verdad: severidad por contexto

Antes de instalar cualquier herramienta, define que llamas critico. Sin esa definicion, Semgrep, Snyk y CodeQL competiran por ver quien alarma mas, y cada alerta cargara el mismo peso visual sin importar el radio de impacto. Usa el threat model del servicio como base y clasifica los activos en tres tiers. Un microservicio tier-1 que procesa PII o dinero no es la misma superficie de riesgo que un job batch interno que lee una replica de solo lectura. Para un servicio tier-1, cualquier CWE-89 (SQL injection) o CWE-78 (inyeccion de comandos del SO) detectada via SAST debe romper el build de inmediato. Para un job batch interno, un reporte semanal quizas baste. Este mapeo de severidad-por-contexto reduce entre 60 y 80 por ciento los falsos positivos relevantes, segun mediciones de nuestro piloto con 12 squads en 2025. El mapeo no es una hoja de calculo que escribes una vez, sino un artefacto de policy-as-code que vive junto al servicio y se revisa cuando cambia la clasificacion de datos.

SAST sin fatiga de alertas

SAST por si solo no resuelve. Combina Semgrep (reglas custom en YAML, baratas de mantener, rapidas sobre diffs) con CodeQL para flujos de datos interprocedurales mas profundos en Java, C# y Go. Corre Semgrep solo sobre los archivos cambiados en el check de PR y manten un scan de arbol completo cada noche, para que la latencia hacia el dev sea baja y la cobertura siga siendo total. Empieza cada regla nueva 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 la tasa de wont-fix. Si wont-fix supera el 40 por ciento, tu baseline de reglas esta mal, no el equipo. Tras ese periodo, promueve solo las reglas con precision sobre 85 por ciento a gate bloqueante. La precision se mide, no se asume: toma 30 hallazgos, que un ingeniero etiquete cada uno como verdadero o falso positivo y calcula el ratio antes de poner el gate en rojo.

Configuracion concreta para copiar

Un gate minimo de Semgrep se ve asi: semgrep ci --config auto --baseline-commit $(git merge-base origin/main HEAD), que escanea solo lo que introduce la rama y suprime la deuda preexistente para no bloquear un PR por pecados del ano pasado. Una regla custom son unas lineas de YAML: un pattern como pattern: exec.Command($CMD, ...) con un metavariable-pattern que marca input contaminado llegando al argumento, etiquetado severity: ERROR y mapeado a CWE-78. Para CodeQL, cablea la action oficial con languages: java y deja que publique en la pestana de code-scanning, para que los hallazgos se dedupliquen contra Semgrep en vez de duplicar el ruido. Manten cada regla en un repositorio versionado con entrada CODEOWNERS, para que un cambio de regla sea el mismo una PR revisada y nunca un cambio silencioso de politica que sorprenda a un squad el lunes por la manana.

SCA y el problema de reachability

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. Una CVE en un camino de codigo que tu servicio nunca ejecuta es un item de backlog, no un rompe-build. Usa Endor Labs, Socket o el propio osv-scanner con flag --experimental-call-analysis para filtrar CVEs en funciones no invocadas, y haz gate solo sobre hallazgos alcanzables, corregibles y de severidad alta o critica. Combina con un SBOM firmado en tiempo de build (syft o trivy sbom) y una politica de cuarentena que bloquee una version recien publicada durante 48 horas, lo que anula la mayoria de ataques de release malicioso a la cadena de suministro. No olvides typosquatting y namespace hijacking: un proxy interno como Artifactory o Nexus con allowlist resuelve el 90 por ciento del riesgo de dependency confusion al negarse a resolver nombres internos desconocidos contra el registro publico.

Escaneo de secretos y el reflejo de rotacion

El escaneo de secretos es la victoria rapida que muchos hacen mal. Gitleaks y TruffleHog en un hook de pre-commit cazan la fuga antes del push, pero un hook local es consultivo y facil de saltar con --no-verify, asi que necesitas un segundo escaner server-side: GitHub Advanced Security push protection, o Gitleaks como Action requerida. El modelo mental critico: en cuanto un secreto aterriza en un commit pusheado, considerarlo publico, punto. Fuerza rotacion; no reescribas la historia y lo llames arreglado. En 2025 vimos 3 incidentes donde equipos perdieron horas en git filter-repo mientras la clave AWS expuesta ya se usaba para levantar instancias de mineria. Ten un runbook automatizado que revoque la credencial en menos de 5 minutos, invalide sesiones dependientes y abra ticket de post-mortem. El modo de secretos verificados de TruffleHog, que prueba si una clave hallada esta viva, vale el minuto extra porque permite triage por exposicion real en vez de por conteo de coincidencias regex.

Endurecer el propio pipeline

Un escaner es tan confiable como el runner donde se ejecuta. Usa runners efimeros de un solo uso, para que un job comprometido no persista al siguiente build. Reemplaza credenciales cloud de larga vida por federacion OIDC de corta vida: el job de CI intercambia su token de identidad firmado por un rol cloud acotado de minutos, de modo que no hay ningun AWS_SECRET_ACCESS_KEY estatico que filtrar. Fija las actions de terceros a un SHA de commit completo en vez de a un tag flotante, porque un tag puede reapuntarse a codigo malicioso despues de tu auditoria. Configura permisos de token de minimo privilegio explicitamente (permissions: contents: read) en vez de heredar defaults amplios. Firma artefactos de build e imagenes de contenedor con Sigstore cosign y verifica la firma en admision, para que el pipeline que escaneo el codigo tambien pruebe que fue lo que se envio. El tooling de seguridad no debe volverse el blanco mas blando en el camino a produccion.

Despliegue escalonado: de warning a blocking

No enciendas todo en bloqueo el dia uno. Fase uno es observar: cada herramienta corre, nada rompe el build, y recolectas baselines de volumen de hallazgos, precision y latencia de fix. Fase dos es advertir en lo nuevo, ignorar lo viejo: el truco del baseline-commit hace que solo emerjan problemas recien introducidos, alineando la senal con lo que el dev acaba de escribir. Fase tres bloquea solo el conjunto estrecho de hallazgos de alta precision, alta severidad y alcanzables, y solo esos. Publica los criterios de promocion abiertamente, para que un squad pueda predecir exactamente que empezara a fallar y cuando. Da a cada gate una salida de emergencia con rastro de auditoria: una excepcion documentada y con expiracion aprobada por el owner del servicio, no un bypass silencioso. Una excepcion visible, acotada en tiempo y revisada es una feature; un bypass que nadie ve es como los gates se pudren de vuelta al estado que hizo al CISO anunciar shift-left en primer lugar.

Metricas de friccion y el SLA interno

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 por ciento), 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 antes de anadir otro escaner. Trata las propias promesas del equipo de plataforma como un SLA: tiempo de respuesta de triage para un nuevo critico, uptime del servicio de escaneo y un presupuesto maximo de latencia anadida al check de PR. Suma sesiones mensuales de purple team sobre flujos reales para validar que lo que el SAST encuentra coincide con lo que un atacante realmente explotaria; un hallazgo de linter sin camino de explotacion es una regla para degradar, y una falla explotada que el linter perdio es una regla para escribir.

Errores comunes

Los fallos recurrentes son aburridamente consistentes. Bloquear sobre todo el backlog historico en vez del diff, lo que castiga al dev equivocado. Hacer gate sobre CVEs no alcanzables, lo que entrena a todos a clicar ignorar por reflejo hasta que ignoran tambien la alcanzable. Guardar comentarios de supresion sin expiracion, de modo que un waiver temporal se vuelve ceguera permanente. Correr escaneo de secretos solo del lado cliente y confiar en el hook. Dejar que el pipeline de seguridad corra en un runner con credenciales de produccion adjuntas. Medir volumen de hallazgos como si mas alertas significaran mas seguridad, cuando la meta real es un flujo bajo, confiable y accionado. Y el mas humano: enviar el tooling sin un canal donde un dev pueda decir esta regla esta mal y recibir una respuesta rapida y respetuosa. Cada uno de estos convierte un control defendible en aquello que los equipos rodean.

Un checklist listo para enviar

Antes de dar el rollout por terminado, confirma lo siguiente. Tiers de activos definidos y guardados como policy-as-code. SAST corriendo con alcance de diff en PRs con scan completo nocturno, reglas nuevas arrancando comment-only. SCA haciendo gate solo sobre CVEs alcanzables, corregibles y de severidad alta o critica, con SBOM firmado por build y ventana de cuarentena en releases nuevos. Un proxy interno de paquetes con allowlist contra dependency confusion. Escaneo de secretos forzado server-side con push protection, mas un runbook automatizado de revocar-y-rotar bajo 5 minutos. Runners efimeros, OIDC en vez de claves cloud estaticas, actions fijadas por SHA, tokens de minimo privilegio y artefactos firmados-y-verificados. Cuatro KPIs de friccion en dashboard por squad con SLA publicado. Excepciones documentadas, con expiracion y auditadas. Si falta alguna linea, tienes un despliegue de escaner, no un programa de AppSec.

FAQ

Debe bloquear primero SAST o SCA? Empieza con SCA sobre criticos alcanzables, porque los hallazgos de dependencias suelen tener un fix claro y de bajo esfuerzo (subir una version) y una historia limpia de verdadero positivo, asi el primer gate bloqueante gana confianza en vez de resentimiento. El bloqueo de SAST viene despues de medir la precision por regla, ya que un gate de SAST ruidoso es la forma mas rapida de perder a la sala.

Como manejamos un secreto que ya esta en la historia de git? Rota primero, siempre, y trata el valor como comprometido desde el momento en que se pusheo. Reescribir la historia con git filter-repo es limpieza que haces despues de rotar para reducir la exposicion futura, nunca la respuesta al incidente en si. Automatiza el camino de revocacion para que el tiempo medio de rotacion sean minutos, no las horas que cuesta un forcejeo manual mientras la clave esta siendo abusada.

El takeaway practico es simple: no enciendas todo en bloqueo el dia uno. Empieza con warning, define criticidad por contexto, endurece el pipeline que escanea, 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.