Lo que el código dice de sí mismo

«Estático» significa sin ejecutar: la herramienta lee el texto del código y reconoce formas conocidas de equivocarse. En el servicio de pagos de Cauce, Semgrep marca una consulta SQL que se arma concatenando el identificador de cuenta que llega del usuario directamente en el texto de la consulta. No ejecuta nada ni prueba el ataque; reconoce el patrón —dato de fuera pegado dentro de una consulta— que abre la puerta a una inyección. Por eso encuentra cosas antes de que existan datos reales, y por eso también se equivoca a veces: ve la forma, no el comportamiento.

Entender que el análisis estático razona sobre la forma del código, no sobre su ejecución, explica a la vez su alcance y sus falsos positivos.

Un análisis estático marca de más: reconoce la forma sospechosa aunque en ese caso concreto no haya riesgo. Distinguir el hallazgo real del falso positivo es leer el contexto. La consulta SQL que pega el identificador de cuenta del usuario es real —ese dato viene de fuera y llega sin sanear a la consulta—. En cambio, un aviso sobre una consulta que solo usa un valor fijo escrito en el propio código, que ningún usuario controla, es ruido: la forma se parece, pero no hay dato externo. Confirmar de dónde viene el dato es lo que separa una de otra.

Comprobar el origen del dato antes de abrir un ticket es lo que evita ahogar a los desarrolladores en falsos positivos y perder su confianza en el control.

La salida de Semgrep no dice «hay un problema»: señala el archivo, la línea exacta y la regla que disparó, con una explicación corta de por qué esa forma es peligrosa. En Cauce Pagos, el hallazgo apunta a la línea donde el identificador de cuenta se concatena en la consulta, con la regla de inyección SQL. Esa precisión es lo que hace accionable el resultado: el desarrollador va a esa línea, cambia la concatenación por una consulta parametrizada, y el hallazgo desaparece en el siguiente escaneo. Sin la línea, el aviso sería una búsqueda a ciegas.

Leer archivo, línea y regla —y saber traducir la regla al arreglo— es lo que convierte un escaneo en una corrección.

No todo hallazgo del análisis estático para la fusión. El criterio se fija por severidad y por certeza: una inyección SQL confirmada en el camino de pagos es un hallazgo crítico y explotable, y se para —ese código no se fusiona hasta arreglarlo—. Un aviso de estilo, o una regla de severidad baja sobre un tramo sin datos de usuario, se registra sin bloquear. La regla que suele fijarse para una cadena como la de Cauce es clara: cero hallazgos críticos para poder fusionar, y los de severidad menor se anotan para atender sin frenar el trabajo.

Fijar el umbral en la severidad, y no en «cualquier hallazgo», es lo que mantiene el control encendido y respetado.

Abre el laboratorio del análisis de código de Cauce y lee la salida de Semgrep. Hay dos hallazgos: un aviso de estilo sin datos de usuario y la inyección crítica en el camino de pagos. Quédate con el crítico y lee el código que lo identifica.