L'audit est l'endroit où vous le découvrez. Le pull request est l'endroit où c'est arrivé. Entre ces deux moments, souvent séparés par des mois, un contrôle qu'un auditeur échantillonnera a cessé de fonctionner, et personne ne l'a remarqué, car le changement qui l'a rompu ne ressemblait pas à un changement de conformité. Il ressemblait à un nettoyage.
Voici sa forme. Le contrôle est l'ISO 27001:2022 A.8.15, le journalisation. Le changement est une ligne supprimée.
Le changement
Un pull request nettoie une fonction qui met à jour le rôle d'un utilisateur. Il y a un appel de journalisation au milieu que l'auteur considère comme du bruit, il se déclenche à chaque changement de rôle et encombre la sortie, donc il est supprimé. La fonction fonctionne toujours. Les tests passent toujours. Le diff est une ligne plus court et, si quelque chose, plus propre.
async function updateRole(actor, target, role) { await db.roles.set(target, role)- await audit.log("role.update", { actor, target, role }) return ok()}Cette ligne était l'enregistrement d'audit pour un changement des droits d'accès. L'A.8.15 (journalisation) exige que les événements pertinents pour la sécurité, y compris les changements de privilèges, soient enregistrés et conservés, et l'A.8.16 (surveillance) dépend de l'existence de cet enregistrement. La supprimer élimine la seule preuve qu'un rôle a jamais changé.
Pourquoi personne ne l'a remarqué
Un relecteur qui examine ce diff voit une ligne de journalisation supprimée. Pour repérer le problème, il devrait savoir que cette ligne de journalisation spécifique est la preuve d'un contrôle, que le contrôle est l'A.8.15, et que l'A.8.15 est dans le périmètre de leur certification. Ce sont trois éléments de connaissance du cadre qu'un relecteur de code n'a pas en tête lorsqu'il approuve un refactorisation de routine.
Voici le problème. Le point de contrôle est au bon endroit, la revue de code examine déjà chaque changement, intentionnellement, avant qu'il ne soit déployé. Ce qui manque, c'est la conscience du cadre pour reconnaître qu'une ligne en apparence ordinaire est porteuse pour un audit.
Ce que cela coûte plus tard
Si cela est détecté ici, c'est un retour en arrière d'une ligne et une conversation de trente secondes. L'auteur a encore tout le changement en tête. Si cela est détecté lors de l'audit, c'est une exception : le contrôle n'a pas fonctionné pendant la période, et maintenant quelqu'un doit reconstruire quand la journalisation a cessé, ce qui en dépendait, et comment la restaurer en toute sécurité, sous pression, éventuellement après le départ de l'auteur.
Le coût d'un écart de conformité est déterminé par une seule chose : combien de temps il est resté là avant que quelqu'un ne le remarque. Le pull request est l'endroit le moins coûteux pour le remarquer.
L'essentiel
La conformité échoue dans un PR de cinq lignes, pas lors de l'audit. L'audit est un indicateur retardé d'une décision prise par quelqu'un dans un diff des semaines plus tôt. heygrc est conçu pour lire ce diff par rapport aux cadres que vous devez respecter et identifier le contrôle qu'un changement touche, A.8.15, sur le pull request, alors que la correction est encore peu coûteuse.