Gestion des changements sur GitHub : en faire une preuve pour ISO/IEC 27001 (ISMS) et SOC 2

Lorsqu'une équipe de développement passe un audit ISMS (le système de management de la sécurité de l'information au sens d'ISO/IEC 27001) ou SOC 2, la gestion des changements fait presque toujours partie des questions. Tout le code est sur GitHub, les revues sont faites. Et pourtant, c'est un domaine où l'on bute souvent sur « que montrer, et comment ? ».

Cet article commence par clarifier ce que l'auditeur cherche à vérifier en matière de gestion des changements, puis présente les réglages à mettre en place côté GitHub et la manière de conserver les preuves.

Ce que l'auditeur cherche à vérifier

Les exigences concernées sont les suivantes.

Aucun des deux ne dit « configurez GitHub de telle manière ». La question est de savoir si vous pouvez démontrer, par des enregistrements, que les changements ont été réalisés conformément à la procédure que vous avez définie.

Dans la pratique, la vérification suit le plus souvent ce déroulé :

1. On vous demande la liste des changements passés en production pendant la période d'observation
2. L'auditeur prélève un échantillon de changements dans cette liste
3. Pour chaque changement prélevé, il vérifie qu'une personne autre que son auteur l'a approuvé avant sa mise en production
4. S'il y a eu des changements urgents, il vérifie qu'une approbation et des enregistrements a posteriori existent

Il vous faut donc la liste des changements sur toute la période, et la trace de l'approbation de chaque changement. Si l'un des deux manque, l'explication devient difficile.

Les réglages à mettre en place sur GitHub

Avant même de parler de preuves, imposez la procédure elle-même par la configuration de GitHub. Plutôt que de simplement écrire des règles dans un document, rendez-les impossibles à contourner techniquement : l'explication en audit n'en sera que plus courte.

Sur la branche qui part en production (main, par exemple), configurez via la protection de branche ou un ruleset :

• Exiger une pull request avant toute fusion : fermer la voie par laquelle un push direct modifierait le code de production
• Exiger au moins une approbation : impossible de fusionner sans l'approbation d'une personne autre que l'auteur
• Annuler les approbations en cas de nouveau push : empêcher d'ajouter discrètement des modifications après l'approbation
• Ne pas exempter les administrateurs : si seuls les administrateurs peuvent contourner la protection, vous ne pouvez plus affirmer que « tous les changements ont été approuvés »
• Interdire la réécriture forcée de l'historique (force push) et la suppression de branche

En parallèle, précisez dans votre procédure de gestion des changements « quelle branche correspond à la production » et « en cas d'urgence, qui approuve, comment, et ce qui doit être consigné a posteriori ». La cohérence entre la configuration et la procédure est elle aussi examinée en audit.

Pourquoi les captures d'écran ne suffisent pas

Une manière courante de fournir des preuves consiste à faire des captures d'écran des pull requests ou de la page de configuration de la protection de branche, puis à les coller dans un document. Cette méthode a des faiblesses structurelles.

• Elle ne montre qu'un instant. Une capture de la page de configuration prouve seulement que le réglage était en place au moment où elle a été prise. Si la protection a été retirée puis rétablie en cours de période, ce fait n'apparaît pas
• La date et la provenance sont difficiles à vérifier. La date visible sur l'image fait partie de l'image ; un tiers n'a aucun moyen de vérifier quand et d'où elle a été obtenue
• La collecte demande du travail à chaque fois. Retrouver et capturer l'écran correspondant à chaque changement échantillonné est un travail qui se répète à chaque audit

Du côté des auditeurs aussi, la tendance est de plus en plus à privilégier, plutôt que ces preuves manuelles, des enregistrements horodatés automatiquement et traçables.

Conserver un historique sur toute la période

Deux points sont essentiels.

1. Enregistrer le changement au moment où il se produit. Au lieu de rassembler les éléments juste avant l'audit, enregistrez quand, qui et quoi dès qu'un push ou une fusion de pull request a lieu. Une collecte a posteriori ne permet pas de retrouver ce qui a disparu ou changé entre-temps.

2. Conserver les enregistrements sous une forme que l'organisation auditée ne peut pas réécrire après coup. L'historique des événements et le journal d'audit de GitHub sont pratiques, mais ces enregistrements résident dans un système géré par l'organisation évaluée elle-même. Leur durée de conservation est en outre plafonnée et, selon l'offre, peut ne pas couvrir une période d'observation de 6 à 12 mois. Il est utile de vérifier une fois la durée de conservation applicable à votre offre.

Pour montrer que les enregistrements n'ont pas été modifiés après coup, on chaîne l'empreinte (valeur de hachage) de chaque enregistrement à celle du précédent. Si un seul enregistrement intermédiaire est modifié, tous les maillons suivants cessent de concorder : toute altération est donc détectable.

Ce que SPHIOR fait, et ce qu'il ne fait pas

L'intégration GitHub de SPHIOR réalise automatiquement les deux points ci-dessus.

• Elle enregistre des événements tels que les push, la création et la fusion de pull requests, au moment où ils se produisent
• Chaque enregistrement contient le type d'événement, la personne qui l'a déclenché, l'heure à laquelle il s'est produit, ainsi que l'empreinte de l'intégralité du contenu reçu de GitHub. Le contenu lui-même n'est pas conservé
• Les enregistrements sont scellés en chaînant leurs empreintes, de sorte que toute altération est détectable. Vous pouvez exporter un pack de vérification et contrôler vous-même

En revanche, SPHIOR ne couvre pas les points suivants.

• L'acte d'approbation de la revue lui-même n'est pas enregistré à ce jour. Pour l'approbation, imposez via la protection de branche décrite plus haut l'impossibilité de fusionner sans approbation, et appuyez votre explication sur cette configuration et sur votre procédure
• SPHIOR ne se prononce pas sur l'issue de l'audit. Ce qu'il fournit, ce sont des preuves complémentaires destinées à être présentées à l'auditeur

L'offre gratuite conserve les enregistrements pendant 90 jours. Lorsque vous avez besoin des enregistrements couvrant toute la période d'observation, vous pouvez passer à une offre à durée de conservation plus longue (Tarifs).

En résumé

• En gestion des changements, on vous demande la liste des changements de la période et la trace de l'approbation de chacun
• Sur GitHub, imposez l'approbation par la protection de branche, sans exception pour les administrateurs
• Une capture d'écran ne montre qu'un instant. Le plus sûr est d'enregistrer chaque événement au moment où il se produit, sous une forme non réécrivable

Pour ne pas avoir à multiplier les captures d'écran dans l'urgence juste avant l'audit, le plus simple est de commencer à enregistrer bien avant.