Protéger les branches Git et permissions entreprise

Protéger les branches Git et permissions entreprise

La branche principale d’un dépôt Git est un actif de sécurité : elle porte le code déployable, les politiques d’infrastructure et souvent les chemins d’accès aux secrets. La protéger ne consiste pas à cocher une règle de fusion, mais à rendre vérifiable qui peut modifier quoi, sous quelles preuves et avec quelle capacité de reprise.

Explication de la marmotte

Une branche principale ressemble au registre officiel d’un atelier : toute modification inscrite dedans peut finir dans les produits livrés. Les permissions et les validations servent à empêcher qu’une personne pressée, malveillante ou simplement très fatiguée change ce registre sans contrôle.

→ Lire l’explication complète de la marmotte

Branche principale et compromis de contrôle

Le compromis central est brutal : imposer des contrôles avant fusion ralentit les changements urgents, mais l’absence de contrôle transforme chaque permission d’écriture en droit de déploiement indirect. La recommandation est donc nette : aucune identité humaine ne doit pousser directement vers main, master, production ou toute branche qui alimente une livraison. Une exception temporaire doit être tracée, limitée dans le temps et révoquée après usage. Sinon, ce n’est pas une exception, c’est une porte de garage avec un post-it.

Git contrôle l’historique, pas l’intention. Un commit signé prouve qu’une clé a produit une signature sur un contenu donné. Il ne prouve ni que le détenteur de la clé était autorisé à modifier ce fichier, ni que le changement a été relu, ni que le pipeline a exécuté les bons tests. La sécurité de la branche résulte donc de plusieurs contrôles indépendants : authentification à la forge, autorisation sur le dépôt, règles de protection, revue, contrôles automatisés et journalisation.

La branche principale doit exiger les propriétés suivantes :

• interdiction des poussées directes, y compris pour les administrateurs par défaut ;
• fusion exclusivement par demande de changement, aussi appelée pull request ou merge request selon la forge ;
• au moins une approbation par une identité distincte de l’auteur ;
• réinitialisation des approbations après chaque nouveau commit ;
• exécution réussie des contrôles obligatoires sur le dernier commit de la demande ;
• interdiction des fusions lorsque la branche cible a avancé sans revalidation ;
• interdiction de la réécriture d’historique et de la suppression de la branche ;
• journalisation des changements de règles, des approbations et des fusions.

Le nombre d’approbations n’est pas un chiffre magique. Une approbation indépendante est suffisante pour un composant courant si l’équipe de relecture est réellement distincte de l’auteur. Deux approbations deviennent nécessaires pour les changements affectant l’authentification, les permissions, les politiques réseau, les pipelines ou les composants cryptographiques. Exiger trois validations sur chaque correction de typographie fabrique seulement une file d’attente et des approbations réflexes, ce merveilleux rituel où un pouce levé remplace la lecture.

Les règles de propriété de code, souvent exprimées par un fichier CODEOWNERS, complètent mais ne remplacent pas les protections de branche. Elles associent des chemins à des responsables de revue. Leur valeur est forte pour les répertoires d’infrastructure, les manifestes d’orchestration, les politiques d’accès et les pipelines. Leur limite est tout aussi forte : si la règle elle-même peut être modifiée et fusionnée sans approbation indépendante, elle protège aussi bien qu’un cadenas livré avec sa clé attachée.

Les pages développement et architecture cyber donnent le cadre voisin : la revue de code n’est pas une cérémonie qualité isolée, c’est un point de contrôle de la chaîne de confiance.

Permissions Git et séparation des rôles

Les rôles de forge doivent suivre le principe du moindre privilège. Lire un dépôt privé, créer une branche, approuver une demande et administrer les règles de protection sont quatre capacités distinctes. Les regrouper dans un rôle large est commode jusqu’au jour où un compte compromis modifie les contrôles qui devaient le limiter.

Le rôle d’administration du dépôt doit rester rare et ne jamais être attribué à des comptes de service utilisés par les pipelines. Un jeton de pipeline capable de modifier les règles de branche ou de créer des accès permanents transforme une compromission de chaîne d’intégration continue en prise de contrôle durable du dépôt. Le pipeline doit lire le code, publier des artefacts et éventuellement écrire des statuts de contrôle. Rien de plus.

Les comptes de service doivent être distincts des identités humaines. Leur jeton doit être limité à un dépôt ou à un groupe de dépôts, avec une durée de vie courte lorsque la forge le permet. Une clé Secure Shell (SSH) de déploiement en lecture seule ne doit jamais devenir une clé d’écriture « temporaire ». Temporaire est le mot préféré des privilèges qui prennent racine.

L’authentification multifacteur doit être obligatoire pour les membres capables de fusionner ou d’administrer un dépôt. L’accès par mot de passe seul ne résiste ni au hameçonnage ciblé ni à la réutilisation de mots de passe. Une fédération d’identité centralisée améliore la révocation, à condition que la forge refuse les comptes locaux de contournement ou que ceux-ci soient placés sous contrôle d’urgence documenté. Les sujets de fédération et de cycle de vie des identités relèvent directement de la section identités.

