Semgrep: SAST moderno en tu pipeline

Actualizado: 2026-05-03

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 se ha asentado como una de las opciones por defecto en pipelines modernos.

Este post resume cómo se usa 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. Para el contexto completo del ecosistema SAST, compara con el análisis de CodeQL en GitHub Advanced Security.

Puntos clave

• Semgrep piensa en reglas escritas en lenguaje similar al código real: baja fricción para codificar convenciones internas.
• Velocidad de análisis por coincidencia sintáctica: un repositorio mediano se escanea en segundos en CI.
• Brilla en uso incorrecto de APIs sensibles, secretos hardcodeados, convenciones internas y configuración YAML.
• No reemplaza análisis interprocedural profundo (CodeQL, Checkmarx) ni detección de dependencias vulnerables.
• La adopción fallida siempre empieza igual: activar todo por defecto y no filtrar el ruido resultante.

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 miles de reglas que la comunidad y el equipo mantienen. Puedes empezar con un pack por lenguaje y añadir reglas propias conforme aparecen problemas recurrentes en tu código.

Qué tipos de problemas detecta bien

Semgrep brilla en un conjunto concreto de vulnerabilidades:

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.

Secretos hardcodeados. Aunque existen herramientas específicas (gitleaks, trufflehog), Semgrep puede detectar patrones característicos de credenciales, claves AWS y tokens de servicios con reglas muy simples, combinando esta detección con otras del mismo pipeline sin introducir una herramienta nueva.

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 supera al de cualquier paquete externo, porque resuelve problemas reales del equipo.

Desvíos de configuración en 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:

• Análisis de taint complejos con flujo a través de muchas funciones o módulos. Herramientas con análisis interprocedural completo (CodeQL, Checkmarx, Fortify) cubren mejor este nicho. 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.
• Detección de vulnerabilidades de librerías de terceros (CVEs). Para eso hay SCA (Dependabot, Renovate con Trivy, Snyk). Intentar forzar Semgrep a hacer SCA lleva a una mala experiencia.
• Bugs de concurrencia, condiciones de carrera, problemas de memoria en código nativo y errores lógicos puros. 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 evitarlo, conviene ir por pasos:

Paso 1: escanear en local primero. Revisar los hallazgos antes de conectar nada a CI 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 que ahorra muchos meses de conflictos.

Paso 2: 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.

Paso 3: 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.

Un ejemplo de regla custom que ilustra el patrón:

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 opera en modelo dual: el motor open source, más el servicio Pro con reglas avanzadas y análisis interprocedural. La oferta empresarial incluye la AppSec Platform, que integra SAST, secretos y un nivel básico de SCA.

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.

Para un stack completo de DevSecOps con análisis de dependencias e imágenes de contenedor, revisa también la comparativa de Trivy y Grype para escaneo de imágenes.

Mi lectura

Semgrep funciona porque invierte el modelo de poder del SAST tradicional. En vez de que un vendor decida qué detectar y el equipo lo consuma, el equipo decide qué detectar y lo codifica en el mismo lenguaje que su código. Ese cambio de locus de control explica por qué las reglas propias tienen más impacto que las de catálogo: reflejan problemas reales del equipo, no problemas genéricos del sector.

La adopción que fracasa es la de quien activa todo por defecto y espera que Semgrep haga el trabajo de gobernanza de código. La que funciona es la de quien dedica una tarde a limpiar el baseline, dos semanas a observar sin bloquear, y desde ahí va añadiendo reglas que resuelven problemas reales.