Leer una consulta

Una consulta de CodeQL empieza con un comentario de metadatos. Los más importantes: @name y @description (qué busca), @kind (la forma del resultado), @problem.severity (error, warning o recommendation), @security-severity (una puntuación de 0.0 a 10.0 en las consultas de seguridad), @precision (low, medium, high o very-high: cuánto se espera que acierte) y @id (un identificador único con forma de ruta, como lenguaje/descripcion).

Hay dos formas de resultado. Con @kind problem la consulta marca un lugar del código. Con @kind path-problem marca un lugar y además entrega el recorrido que lleva hasta él, paso a paso, desde donde entra un dato hasta donde se usa.

El @id es el nombre con el que una consulta aparece en un informe, en una supresión o en una política. Dos consultas no pueden compartirlo. Cuando un equipo escribe «ignorar la consulta X» o «subir la consulta X a bloqueante», X es ese identificador.

Abre las dos consultas de la carpeta. Una es de seguridad y entrega recorridos.

Una consulta de flujo de datos se lee en tres partes. Primero, qué se considera un origen: los lugares donde entra un dato que no controlamos (la petición HTTP, un archivo subido, una variable de entorno). Segundo, qué se considera un destino peligroso: el punto donde ese dato haría daño si llega sin tratar, como el texto de una consulta SQL. Tercero, qué se considera una barrera: la función que, si el dato pasa por ella, hace que la consulta deje de seguirlo.

La tercera parte es la que más se olvida al leer, y la que más falsos positivos o falsos negativos provoca: una barrera que la consulta no conoce hace que marque flujos que ya están protegidos; una barrera demasiado generosa hace que la consulta deje pasar flujos que no lo están.

@precision es la propia promesa de la consulta sobre cuánto acierta. Una consulta de precisión alta marca poco y casi siempre con razón; una de precisión baja marca mucho y a menudo sin razón. Con @problem.severity recommendation y precisión baja, la consulta es una sugerencia de mantenimiento, no una vulnerabilidad.

Esto importa al decidir qué consulta puede parar una fusión y cuál solo informa. Una política que bloquea por todo lo que haya en el informe termina bloqueando por sugerencias, y el equipo acaba desactivando el análisis entero.

La consulta de registro sin nivel la escribió un desarrollador del equipo de pedidos y marca llamadas que no indican el nivel del mensaje. Plataforma quiere activar el análisis en las solicitudes de cambios y decidir si esa consulta puede frenarlas.