Recherchez SOC 2 dans les pull requests et vous trouverez surtout des listes de contrôle de processus : exiger des revues, des vérifications de statut et des commits signés. Ces paramètres comptent. Ils constituent des preuves qu’un processus de gestion des changements existe. CC8.1 (critères communs de gestion des changements) concerne aussi le fait de savoir si le contrôle a été appliqué pour un changement donné : le changement a-t-il été autorisé comme le prévoit votre politique, ou une correction urgente, un bot ou un chemin d’urgence a-t-il ignoré une étape requise.
Ce guide se concentre sur l’analyse au niveau des pull requests. Il ne réexplique pas la différence entre Type I et Type II (voir /guides/how-to-pass-soc-2-as-a-startup) et ne cartographie pas toute la famille CC6 d’accès (voir /guides/what-soc-2-actually-checks-in-your-repo). Il se concentre sur la gestion des changements au moment où une pull request est fusionnée.
La protection des branches est nécessaire, mais pas suffisante
Exiger une revue d’approbation et une vérification CI réussie est la base habituelle. Les auditeurs vérifient si ce processus a été appliqué pendant la fenêtre d’observation. Un dépôt avec une protection activée peut toujours produire des exceptions lorsqu’une personne fusionne avec une autorisation d’administrateur, lorsqu’un chemin de déploiement contourne la branche protégée, ou lorsqu’un compte automatisé fusionne sans l’approbation humaine que votre politique exige.
L’indice visible dans le code n’est pas toujours dans le code source de l’application. Il se trouve souvent dans les fichiers de workflow, CODEOWNERS, les scripts de déploiement ou une modification en une ligne de qui peut approuver. Ces changements apparaissent toujours sous forme de pull requests.
Exemple concret : chemin d’urgence qui ignore l’approbation requise
L’équipe d’astreinte est alertée. Un ingénieur ouvre une pull request qui ajoute un job workflow_dispatch avec continue-on-error et un chemin qui déploie en production depuis une fourche personnelle en utilisant un jeton à longue durée de vie, documenté comme « break-glass ». Une deuxième pull request le même jour modifie CODEOWNERS pour que ce chemin n’exige plus l’équipe plateforme. Les deux pull requests semblent être de la maintenance opérationnelle. Le code de l’application peut ne pas changer du tout.
Ce qui intéresse CC8.1, c’est de savoir si les changements en production passent toujours par le processus de changement autorisé. Un chemin break-glass qui affaiblit durablement les approbations requises est un changement de contrôle, pas seulement une commodité. Pendant une fenêtre de Type II, si l’auditeur échantillonne des déploiements ayant utilisé ce chemin sans l’approbation documentée, vous devrez expliquer une exception. Détecter les diffs de workflow et CODEOWNERS au moment de la revue est moins coûteux que de les expliquer six mois plus tard.
Lien avec la fenêtre d’observation (sans réexpliquer l’audit)
Pour le Type II, l’auditeur vérifie si les contrôles ont fonctionné sur une période. Une seule approbation ignorée pendant cette fenêtre peut devenir une exception échantillonnée, même si le reste de l’année était conforme. C’est pourquoi l’hygiène de la gestion des changements pendant la fenêtre n’est pas une bureaucratie pour elle-même : c’est ainsi que vous évitez de surprendre l’opinion pour laquelle vous avez passé des mois à vous préparer. Les détails de la préparation, de la définition du périmètre et de la sélection de l’auditeur restent dans le guide de processus SOC 2 pour les startups.
Une vérification de conformité dans une pull request qui cite CC8.1 sur une porte d’approbation affaiblie n’approuve pas l’urgence. Elle rend le changement de processus visible tant que la pull request est encore ouverte.
Rôle de heygrc et limite d’honnêteté
heygrc est conçu pour analyser les pull requests par rapport aux cadres que vous avez sélectionnés, y compris SOC 2 lorsqu’il est activé, et pour identifier des critères tels que CC8.1 lorsqu’un changement semble affaiblir la gestion des changements (portes d’approbation, vérifications requises, autorisation de déploiement). Il n’effectue pas votre audit, ne collecte pas de preuves IdP ou RH, ni n’émet d’opinion.
Gardez votre réviseur de qualité de code. CC8.1 concerne l’intégrité du processus pour le changement, pas la question de savoir si la correction urgente était élégante.