Gestion des changements, dans le pipeline.
CC8.1 est le critère SOC 2 relatif à la gestion des changements : les modifications apportées à l'infrastructure, aux données et aux logiciels doivent être autorisées, conçues, développées, testées et approuvées avant d'être mises en production. Une grande partie de cela réside dans votre pipeline et votre protection de branche, ce qui signifie qu'une pull request peut discrètement supprimer les contrôles qui régissent la manière dont les changements sont déployés.
The shapes the same control failure takes.
CC8.1 s'affaiblit lorsqu'un changement assouplit le processus censé régir les modifications. Les formes récurrentes :
Une approbation requise est supprimée
Une révision ou une étape d'approbation obligatoire avant un déploiement en production est retirée de la configuration CI ou de la protection de branche, permettant ainsi aux changements d'être déployés sans validation.
Une migration contourne la révision
Une migration de base de données ou une modification de données est configurée pour s'exécuter lors du déploiement sans révision ou approbation distincte pour un changement qui modifie les données de production.
Les tests ne bloquent plus la fusion
Une vérification de statut obligatoire (la suite de tests, une analyse de sécurité) est rendue non bloquante ou supprimée, permettant ainsi aux changements non vérifiés de fusionner.
Un chemin de contournement est ajouté
Un chemin d'urgence ou d'administration est ajouté, permettant à un changement d'atteindre la production en dehors du pipeline normal, sans contrôles équivalents.
Le rollback est supprimé
Un rollback sécurisé ou un chemin de migration inverse est retiré, permettant ainsi à un changement d'être déployé sans possibilité de retour en arrière propre si quelque chose ne va pas.
Une approbation de déploiement requise, supprimée.
Une approbation manuelle obligatoire avant les déploiements en production a ralenti les mises en production, donc un changement supprime la règle de protection. Les déploiements deviennent plus rapides, et désormais toute fusion dans main atteint la production sans que personne ne valide le changement.
jobs: deploy:- environment:- name: production # requires a reviewer approval steps:Supprimer l'approbation obligatoire pour l'environnement de production signifie que les changements atteignent désormais la production sans validation. CC8.1 exige que les changements soient autorisés et approuvés avant d'être mis en ligne. Si les approbations sont trop lentes, limitez qui ou ce qui en a besoin, ou automatisez les vérifications, mais conservez une étape d'approbation plutôt que de la supprimer.
La gestion des changements est échantillonnée à partir des changements réels.
Un auditeur échantillonne les changements qui ont été déployés en production et recherche les preuves que chacun a été révisé, testé et approuvé, souvent via la pull request, ses approbations et les vérifications réussies. Un changement qui a supprimé une approbation requise ou rendu un test non bloquant est la faille derrière ces preuves, et il est visible dans le diff de la configuration du pipeline ou de la protection de branche.
Une révision, pas votre processus de release.
heygrc signale les changements qui concernent CC8.1 et cite le critère afin que la correction ait lieu dans la pull request. Il n'exécute pas vos déploiements ni ne gère votre protection de branche. Il détecte le moment où un changement assouplit le processus qui régit les modifications, au niveau du diff.