Durante mucho tiempo SAST fue sinónimo de herramienta pesada, cara y con tasas de falsos positivos que agotaban a cualquier equipo. Los escáneres comerciales clásicos tardaban horas en terminar y cuando lo hacían, la lista de hallazgos era tan larga que nadie la leía. Ese escenario ha cambiado en los últimos años, y buena parte del mérito lo tiene Semgrep, una herramienta que apareció como proyecto open source y que en 2025 se ha asentado como una de las opciones por defecto en pipelines modernos.
Este post resume cómo se usa hoy Semgrep en los equipos que he visto, qué tipo de reglas aportan valor, y qué errores se repiten cuando se intenta desplegarlo sin el cuidado debido. No es una introducción a la sintaxis del patrón; sí es una reflexión sobre el rol del SAST en un flujo de trabajo moderno.
Por qué Semgrep encaja donde otros SAST no
La diferencia de fondo es que Semgrep piensa en reglas, no en un catálogo monolítico. Una regla de Semgrep es un patrón de código escrito en un lenguaje muy parecido al código real, con comodines. El usuario escribe la regla en diez minutos, la prueba en su propio repositorio, y si le sirve, la mete en el pipeline. Esa baja fricción cambia por completo la economía del análisis estático: dejan de ser reglas imposibles de entender de un vendor y pasan a ser código del equipo.
La segunda razón es la velocidad. Semgrep analiza por coincidencia sintáctica, sin construir un grafo completo de control de flujo. Para muchos tipos de vulnerabilidades eso es suficiente y da un rendimiento órdenes de magnitud mejor que los SAST clásicos. Un repositorio mediano se escanea en segundos en CI, no en horas. Eso permite tenerlo en cada pull request en lugar de como job nocturno que nadie mira.
La tercera razón es el catálogo público. El registry de Semgrep acumula ya miles de reglas que la comunidad y el propio equipo mantienen. Puedes empezar con un pack por lenguaje y añadir reglas propias conforme aparecen problemas recurrentes en tu código. El hueco entre «herramienta con reglas fijas» y «herramienta que adaptas al contexto» desaparece.
Qué tipos de problemas detecta bien
Semgrep brilla en un conjunto concreto de vulnerabilidades, y conviene conocerlo para no esperar lo que no va a dar.
El primero es el uso incorrecto de APIs sensibles. Llamadas a funciones de cifrado sin inicialización segura, uso de bibliotecas criptográficas con algoritmos débiles, patrones de construcción de SQL sin parámetros, inclusión de entrada de usuario en comandos de shell. Estos son los casos donde Semgrep hace el trabajo de un linter de seguridad con muy pocos falsos positivos.
El segundo son los secretos hardcodeados. Aunque existen herramientas específicas (gitleaks, trufflehog), Semgrep puede detectar patrones característicos de credenciales, claves AWS, tokens de servicios, con reglas muy simples. El valor añadido es que puedes combinar esta detección con otras del mismo pipeline sin introducir una herramienta nueva.
El tercero son las violaciones de convenciones internas. Muchos equipos tienen reglas implícitas: «siempre usar logger X, no print», «todos los endpoints deben pasar por el decorador de auth», «no construir URLs manualmente». Esas reglas se escriben en Semgrep en un rato y se vuelven parte del CI. El efecto en calidad del código es superior al de cualquier paquete externo, porque resuelve problemas reales del equipo.
El cuarto son los desvíos de configuración en archivos YAML o JSON. Políticas de Kubernetes sin requests, CronJobs sin backoffLimit, imágenes sin digest fijo. El motor de Semgrep entiende estructura, no solo texto, y permite reglas precisas sobre ficheros de configuración.
Lo que Semgrep no hace igual de bien
Es importante no creer que Semgrep sustituye a todos los otros análisis. Hay cosas donde se queda corto.
Los análisis de taint complejos, donde una vulnerabilidad depende del flujo de un valor a través de muchas funciones o módulos, están mejor cubiertos por herramientas con análisis interprocedural completo (CodeQL, Checkmarx, Fortify). Semgrep Pro ha incorporado taint con flujo limitado en los últimos años y cubre más casos que antes, pero el nicho de los análisis profundos sigue siendo de herramientas especializadas.
La detección de vulnerabilidades de librerías de terceros (CVEs) no es el trabajo de Semgrep. Para eso hay SCA (Dependabot, Renovate con Trivy, Snyk). Intentar forzar Semgrep a hacer SCA lleva a una mala experiencia.
Los bugs de concurrencia, condiciones de carrera, problemas de memoria en código nativo, y errores lógicos puros quedan también fuera del alcance. Semgrep es un motor de patrones, no un analizador semántico exhaustivo.
Cómo meterlo en un pipeline sin que se convierta en ruido
La adopción típica falla cuando se activa todo el paquete por defecto y el primer día aparecen doscientos hallazgos. Nadie los lee y la herramienta pasa a ignorarse. Para evitar eso, conviene ir por pasos.
Primero, escanear el repositorio en local y revisar los hallazgos antes de conectar nada a CI. Eso permite identificar reglas ruidosas, marcarlas como disabled en el archivo de configuración y empezar con un perfil limpio. Es un trabajo de una tarde y ahorra muchos meses de conflictos.
Segundo, introducir Semgrep en CI como aviso, no como bloqueo. Las primeras semanas, los hallazgos aparecen como comentarios en la pull request pero no impiden el merge. Esto deja al equipo aprender a leerlos sin presión. Cuando el volumen de nuevos hallazgos se estabiliza, se puede empezar a bloquear por severidad alta.
Tercero, separar reglas por propósito: las de seguridad en un pack obligatorio, las de convenciones internas en un pack opcional, las reglas custom en su propio archivo versionado en el repositorio. Esta separación ayuda a que el equipo entienda qué está pasando cuando algo salta.
rules:
- id: block-bare-urllib
pattern: urllib.request.urlopen($X)
message: Usa http_client.get() del módulo interno; urlopen no valida certificados por defecto.
severity: WARNING
languages: [python]Una regla así, escrita en la tarde de integración, cubre un problema concreto del equipo y se revisa cuando cambia la arquitectura. Es la diferencia entre hacer seguridad como ceremonia y hacerla como código.
El salto a Semgrep Pro y AppSec Platform
Semgrep lleva tiempo en modelo dual: el motor open source, más el servicio Pro con reglas avanzadas y análisis interprocedural. En los últimos meses la oferta empresarial se ha ampliado con la AppSec Platform, que integra SAST, secretos y un nivel básico de SCA.
Mi opinión, después de ver varias adopciones, es que el open source cubre el 80% de las necesidades de un equipo pequeño o mediano. El salto a Pro tiene sentido cuando el código tiene bastante flujo de datos complejo (aplicaciones con muchas capas) y cuando el equipo ya ha madurado el uso de la herramienta hasta el punto de necesitar taint analysis. Empezar con Pro sin haber pasado por el ciclo de reglas propias es caro y da menos valor del que parece.
Mi lectura
Semgrep no es perfecto pero representa el cambio más sano que ha tenido el SAST en la última década. Mover las reglas al código del equipo, hacer las ejecuciones rápidas, y abrir el catálogo a una comunidad ha convertido el análisis estático en una herramienta práctica en lugar de un trámite de auditoría.
Lo que más me convence es que, cuando se usa bien, deja de ser la voz del equipo de seguridad gritándole al equipo de desarrollo. Cada desarrollador puede escribir reglas para su propio código, cada repositorio tiene su perfil, y las discusiones sobre qué es un hallazgo real pasan en pull requests normales. Esa normalización es más valiosa que cualquier prestación puntual.
Para quien está decidiendo hoy si adoptarlo, diría que la pregunta no es si Semgrep vale, sino si el equipo está listo para convivir con hallazgos que exigen leerlos y decidir. Si la cultura todavía no está en ese punto, antes que Semgrep hay trabajo de proceso. Si lo está, Semgrep se convierte en una de las piezas más útiles del cinturón.