Les permissions de groupe méritent une revue périodique, au minimum trimestrielle et après tout changement d’organisation. L’inventaire doit couvrir les membres directs, les groupes imbriqués, les comptes de robots, les clés de déploiement et les jetons personnels. Les groupes imbriqués sont particulièrement dangereux : la forge affiche parfois un accès hérité sans exposer assez visiblement la chaîne qui l’a accordé.

Revue obligatoire et contrôles de fusion

Une demande de fusion doit être courte, ciblée et liée à un changement vérifiable. Cette contrainte n’est pas esthétique. Une revue de 2 000 lignes mélangeant une correction de sécurité, un renommage et une mise à jour de dépendance ne permet pas d’établir une décision de sécurité fiable. Les changements mécaniques doivent être isolés, sinon la relecture devient un exercice de divination assisté par écran.

Les contrôles automatisés obligatoires doivent être attachés à la branche protégée, pas seulement définis dans le pipeline versionné. Un contributeur capable de modifier la définition du pipeline dans sa propre branche peut supprimer un test avant de demander la fusion. La forge doit exiger les statuts nommés, produits par une exécution associée au commit exact. Si les statuts sont acceptés depuis n’importe quelle source, un jeton compromis peut publier un faux succès.

Au minimum, imposer :

• compilation et tests applicatifs ;
• analyse des dépendances avec seuil de blocage explicite ;
• détection de secrets sur l’historique et le différentiel ;
• analyse statique ciblant les familles de vulnérabilités pertinentes ;
• validation syntaxique des fichiers d’infrastructure ;
• contrôle de provenance des artefacts lorsque la chaîne le permet.

Un contrôle de secret qui détecte une clé après sa fusion n’empêche pas sa divulgation. Git réplique l’historique dans les clones, les miroirs, les caches et les archives. La suppression du fichier ne retire pas le secret des anciens objets. La réponse est alors une révocation ou une rotation immédiate, puis un nettoyage d’historique si nécessaire. La gestion de cette rotation doit suivre les principes documentés dans la section cryptographie, même quand la clé n’est pas stockée dans un module matériel.

La fusion doit être bloquée si la branche cible a changé depuis l’approbation, sauf si la forge recalcule explicitement les contrôles sur le résultat de fusion. Sans cela, une demande approuvée peut passer sur une base de code différente de celle relue. C’est un défaut de cohérence, pas une subtilité de produit.

Exemple de protection reproductible avec GitHub

L’interface de programmation applicative (API) GitHub permet d’appliquer une protection de branche de manière déclarative. Le jeton utilisé doit disposer du droit d’administration du dépôt, ce qui interdit de l’exécuter depuis le pipeline du dépôt protégé. L’opération doit être lancée depuis une identité d’administration dédiée et auditée.

#!/usr/bin/env bash
set -euo pipefail

# Préparer OWNER, REPO et GH_TOKEN dans l'environnement.
# GH_TOKEN doit être un jeton d'administration, jamais un secret de pipeline.
curl --fail-with-body \
  --request PUT \
  --header "Accept: application/vnd.github+json" \
  --header "Authorization: Bearer ${GH_TOKEN}" \
  "https://api.github.com/repos/${OWNER}/${REPO}/branches/main/protection" \
  --data '{
    "required_status_checks": {
      "strict": true,
      "contexts": ["build", "test", "secret-scan", "dependency-scan"]
    },
    "enforce_admins": true,
    "required_pull_request_reviews": {
      "dismissal_restrictions": {},
      "dismiss_stale_reviews": true,
      "require_code_owner_reviews": true,
      "required_approving_review_count": 1,
      "require_last_push_approval": true
    },
    "restrictions": null,
    "required_linear_history": true,
    "allow_force_pushes": false,
    "allow_deletions": false
  }'

enforce_admins est la ligne qui sépare la politique de l’aménagement permanent. Sans elle, un administrateur peut contourner les règles par une poussée directe. Dans certaines forges, cette option porte un autre nom ou exige une politique de fusion distincte : le résultat à vérifier reste identique, aucun rôle humain ne doit disposer d’un contournement silencieux.

La liste des statuts doit correspondre aux noms réellement émis par les pipelines. Renommer un job sans mettre à jour la règle peut soit bloquer toute fusion, soit pire, laisser une ancienne vérification vide satisfaire la règle. Tester la protection sur un dépôt de validation avant déploiement à grande échelle évite ce genre de petit incendie administratif.

Surface d’attaque, exploitation et reprise

La première attaque vise l’identité : hameçonnage d’un approbateur, vol de session, jeton personnel exposé ou compte d’administrateur mal fédéré. Les contre-mesures sont l’authentification multifacteur résistante au hameçonnage lorsque disponible, la durée de vie limitée des sessions, la révocation centralisée et l’alerte sur ajout de clé ou création de jeton.

