Recherchez des vérifications de conformité dans les pull requests et la plupart des résultats concernent les vérifications de statut obligatoires de GitHub : s'assurer que la suite de tests et le linter sont au vert avant une fusion. C'est une chose réelle et utile, mais ce n'est pas le sujet de cette page. Une vérification de conformité pose une question différente sur la même pull request : cette modification touche-t-elle un contrôle pour lequel votre entreprise est auditée, dans SOC 2, ISO 27001, le RGPD ou un autre cadre auquel vous êtes soumis ?
Cette question a rarement un propriétaire lors de la revue de code. La correction et la sécurité ont chacune des vérifications bien comprises ; savoir si une modification affecte un contrôle audité est une lecture distincte, et c'est celle qu'une vérification de conformité sur la pull request ajoute. Il est important d'être précis sur ce que cette vérification est et n'est pas.
Ce que c'est, et ce que ce n'est pas
Une vérification de conformité lit le diff, pas les résultats des tests. Elle associe la modification réelle au contrôle spécifique qu'elle affecte et signale ce contrôle par son nom, avec un niveau de détail vérifiable. Ce n'est pas une validation ou un échec de votre suite de tests, ni un seuil de couverture, ni un document de politique qu'un auditeur échantillonne une fois par an. C'est une lecture par modification pour savoir si la pull request devant vous a modifié quelque chose que vous êtes tenu de conserver.
Ce qui la rend utile, c'est la citation. « Cela semble non conforme » est du bruit. « Cela supprime le journal d'audit pour une action privilégiée, que ISO 27001:2022 A.8.15 exige de conserver » est quelque chose qu'un ingénieur peut traiter ou contester. Une vérification de conformité qui ne peut pas nommer le contrôle ne vaut pas la peine d'être ajoutée.
Trois modifications pertinentes pour les contrôles qui se cachent dans les pull requests de routine
Un élargissement de l'accès. Une pull request élargit un rôle IAM ou ouvre une nouvelle route vers une ressource. Le code est correct et peut être parfaitement sûr, mais il élargit qui peut accéder aux données protégées, ce qui est précisément l'objet de SOC 2 CC6.1 (contrôles d'accès logique). Cela peut sembler une modification de configuration de routine alors que le contrôle qu'elle affecte reste non identifié.
Un journal d'audit affaibli. Un nettoyage supprime ou réduit une ligne de journal qui se trouvait être l'enregistrement d'une action privilégiée. Rien ne casse, et cela peut sembler un nettoyage inoffensif, mais la preuve qu'un auditeur échantillonne sous ISO 27001:2022 A.8.15 (journalisation) a maintenant disparu. La modification qui l'a causé est l'endroit le moins coûteux pour la détecter.
Un nouveau stockage de données personnelles sans limite. Une migration ajoute une table qui commence à collecter des données personnelles sans limite de conservation. C'est du code propre et fonctionnel, et il vous place discrètement du mauvais côté de RGPD Art. 5(1)(e) (limitation de la conservation), qui exige que les données personnelles ne soient conservées que le temps nécessaire. Aucune de ces trois modifications n'est un bug ou une vulnérabilité. Chacune est une modification pertinente pour les contrôles qui se cache dans une pull request de routine.
Conseil par défaut, blocage uniquement si vous le choisissez
Une vérification de conformité qui bloque chaque fusion à la moindre découverte habitue les gens à l'ignorer ; une qui ne bloque jamais rien finit par être ignorée. Le paramètre par défaut utile est le conseil : la vérification publie le contrôle et la clause sous forme de commentaire et avec un statut neutre, afin que la découverte soit visible sans interrompre la fusion. La décision de bloquer relève de votre politique de protection de branche, pas de l'outil.
Si un contrôle omis est réellement coûteux, par exemple tout ce qui touche au contrôle d'accès, à la cryptographie ou aux données personnelles, vous pouvez exiger la vérification via la protection de branche sur les dépôts ou les branches protégées où cela compte le plus, et la laisser en mode conseil ailleurs. Le mécanisme doit vous permettre de choisir la posture plutôt que de l'imposer à tout.
Comment en ajouter une
Une vérification de conformité s'exécute sur la pull request de la même manière que vos autres vérifications : elle se déclenche lorsqu'une PR est ouverte ou mise à jour, lit le diff par rapport aux cadres de référence que vous avez sélectionnés et au contexte de votre entreprise, et publie les contrôles qu'une modification touche avec la clause associée. La partie difficile n'est pas de remarquer qu'un changement a eu lieu ; c'est de nommer exactement quel contrôle a été modifié, correctement, c'est pourquoi les cadres de référence auxquels vous êtes soumis et votre propre contexte doivent alimenter la vérification.
heygrc est conçu pour être cette vérification sous forme d'application GitHub : installez-le, indiquez-lui vos cadres de référence et votre contexte une fois, et il examine chaque pull request pour l'impact sur la conformité, en publiant un statut de vérification neutre ainsi que des commentaires en ligne afin qu'il informe plutôt que de bloquer, sauf si vous décidez de l'exiger. Le guide de configuration couvre l'intégration en trois minutes.