Comment prouver la gestion des changements à partir de GitHub pour SOC 2 ou ISO 27001 ?
l'équipe heygrc
Dans une large mesure, oui, si les paramètres sont correctement configurés. Un workflow de pull request enregistre déjà ce qui a changé (le diff), qui l'a révisé et approuvé, ce qui a été exécuté avant la fusion (les vérifications), et quand la fusion a eu lieu (le commit de fusion). SOC 2 CC8.1 et ISO 27001 A.8.32 exigent que les changements soient autorisés, testés, approuvés et traçables, et un dépôt bien géré fournit la plupart de ces preuves sans outil supplémentaire. Ce qu'il ne fournit pas gratuitement, c'est la preuve de l'application des règles (preuve que les approbations ne peuvent pas être contournées) et la correspondance entre chaque changement et le contrôle qu'il affecte. Ce sont ces éléments que vous devez ajouter.
Laissez la protection de branche porter la partie autorisation
La gestion des changements repose sur deux questions : chaque changement a-t-il été autorisé, et pouvez-vous le prouver. La pull request montre l'instance ; la protection de branche montre la règle. Exigez des pull requests avec au moins une approbation (deux lorsque la séparation des tâches est importante), exigez les vérifications de confiance, et exigez une révision des code owners pour les chemins critiques. Un auditeur échantillonnant CC8.1 ou A.8.32 demandera comment vous savez qu'un changement non révisé ne peut pas atteindre la branche main : les paramètres de protection montrent la règle telle qu'elle est aujourd'hui, chaque approbation est une instance de son application, et si la règle a changé pendant la période d'audit, le journal d'audit du dépôt (modifications des règles et des protections) est l'endroit où vous montrez quand.
Faites de chaque pull request un enregistrement de changement
Le corps de la PR explique pourquoi, le diff montre quoi, les exécutions de vérification prouvent qu'il a été testé, l'approbation indique qu'une deuxième personne l'a accepté, et le commit de fusion indique quand le changement a été fusionné. La date de déploiement effectif relève d'un enregistrement de déploiement (une release, un environnement, une exécution de déploiement), que la gestion des changements traite comme une étape distincte, non prouvée par la fusion. Gardez les pull requests suffisamment petites pour qu'une révision soit une vraie révision, liez le ticket ou l'issue pour la justification métier, et ne poussez pas directement vers la branche protégée même si c'est possible, car c'est le moyen de contourner la révision que vous imposez à tous les autres. Un historique propre n'est pas une question de vanité : c'est la population qu'un auditeur échantillonne.
Sachez ce que GitHub ne prouve pas
Trois lacunes. Un force-push peut réécrire l'historique sur les références non protégées, et les administrateurs peuvent contourner certaines protections, donc l'histoire de l'application des règles a des limites ; mentionnez-les honnêtement plutôt que de surestimer. La conservation a aussi des limites : supprimez le dépôt et les enregistrements des pull requests disparaissent avec lui, et les journaux de GitHub (journal d'audit de l'organisation, journaux Actions) expirent après une période limitée, variable selon le plan, donc exportez ce dont votre période d'audit a besoin avant qu'ils ne le fassent. Enfin, rien dans l'enregistrement de la pull request ne lie un changement au cadre : CC8.1 n'étiquette pas un diff et A.8.32 ne commente pas une pull request. Cette correspondance est ce qu'une révision de conformité par PR ajoute (heygrc publie des constats qui nomment la clause), en construisant la traçabilité contrôle-changement au même endroit où le changement réside déjà.
# Revisers par défaut pour l'ensemble du dépôt* @acme/devs+ /security/ @acme/securityAvec une protection de branche exigeant une révision des code owners, les changements sous /security/ sont acheminés vers l'équipe sécurité pour approbation. Protégez également le fichier CODEOWNERS lui-même de la même manière, sinon la règle peut être affaiblie dans une pull request ordinaire. Autorisation pour les chemins à risque, écrite dans un fichier qu'un auditeur peut lire.
Associé