L'analyse statique est devenue très efficace pour répondre à une question spécifique : ce code est-il incorrect ? Elle détecte la déréférenciation nulle, l'injection, la désérialisation non sécurisée, le motif connu comme dangereux. Ce qu'elle ne peut pas demander, c'est une question totalement différente : cette modification viole-t-elle une obligation définie dans une réglementation ?
Deux questions différentes
Un linter raisonne sur le code qui lui est présenté : types, flux de contrôle, taint, signatures de vulnérabilités connues. Il est aveugle aux cadres par conception, car les règles qu'il applique sont universelles, identiques dans chaque dépôt au monde.
La conformité est l'inverse. Qu'une modification pose problème dépend de faits que le code ne contient pas : quels cadres votre entreprise doit respecter, ce qui compte comme données personnelles dans votre domaine, combien de temps vous êtes autorisé à les conserver, où elles sont autorisées à circuler. Le même diff peut être parfaitement conforme dans une entreprise et constituer une observation dans une autre.
La modification à la fois correcte et non conforme
Ajoutez une ligne de journalisation qui enregistre le corps complet de la requête pour déboguer un flux de paiement. Le code est correct. Il compile, il s'exécute, aucun linter ne proteste, les tests passent. Il écrit également un email et une adresse de client dans vos journaux, ce qui représente plus de données personnelles que nécessaire pour l'objectif, et cela relève de l'article GDPR Art. 5(1)(c).
Aucun outil raisonnant sur la qualité du code ne signalera cela, car rien dans le code n'est de mauvaise qualité. Le problème n'est visible que si vous lisez la modification par rapport aux obligations de protection des données que l'entreprise a effectivement. C'est la couche consciente des cadres que les linters n'ont pas.
La couche manquante, pas un remplacement
Ceci n'est pas un argument contre les linters ou les scanners. Gardez-les ; ils détectent des choses que heygrc ne détectera jamais. C'est un argument selon lequel il existe une catégorie entière de risques située au-dessus d'eux, les obligations des cadres, qu'aucune analyse de qualité de code ne peut voir.
heygrc est cette couche. Il lit la modification par rapport à vos cadres et cite le contrôle spécifique, afin que le point aveugle lié aux cadres dans vos outils existants obtienne une paire d'yeux.