Una regla por dentro

Una regla en formato YAML, como las de Semgrep, tiene piezas fijas: un id, los languages a los que aplica, una severity, un message que le explica al desarrollador qué cambiar y un bloque metadata para lo que la herramienta no usa pero las personas sí. El corazón es el patrón. pattern es una forma de código a buscar; pattern-either pide que se cumpla cualquiera de varias; patterns pide que se cumplan todas. Las metavariables como $A capturan cualquier expresión. Y hay una familia de excluyentes, pattern-not y pattern-not-inside, que descartan lo que parece el fallo pero se sabe inocuo.

Una regla ancha atrapa mucho y se equivoca mucho (falsos positivos); una estrecha se equivoca poco pero deja pasar variantes (falsos negativos). Escribir una regla es elegir ese equilibrio con los ojos abiertos.

El bloque metadata es donde la regla enlaza su hallazgo con el catálogo de debilidades de software que mantiene MITRE, el CWE. Gracias a ese identificador, los informes de herramientas distintas se agrupan bajo el mismo nombre y quien lee un informe sabe a qué familia de fallos se refiere. La confianza dice cuánta probabilidad hay de que el hallazgo sea real; más adelante en este módulo la política la usa para decidir qué reglas pueden bloquear una fusión y cuáles solo avisan.

Cuando una regla propia o heredada no declara a qué debilidad corresponde, el informe pierde buena parte de su valor para quien debe priorizar.

Una regla sin pruebas es una opinión. Para tenerlas se escribe un archivo de código con casos marcados con comentarios: # ruleid: <id-de-la-regla> antes de una línea que la regla debe marcar, y # ok: <id-de-la-regla> antes de una que no debe marcar. Con semgrep --test se corren todas y el resultado separa los dos fallos posibles: un caso ok que la regla marcó es un falso positivo; un caso ruleid que la regla no marcó es un falso negativo.

La regla propia de Naranjal, que exige autorizar un reintegro antes de pagarlo, tiene tres casos de prueba. El resultado de la última corrida dice dónde falla.

Cuando una prueba falla hay dos tentaciones: cambiar la prueba para que vuelva a pasar o aflojar la regla para que deje de molestar. Las dos esconden el problema. La corrección honesta pregunta primero si el caso de prueba tiene razón. Si la tiene, se cambia la regla de modo que lo cumpla, y se vuelven a correr todas las pruebas para comprobar que lo que ya funcionaba sigue funcionando.

En la regla de consultas de Naranjal, un caso que se escribió como inocuo (dos textos fijos pegados entre sí) está siendo marcado. El caso tiene razón: ningún dato de fuera interviene.