Cuándo SAST por patrón y cuándo semántico

Un analizador por patrones busca una forma en el código, como una llamada con una concatenación dentro. Es rápido, no necesita compilar ni construir una base, funciona con muchos lenguajes y se escribe una regla en minutos. Pero solo ve lo que cabe en un patrón local: no sabe de dónde viene el dato ni a dónde va después.

Un análisis semántico construye primero la base de datos y sigue los datos entre funciones y archivos. Ve fallos que cruzan varias líneas y distingue un dato de fuera de una constante. A cambio, tarda más, necesita extraer bien el código de cada lenguaje y las consultas son más difíciles de escribir.

Cuando el patrón busca una concatenación dentro de la llamada y la consulta llega a la llamada ya armada, el patrón no la reconoce. El análisis semántico, que sigue el dato desde la petición, sí.

Compara los informes con la lista de casos. Uno de los casos lo ve el análisis semántico y no el analizador por patrones.

Un patrón que marca toda concatenación marca también la que no tiene un dato de fuera. Cuando el equipo de pedidos recibió el informe del analizador por patrones, uno de los hallazgos no era un fallo, y la revisión manual lo confirma.

Ninguna de las dos herramientas lo ve todo. El análisis semántico no puede seguir un dato cuando el destino se decide en tiempo de ejecución, por ejemplo cuando el nombre de la función a llamar llega como texto. El analizador por patrones tampoco ve ese caso, porque en el código no hay forma fija que buscar. Lo que los dos dejan pasar se encuentra con revisión manual, con pruebas o con consultas escritas a propósito.

Para medir qué tan bien lo hizo cada herramienta hay que saber cuántos fallos reales había. Eso no lo da ninguna: lo da la revisión manual, que decide caso por caso si es real o no.

Cuenta los casos que la revisión marca como reales.