La conformité en tant que code est l'idée selon laquelle une obligation de conformité doit être exprimée et vérifiée là où le système réside réellement, c'est-à-dire dans le dépôt et le pipeline, plutôt que uniquement dans un document de politique qu'un auditeur échantillonne une fois par an. Elle s'inspire de la démarche qui a fonctionné pour les tests et l'infrastructure : prendre quelque chose qui était manuel et périodique, et le rendre défini et continu.
Les trois éléments réellement nécessaires
Premièrement, l'obligation doit être nommée à un niveau de granularité vérifiable. « Améliorer notre posture de sécurité » n'est pas vérifiable ; « un changement de rôle privilégié doit être journalisé, conformément à l'ISO 27001:2022 A.8.15 » l'est. Deuxièmement, la vérification doit s'exécuter là où les modifications ont lieu, c'est-à-dire sur la pull request, et non dans un outil séparé que personne n'utilise. Troisièmement, lorsqu'elle signale quelque chose, elle doit indiquer quel contrôle est concerné et pourquoi, afin que l'ingénieur puisse agir sans devenir un expert en conformité.
La plupart des équipes disposent déjà du premier ingrédient dans leurs cadres de référence et du deuxième dans leur CI. Ce qui manque généralement, c'est la couche de traduction qui relie une modification de code concrète au contrôle spécifique qu'elle affecte.
Pourquoi le diff est l'unité appropriée
Un contrôle ne se dégrade pas selon un calendrier. Il se dégrade dès qu'une personne élargit un rôle, supprime un paramètre de chiffrement ou retire une ligne de journalisation. Chacune de ces actions est un diff. Si vous vérifiez la conformité au niveau du diff, vous détectez la dégradation au moment où elle est introduite, alors que l'auteur dispose encore du contexte pour la corriger à moindre coût.
C'est la même raison pour laquelle les tests s'exécutent à chaque modification plutôt qu'une fois par trimestre : le coût d'une régression augmente avec le temps écoulé entre son introduction et sa détection.
Où s'intègre heygrc
heygrc est conçu pour être cette couche de traduction : lire chaque pull request par rapport aux cadres de référence sélectionnés par votre entreprise et identifier le contrôle spécifique qu'une modification affecte, sous la forme d'un commentaire de révision avec la clause associée. Il n'est pas destiné à remplacer votre cadre de référence, votre auditeur ou votre jugement technique ; l'objectif est de rendre le contrôle visible au niveau du diff afin que la décision soit éclairée.