Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Branch Protection

devsecops

Définition

La Branch Protection (protection des branches) est un ensemble de contrôles de sécurité configurables dans les plateformes Git hébergées (GitHub, GitLab, Bitbucket, Azure DevOps) qui restreignent les opérations autorisées sur les branches importantes d'un dépôt (typiquement main, master, develop, release/*). Ces protections constituent un contrôle de sécurité fondamental dans les pipelines DevSecOps en garantissant que le code déployé en production a subi toutes les validations requises. Les règles de Branch Protection courantes incluent : l'obligation d'une Pull Request avant merge (prevention des pushs directs), le nombre minimum d'approbations de révision de code requises, la résolution obligatoire des commentaires de revue, le statut obligatoire des checks CI (tests, SAST, SCA) avant merge possible, la protection contre la suppression de branches, la protection contre les force-pushs (préservant l'historique), la nécessité d'une signature de commit (GPG ou SSH) pour les branches critiques, et les Linear History uniquement (pas de merge commits). L'implémentation des Branch Protection en tant que code (Protection Rules as Code) est une bonne pratique DevSecOps : les règles de protection sont définies dans des fichiers de configuration versionnés et appliquées via Terraform (ressource github_branch_protection), des API scripts, ou des outils comme Allstar (OpenSSF) qui maintient automatiquement les règles de sécurité sur les dépôts GitHub. Cette approche garantit la cohérence des protections entre dépôts et empêche les modifications manuelles non autorisées. GitHub a introduit les "Rulesets" (règles à portée organisation) qui permettent d'appliquer des règles de protection uniformes sur des groupes de dépôts sans configuration individuelle. Ces Rulesets supportent des conditions basées sur les noms de branches, les patterns de dépôts, et les rôles d'utilisateurs, offrant une gouvernance centralisée des politiques de protection du code. Les Branch Protection Rules s'intègrent dans un programme de sécurité DevSecOps plus large : elles travaillent de concert avec les Required Status Checks (obligeant le passage des contrôles SAST/SCA/tests), les CODEOWNERS (assignation automatique de reviewers), et les Deployment Protection Rules (validation avant déploiement en environnement sensible).

Règles de protection essentielles

Les règles de Branch Protection critiques pour les branches de production : Require pull request reviews before merging (min 2 approbations), Dismiss stale reviews when new commits are pushed (invalider les approbations précédentes sur nouveau commit), Require status checks to pass (CI tests + SAST + SCA), Require branches to be up to date before merging, Block force pushes, Restrict deletions. Ces règles combinées garantissent qu'aucun code non validé n'atteint la production.

Branch Protection as Code avec Terraform et Allstar

La gestion déclarative des Branch Protection évite la dérive de configuration entre dépôts. Terraform (provider github, ressource github_branch_protection) applique les règles de façon idempotente. OpenSSF Allstar est un bot GitHub qui monitore les dépôts d'une organisation et réenforce automatiquement les politiques de sécurité configurées (branch protection, code review, binary artifacts) en ouvrant des issues ou en bloquant les merges non conformes.

Required Status Checks et security gates

Les Required Status Checks permettent d'imposer le succès de checks CI spécifiques avant tout merge. En DevSecOps, cela inclut : les tests unitaires et d'intégration, les scans SAST (Semgrep, CodeQL), les scans SCA (Snyk, Dependabot), les scans de secrets (GitLeaks), et les validations de politique IaC (Conftest, Checkov). Ces checks forment le "security gate" du pipeline, refusant automatiquement les contributions ne respectant pas les standards de sécurité.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis