La conformité appartient à la pull request.
Nous appelons cette pratique la revue de conformité pour les pull requests : examiner chaque modification par rapport aux cadres que votre entreprise doit respecter, dans la diff, et non des mois plus tard lors d'un audit. Ces essais sont les arguments derrière cette catégorie. Courts, argumentés et écrits pour les personnes qui modifient réellement le système : les ingénieurs et les ingénieurs en sécurité.
- 00
Revue de conformité pour les pull requests.
La revue de code se divise en plusieurs axes : la justesse, la sécurité, et désormais la conformité. Cet essai définit ce troisième axe comme une catégorie et explique pourquoi il émerge aujourd'hui.
- 01
Détectez-le dans la PR, pas lors de l'audit.
Un écart de conformité coûte moins cher à corriger au moment où il est écrit, et bien plus cher le jour où un auditeur le découvre.
- 02
La conformité est une vérification CI, pas un exercice d'urgence trimestriel.
Traiter la conformité comme un événement que l'on survit deux fois par an explique pourquoi cela ressemble à un exercice d'urgence. Traitez-la comme une vérification qui s'exécute à chaque modification et elle deviendra ennuyeuse, ce qui est l'objectif.
- 03
Votre linter est aveugle aux cadres de conformité.
Les linters et les scanners détectent les défauts et les classes de vulnérabilités. Une modification peut être un code irréprochable et pourtant violer une obligation de conformité, car l'obligation n'est pas une propriété du code, mais une propriété du cadre.
- 04
Les contrôles vivent dans les diffs, pas dans les documents Word.
Un contrôle écrit dans un document de politique est une intention. Le contrôle n'est réel que là où le système en cours l'applique, et le système en cours change une diff à la fois.
- 05
L'audit est un indicateur retardé.
Un audit vous indique ce qui était vrai il y a plusieurs mois. Si c'est le seul signal que vous avez, vous pilotez un système en regardant dans le rétroviseur.