La deuxième attaque vise le processus : collusion entre auteur et approbateur, approbation avant modification finale, contournement par branche non protégée ou modification de CODEOWNERS. La réinitialisation des approbations, la validation du dernier commit, la protection de tous les chemins de livraison et l’approbation des propriétaires de code réduisent cette surface. Elles ne détectent pas une revue complaisante : la séparation des rôles et la surveillance restent nécessaires.

La troisième attaque vise la chaîne automatisée : exfiltration d’un secret depuis un journal de pipeline, substitution d’action tierce, publication d’un statut frauduleux ou modification de l’image d’exécution. Les secrets ne doivent être injectés que dans des jobs protégés, jamais dans un pipeline déclenché par une contribution non fiable. Les dépendances de pipeline doivent être épinglées par version immuable ou empreinte cryptographique. « Latest » est une stratégie de gestion du changement déguisée en mot court.

La protection de branche ne garantit pas la qualité du code, l’absence de vulnérabilité, la sécurité d’un artefact ni la bonne configuration de production. Elle garantit seulement que les règles définies par la forge ont été satisfaites avant la modification d’une branche protégée. Les contrôles manquants doivent venir de l’analyse de sécurité, de la signature d’artefacts, des politiques de déploiement et de la supervision.

Les journaux d’audit doivent être exportés hors de la forge : changements de membres, de jetons, de clés, de règles de branche, d’approbations et de permissions. Conserver ces événements dans le même périmètre administré que le dépôt ne constitue pas une preuve robuste lors d’une compromission d’administrateur. La sauvegarde doit inclure les dépôts, les références, les paramètres de protection et les règles de propriété de code. Restaurer seulement les objets Git restaure le code, pas les garde-fous. C’est une moitié de reprise, donc une reprise qui attend son accident.

🐝 Ce qui arrive si on s’en passe

Sans protection de branche, la réécriture d’historique reste possible sur la branche livrée : un commit peut être poussé, déclencher une livraison, puis disparaître par une poussée forcée. L’artefact déployé référence alors une empreinte de commit absente de la branche, ce qui rend inopérants la recherche par dichotomie, l’attribution d’un changement à son auteur et la comparaison entre version livrée et code relu. Les clones existants divergent sans alerte, et une synchronisation ordinaire peut réintroduire ou effacer l’objet selon le poste. Les attestations de provenance perdent leur valeur : elles prouvent qu’un artefact vient d’un commit précis, sans que ce commit ait jamais satisfait une règle de revue. Tout consommateur qui suit la branche par son nom récupère le changement sans aucune décision intermédiaire.

🦫 Explication de la marmotte 🍫

Un dépôt Git conserve les fichiers d’un projet et l’historique de leurs modifications. Une branche principale contient la version destinée à être livrée ou déployée. Si une personne peut modifier cette branche sans contrôle, elle peut ajouter du code dangereux, retirer un test ou changer une configuration qui donne accès à des données.

La règle consiste à interdire les modifications directes. Une personne crée d’abord une branche séparée et propose ses changements. Une autre personne lit alors les modifications, vérifie leur but et donne ou refuse son accord. Des programmes exécutent aussi des vérifications : compilation, tests, recherche de mots de passe ou de clés copiés par erreur, et contrôle des dépendances utilisées.

La fusion vers la branche principale n’est autorisée que si les accords demandés et les vérifications attendues sont présents. Si l’auteur ajoute un nouveau changement après un accord, cet accord doit disparaître, car le contenu examiné n’est plus le même. Si la branche principale change entre-temps, les vérifications doivent recommencer sur la version finale.

Les droits sont séparés : lire le projet, proposer un changement, approuver et modifier les règles ne donnent pas le même pouvoir. Les accès, les clés de connexion et les jetons doivent être retirés quand ils ne servent plus. Les journaux gardent la trace des décisions. En cas d’échec d’un contrôle, la fusion s’arrête ; il faut corriger le changement ou restaurer les permissions avant de continuer.

À lire aussi

• Sécuriser un monorepo avec des permissions finesConcevoir des permissions à grain fin, des contrôles de fusion et une exploitation résiliente pour un monorepo partagé par plusieurs équipes.
• Sécuriser les secrets et permissions CI/CDSécuriser une pipeline CI/CD impose des secrets éphémères, des permissions minimales et une revue à quatre yeux réellement bloquante.
• Durcir les postes de développeurs contre le vol de code et secretsLes postes de développeurs constituent une cible souvent oubliée du durcissement, alors qu’ils concentrent code source, identités, secrets et accès de production.
• Intégration continue avec Git : automatiser vos workflowsGuide technique sur l'intégration continue avec Git, détaillant les configurations, cas d'usage, risques et bonnes pratiques pour automatiser vos workflows.

Pages voisines

La citent

• Configurer GitHub Actions OIDC vers AWS sans clé statique
• Installer et utiliser GitHub Copilot en mode agent

Protéger les branches Git et permissions entreprise

Elle cite

• ⇄Lien dans les deux sens :SLSA : niveaux Build, provenance in-toto et vérification
• Comptes de service Git à révoquer réellement
• OIDC, SAML et OAuth 2.1 en fédération

⇄ : les deux pages se citent l’une l’autre.