"Bot de conformité pour GitHub" est une recherche que les utilisateurs effectuent lorsqu'ils veulent un outil qui s'intègre à leurs dépôts et signale les problèmes de conformité sans nécessiter l'ouverture d'une console GRC distincte. Les résultats sont un mélange d'outils partageant le mot "conformité" mais ayant peu d'autres points communs : des bots qui publient des commentaires de statut, des outils qui téléchargent les rapports de conformité de GitHub, des collecteurs de preuves qui vérifient si la protection des branches est activée, et des applications de chat sans lien avec la revue de code. Ce guide décrit la forme qui répond à l'intention réelle : un bot qui lit chaque pull request par rapport aux cadres sélectionnés et cite un contrôle au niveau du diff.
Ce guide est délibérément distinct du guide principal sur les vérifications de conformité dans les pull requests. Ce dernier explique ce qu'est une vérification de conformité (le concept : statut consultatif, citation de contrôle, choix de protection de branche). Celui-ci explique ce qu'est un produit de type bot de conformité (l'outil installable, la boucle d'événements, les autorisations et ce qu'il n'est pas).
Quatre choses que les gens entendent par "bot de conformité" (une seule correspond au produit)
Première : un chatbot ou un bot de ticket qui répond aux questions de politique dans Slack. Utile pour les personnes, mais pas pour les pull requests. Deuxième : un connecteur de reporting qui exporte les audits ou rapports de conformité de GitHub pour un auditeur. Il s'agit d'export de preuves, pas d'une lecture des modifications. Troisième : un collecteur de preuves ou une plateforme GRC qui vérifie si les paramètres de dépôt requis (protection des branches, revues obligatoires, commits signés) sont configurés. Il s'agit de preuves de processus pour la couche programme. Quatrième : une GitHub App qui, à chaque événement de pull request, examine le diff par rapport aux contrôles des cadres nommés et publie une revue ainsi qu'un statut de vérification optionnel. Seul le quatrième est un bot de conformité cartographié selon les cadres pour les pull requests.
Si vos résultats de recherche sont remplis des trois premiers, cela ne signifie pas que votre besoin est erroné. Le terme de catégorie pour le quatrième est encore nouveau : revue de conformité pour les pull requests. Un bot est simplement la manière dont cette revue est livrée sur GitHub.
Ce que le bot fait sur une vraie pull request
Lors de l'installation, le bot s'attache aux dépôts que vous choisissez. Lorsqu'une pull request est ouverte, mise à jour ou rouverte (selon le mode d'exécution configuré), il lit la modification, la compare aux cadres sélectionnés par votre organisation, et si un contrôle est concerné, il publie un commentaire de revue qui cite la clause (par exemple SOC 2 CC6.1 pour un rôle IAM élargi, ou GDPR Art. 5(1)(c) pour un journal capturant un enregistrement d'identité complet). Il peut également publier une vérification GitHub avec un statut neutre afin que la découverte soit visible sans bloquer la fusion par défaut.
Le paramètre par défaut utile pour un bot de conformité est consultatif : afficher le contrôle et laisser la décision de fusion à votre politique de protection de branche. Un bot qui bloque systématiquement chaque découverte incite les utilisateurs à l'ignorer. Un bot qui n'apparaît jamais dans le fil de revue est ignoré. Un statut neutre associé à une citation claire est la conception qui maintient le signal sans devenir du théâtre.
Ce qu'il n'est pas (pour éviter d'acheter le mauvais outil)
Ce n'est pas votre auditeur, votre avis SOC 2 ou un certificat. Ce n'est pas une plateforme GRC qui collecte des preuves à travers l'identité, les RH et le cloud pour toute la fenêtre d'observation. Ce n'est pas un scanner de secrets, un outil SAST ou un conseiller de dépendances, bien que ces outils partagent souvent le même fil de pull request et doivent continuer à fonctionner. Ce n'est pas un remplacement pour Bugbot, CodeRabbit ou tout autre réviseur de qualité de code : ceux-ci vérifient si le code est correct et sûr ; le bot de conformité vérifie si la modification affecte un contrôle qui sera évalué.
Si vous avez besoin d'automatisation des preuves au niveau du programme, achetez ou conservez une plateforme GRC. Si vous avez besoin de détections de vulnérabilités, conservez vos scanners de sécurité. Le travail du bot de conformité est de répondre à une troisième question sur la même pull request : ce diff affecte-t-il un contrôle, et lequel ?
Comment heygrc implémente cette forme
heygrc est une GitHub App qui effectue des revues de conformité pour les pull requests : installez-la sur les dépôts qui vous intéressent, sélectionnez les cadres, et elle publiera des découvertes avec citations de contrôles au niveau du diff. Les dépôts publics sont gratuits ; les dépôts privés commencent avec une allocation mensuelle gratuite et un essai illimité court lorsque vous revendiquez l'installation dans la console. Elle ne bloque jamais les fusions par défaut. Vous pouvez exiger la vérification dans la protection de branche vous-même si votre politique nécessite un verrouillage.
Voir un exemple en direct dans le dépôt de démonstration public, où des pull requests préparées montrent des revues réelles contre les contrôles SOC 2, ISO 27001 et GDPR sur du code synthétique propre. Pour le concept de la vérification elle-même, lisez le guide principal. Pour la configuration, lisez le guide d'installation orienté agent.