El análisis estático se ha vuelto muy bueno en una pregunta específica: ¿este código está mal? Encuentra la desreferenciación nula, la inyección, la deserialización insegura, el patrón conocido como malo. Lo que no puede preguntar es una pregunta completamente diferente: ¿este cambio viola un deber que reside en una normativa?
Dos preguntas diferentes
Un linter razona sobre el código frente a él: tipos, flujo de control, contaminación, firmas de vulnerabilidades conocidas. Es ciego a los marcos por diseño, porque las reglas que aplica son universales, las mismas en cada repositorio del mundo.
El cumplimiento es lo opuesto. Si un cambio es un problema depende de hechos que el código no contiene: qué marcos debe cumplir tu empresa, qué se considera datos personales en tu dominio, cuánto tiempo estás autorizado a conservarlos, dónde está permitido que fluyan. El mismo diff puede ser perfectamente conforme en una empresa y un hallazgo en otra.
El cambio que es correcto e incumplido a la vez
Agrega una línea de registro que graba el cuerpo completo de la solicitud para depurar un flujo de pago. El código es correcto. Compila, se ejecuta, ningún linter objeta, las pruebas pasan. También escribe un correo electrónico y una dirección del cliente en tus registros, lo cual es más datos personales de los que el propósito requiere, y eso es territorio del GDPR Art. 5(1)(c).
Ninguna herramienta que razone sobre la calidad del código marcará eso, porque no hay nada de baja calidad en el código. El problema solo es visible si se lee el cambio en función de las obligaciones de protección de datos que la empresa realmente tiene. Esa es la capa consciente de los marcos que los linters no tienen.
La capa faltante, no un reemplazo
Esto no es un argumento en contra de los linters o escáneres. Consérvalos; detectan cosas que heygrc nunca detectará. Es un argumento de que existe una categoría completa de riesgos por encima de ellos, las obligaciones de los marcos, que ningún análisis de calidad de código puede ver.
heygrc es esa capa. Lee el cambio en función de tus marcos y cita el control específico, para que el punto ciego de los marcos en tus herramientas existentes obtenga un conjunto de ojos.