Lo que un analizador estático encuentra y lo que no

Un analizador estático de seguridad lee el código sin ejecutarlo y lo compara con reglas: patrones peligrosos (una llamada a evaluar texto como código, un generador aleatorio de propósito general), y en los mejores casos flujos de una fuente conocida a un sumidero conocido. Es rápido, no se cansa y no se salta archivos. Por eso conviene correrlo pronto: encuentra en minutos lo que es repetitivo y deja las horas de lectura para lo que necesita criterio.

Lo que no puede ver es lo que no tiene forma de patrón. No sabe que una ruta del panel debería exigir un rol, ni que un pedido debería ser del cliente que lo pide, ni que el monto de un cobro no debería venir del navegador: esas reglas son del negocio y no están escritas en ningún sitio que la herramienta lea. Tampoco sabe qué carpeta está en el alcance, ni reconoce siempre una validación hecha unas líneas antes con una función propia. De ahí salen sus dos errores: lo que calla y lo que marca de más.

El analizador se corrió sobre todo el repositorio, y la carta no cubre todo el repositorio. Antes de discutir si una alerta es cierta conviene apartar las que no se evalúan: las que caen en código de terceros fuera del alcance y las que caen en código que nunca llega a producción. Apartarlas no es esconderlas: las del kit del proveedor se le pueden comentar al cliente para que las traslade, y las de las pruebas automáticas se anotan si el dato que contienen fuera real.

Abre la consola. Empieza por la carta y luego por la lista de alertas.

Una regla de consulta concatenada marca cualquier suma de textos dentro de una consulta. No mira qué se suma: si el valor se convirtió en número o se comparó con una lista cerrada unas líneas antes, la regla no lo reconoce, sobre todo si la validación usa una función propia del proyecto. Para decidir hay que leer el contexto: de dónde sale cada pieza que se suma y qué le pasó antes.

Dos alertas de esta salida tienen la misma regla y la misma severidad. Solo una sobrevive a la lectura.

Las salas anteriores dejaron tres hallazgos de lectura manual. Cruzarlos con las alertas responde una pregunta que el cliente va a hacer: «¿por qué no lo encontró nuestra herramienta?». La respuesta casi siempre es la misma: el fallo está en el orden, en lo que falta o en una regla del negocio, y nada de eso tiene forma de patrón.

La salida de un analizador no es un informe. Pegarla entera traslada al cliente un trabajo que le tocaba al evaluador: separar lo cierto de lo que no lo es. Lo que sí se entrega es cada alerta con su decisión y su motivo, y cada hallazgo confirmado con su ubicación, su flujo y su prueba, venga de la herramienta o de la lectura. Contar cuántas alertas se descartaron y por qué ayuda además al cliente a ajustar las reglas que corre en su propia canalización.