Les ingénieurs qui s'engagent dans une première certification ISO 27001 imaginent souvent une immense audit de code, ou un certificat que l'on obtient comme un test. Ce n'est ni l'un ni l'autre. ISO/IEC 27001:2022 est une norme de système de management. Vous construisez un système de management de la sécurité de l'information (politiques, traitement des risques, rôles, fournisseurs, incidents, et le reste). Un organisme de certification accrédité audite ce système et, s'il est conforme, délivre un certificat. Le dépôt GitHub n'est pas l'objet de la certification.
Cette page traite de la petite partie qui se trouve effectivement dans le dépôt : les contrôles technologiques de l'Annexe A qu'une pull request peut affaiblir discrètement. C'est le pendant ISO 27001 des guides "ce qu'il vérifie réellement" pour SOC 2 et HIPAA. Ce n'est pas le catalogue des contrôles (c'est le hub du cadre), et ce n'est pas la question "existe-t-il une application GitHub" (c'est une réponse à part entière).
Le certificat n'est pas un scan de dépôt
Un rapport SOC 2 Type II est l'opinion d'un cabinet d'expertise comptable indépendant sur le fait que vos contrôles, tels que vous les avez décrits, étaient convenablement conçus et ont fonctionné efficacement sur une période donnée. Un rapport de Type I ne porte que sur la conception à un moment donné. Un certificat ISO 27001 accrédité est différent en nature : un organisme de certification accrédité atteste que votre système de management est conforme à la norme. Aucun des deux n'est un scan statique du code source. Aucun n'est délivré par une application GitHub. Si un fournisseur implique que l'installation d'un examinateur "vous obtient ISO 27001", ils décrivent un produit différent de la norme.
L'annexe A de l'ISO/IEC 27001:2022 liste 93 contrôles répartis sur quatre thèmes (organisationnels, personnes, physiques, technologiques). Vous n'implémentez pas les 93 comme une liste de contrôle de code. La Déclaration d'Applicabilité enregistre les contrôles que vous avez déterminés comme nécessaires, pourquoi ils sont inclus, s'ils sont mis en œuvre, et pourquoi tout contrôle de l'annexe A est exclu. L'annexe A est un ensemble de référence auquel vous vérifiez ces décisions, et non un menu de 93 éléments à implémenter dans le code. La plupart des 93 n'apparaissent jamais dans une diff : contrats de fournisseurs, bureaux physiques, dépistage des RH, papier de traitement des risques. Traiter les 93 comme un audit de dépôt est la mauvaise granularité.
La partie de l'Annexe A qui vit dans le code
Le thème technologique (A.8) comporte 34 contrôles. Même là, seulement quelques-uns apparaissent régulièrement dans une pull request : journalisation (A.8.15), surveillance (A.8.16), cryptographie et gestion des clés (A.8.24), restriction de l'accès (A.8.3), force de l'authentification (A.8.5), configuration correspondant à une ligne de base (A.8.9), codage sécurisé (A.8.28), gestion des changements (A.8.32), et sauvegarde d'informations (A.8.13). Si vous pouvez raisonner sur qui peut atteindre quoi, comment ils prouvent qui ils sont, ce qui est journalisé, comment les secrets sont conservés, et si un changement est toujours passé par le processus que vous avez écrit, vous raisonnez sur la plupart de la surface orientée code.
Le reste de A.8 (réseaux, capacité, logiciels malveillants, horloges, et ainsi de suite) est réel, mais il est généralement décidé dans l'architecture et les opérations, et non dans une pull request d'application de deux lignes. Le hub du cadre liste les déclencheurs. Cette page est le modèle mental : ISO 27001 dans un dépôt, ce sont ces formes de A.8, et non le certificat ni la liste complète de l'Annexe A.
Un chemin privilégié qui supprime discrètement un deuxième facteur
Une équipe de support ne peut pas créer un jeton API pendant un incident car la route d'administration nécessite une authentification multifactorielle et le téléphone de garde est dans un casier. Une pull request supprime la vérification du deuxième facteur et laisse le cookie de session comme seule barrière. Les tests restent verts. Le code est plus court. Les commentaires de révision concernent le débloquage de l'incident. Après la fusion, toute personne pouvant obtenir une session valide peut créer un jeton privilégié sans le facteur supplémentaire que le chemin exigeait auparavant.
ISO 27001:2022 A.8.5 concerne la force de l'authentification. Une action privilégiée qui nécessitait auparavant un deuxième facteur et qui n'en nécessite plus qu'un seul est plus faible après la fusion. Le fait que cela soit acceptable (une exception documentée et temporaire pour un incident par rapport à un trou permanent) est une décision de risque pour l'équipe. Le rôle de la révision est de nommer le contrôle afin que la décision soit prise intentionnellement. A.8.3 (restriction de l'accès) peut s'y ajouter si le jeton est la manière dont l'accès est accordé.
Le changement inverse, remettre requireMfa sur la route, ou faire passer la frappe de jetons d'incident par un chemin de secours qui est enregistré et expire, est peu coûteux sur la PR. Laisser le chemin plus faible en place est la version coûteuse : six mois plus tard, un échantillonneur d'organisme de certification peut demander comment les actions privilégiées sont authentifiées, et le contexte est perdu.
Où heygrc s'intègre, et la limite d'honnêteté
heygrc est une application GitHub qui examine chaque pull request par rapport aux cadres que vous avez sélectionnés et cite le contrôle de l'Annexe A qu'un changement touche, par exemple A.8.5 sur le contournement de MFA ci-dessus, ou A.8.15 lorsqu'une action privilégiée n'est plus journalisée. Elle ne vous certifie pas. Elle n'exécute pas votre ISMS. Elle ne rédige pas la Déclaration d'Applicabilité, ne choisit pas l'organisme de certification, ni ne délivre de certificat. Ni heygrc ni ISMS Copilot ne détient une certification ISO 27001. Utilisez-la comme réviseur du changement, et non comme système de management.
Si la question que vous avez réellement posée était "existe-t-il une application GitHub pour ISO 27001", la réponse courte est oui, et elle vit sur sa propre page. Ce guide est l'autre moitié : ce que cette application examinerait, et pourquoi la plupart d'ISO 27001 n'apparaîtra jamais dans le diff.