Cómo la AI clasifica hallazgos de Semgrep

Convertir un bug encontrado una sola vez en una barrera permanente es el objetivo de combinar Semgrep con AI para el triaje de vulnerabilidades. Si trabajas con código legacy y quieres dejar registro de cada error sin ahogarte en falsos positivos, esta combinación te da un flujo repetible y confiable.

La idea central es simple: un hallazgo aislado no sirve de mucho porque el mismo error puede volver a aparecer, ya sea a ti o a alguien más del equipo. Por eso pasamos de encontrar bugs a registrarlos como reglas que el análisis estático vigile de forma automática.

Por qué combinar análisis estático con AI en seguridad

Cada herramienta tiene fortalezas y debilidades muy claras, y aquí viene lo interesante: se complementan casi a la perfección.

El análisis estático, conocido como SAST, trabaja con reglas predefinidas para patrones comunes que incluso tú puedes crear [00:52]. Escanea todo el código sin cansarse, pero es muy malo entendiendo el contexto. Le cuesta distinguir lo que realmente es explotable de lo que no lo es.

La AI, específicamente un LLM con conciencia de contexto, es excelente razonando sobre ese contexto y respondiendo si algo es explotable aquí o no. Pero es pésima escaneando todo el código y puede alucinar si le das demasiado contexto sin control [01:20].

¿Qué es el análisis estático o SAST? Es una técnica que escanea el texto del código buscando patrones de error conocidos mediante reglas predefinidas. Nunca se cansa de buscar, pero no comprende el contexto de lo que encuentra.

La distribución del trabajo respeta lo que cada quien hace mejor: Semgrep encuentra, la AI interpreta.

Cómo ejecutar Semgrep y generar un reporte

El primer paso es correr Semgrep en vivo sobre el proyecto y verificar que esté disponible antes de nada [02:01].

Luego se crea la carpeta donde se guardará el reporte generado, en este caso dentro de samples. Después se ejecuta la herramienta con el comando que apunta a la configuración automática, formato JSON y la ubicación del archivo.

bash semgrep --config auto --json <ubicación-del-archivo>

El resultado en crudo es bastante ruidoso, porque busca patrones de error comunes de forma general [02:35]. Aunque en el ejemplo aparecen cuatro o cinco hallazgos, entenderlos manualmente tomaría demasiado tiempo. Ese es justo el problema clásico de la herramienta: una avalancha de alertas donde 10 son relevantes y el resto son falsos positivos.

Cómo usar AI para clasificar hallazgos de Semgrep

Aquí entra la AI como herramienta de triaje, no para encontrar problemas desde cero sino para interpretar lo que Semgrep ya detectó.

El prompt le pide a la AI actuar como revisor de seguridad de Payments SVC y clasificar cada hallazgo en tres categorías [03:15]:

• True: el patrón es explotable y representa un bug accionable en este contexto.
• False positive: el patrón se marcó, pero no es explotable aquí o no aplica.
• Human require: se necesita contexto humano para decidir sin inventar nada.

Las reglas del prompt son estrictas y evitan alucinaciones. La AI solo puede usar la salida de Semgrep y los archivos del repo, debe abrir las líneas citadas antes de clasificar, y las citas deben corresponder a líneas reales del archivo. No puede inventar contexto sobre infraestructura, bases de datos, autenticación o usuarios, y si necesita suponer algo para decidir, debe clasificarlo como human require [04:04].

¿Cómo evitar que la AI invente vulnerabilidades? Restringe el prompt a que solo use la salida real de la herramienta y los archivos citados, prohíbe suponer contexto de infraestructura y obliga a marcar como human require cualquier caso que requiera asumir algo.

El resultado organiza los hallazgos, los interpreta y entrega el triaje. Por ejemplo, un hallazgo señala que una función valida un estado contra una allowlist fija antes de concatenar, por lo que ese valor nunca se concatenará fuera de la lista permitida: es un falso positivo [04:50]. En cambio, otro hallazgo es real, una inyección en una consulta SQL colocada intencionalmente, porque permite manipular la query [05:10].

Cómo convertir un anti-patrón confirmado en una regla de Semgrep

Una vez que sabes qué es real, puedes modificar las reglas de Semgrep para que siempre revisen ese patrón y dejen de listar los falsos positivos que confunden a medida que el código crece [05:45].

Le pedimos a la AI que genere una regla de Semgrep basada en el anti-patrón confirmado. El prompt es específico: no quiere una explicación general, sino una regla que se pueda guardar y correr [06:20]. El anti-patrón descrito es una variable con nombre tipo query, SQL o statement que se construye concatenando strings con una variable de entrada y luego se ejecuta contra la base de datos.

Los requisitos de la regla incluyen:

• Debe contener ID, message, severity, language, metadata y patterns.
• Debe detectar queries construidas por concatenación, incluso en variables ensambladas y ejecutadas después.
• No debe depender de una sola línea, porque la concatenación puede ocurrir en asignaciones multilínea.
• No debe ser tan específica que solo funcione para el ejemplo, ni incluir Markdown en el YAML final [07:10].

Algo valioso: tú mismo puedes construir este tipo de prompt con AI para personalizarlo al caso específico que encontraste.

Al correr de nuevo el comando de Semgrep, el reporte muestra solo dos hallazgos activos, los que eran reales y para los que configuramos reglas, mientras los demás quedan tratados como los falsos positivos que son [08:00].

Por qué este proceso sigue siendo reactivo

Este flujo es repetible: si el repo crece y se agregan archivos, aparecerán nuevas alertas y puedes repetir el ejercicio para decidir si son falsos positivos o no, y sumar las reglas correspondientes [08:30].

El resumen del enfoque queda claro: el análisis estático escanea sin descanso, la AI razona con base en el contexto, y cada hallazgo se clasifica como true, falso positivo o requiere revisión humana. La AI incluso nos ayuda a escribir nuevas reglas de Semgrep.

Pero hay una limitación honesta: hasta ahora seguimos siendo reactivos, reaccionamos a lo que la herramienta encuentra [09:05]. En la siguiente clase cambia el rol y le pedimos a la AI que actúe como atacante.

¿Ya probaste este flujo de triaje en tu propio proyecto? Cuéntame en los comentarios qué reglas personalizadas creaste.