Comment auditer la sécurité de vos dépôts GitHub en 7 étapes — guide complet 2026

En 2026, un dépôt GitHub est bien plus qu'un simple hébergeur de code source. C'est une surface d'attaque complète : secrets stockés dans l'historique, dépendances transitives vulnérables, workflows CI/CD qui disposent de permissions cloud étendues, tokens d'accès à durée de vie illimitée. D'après le rapport GitHub Security 2025, plus de 39 millions de secrets ont été détectés dans les dépôts publics sur la seule année 2024. Pour les développeurs français travaillant sur des projets open source à Paris, Lyon, Nantes ou Bordeaux, auditer systématiquement la sécurité de vos dépôts n'est plus une option — c'est une obligation professionnelle et, dans certains secteurs, une exigence réglementaire (NIS2, Cyber Resilience Act).

Ce guide vous donne une procédure complète en 7 étapes, testée sur des dizaines de dépôts chez nos clients francophones. Chaque étape est actionnable immédiatement avec des outils gratuits et open source. Que vous gériez un dépôt personnel ou une organisation GitHub avec 50 dépôts privés, la méthode est la même — seule l'échelle change.

Étape 1 : Scanner les secrets exposés (tokens, clés API, mots de passe)

La première et la plus urgente des étapes. Les secrets exposés dans l'historique Git représentent la vulnérabilité numéro un des dépôts GitHub. Même si vous avez supprimé un fichier .env dans un commit ultérieur, le secret reste présent dans l'historique — et n'importe qui avec un accès au dépôt peut le récupérer. GitHub a détecté 39 millions de secrets en 2024 dans les dépôts publics. Pour les dépôts privés d'entreprises françaises, nos audits révèlent en moyenne 3 à 8 secrets exposés par dépôt, incluant des clés AWS, des tokens Stripe et des mots de passe de bases de données.

Scanner l'historique complet avec truffleHog

truffleHog de Truffle Security est l'outil de référence pour scanner l'intégralité de l'historique Git. Il détecte plus de 800 types de secrets et effectue une validation active — il teste si le secret est encore valide en contactant le fournisseur concerné.

# Installer truffleHog
pip install trufflehog

# Scanner l'historique complet d'un depot local
trufflehog git file://. --only-verified --json > secrets-audit.json

# Scanner un depot GitHub distant
trufflehog github --repo https://github.com/org/repo --only-verified

# Scanner toute une organisation GitHub
trufflehog github --org mon-organisation --only-verified --json > org-secrets.json

# Compter les secrets trouves par type
cat secrets-audit.json | jq -r '.DetectorName' | sort | uniq -c | sort -rn

Configurer git-secrets pour bloquer les futurs commits

git-secrets d'AWS Labs agit comme un hook pre-commit qui bloque tout commit contenant des patterns de credentials. C'est votre première ligne de défense préventive :

# Installer git-secrets
brew install git-secrets   # macOS
# ou
git clone https://github.com/awslabs/git-secrets.git && cd git-secrets && make install

# Configurer pour le depot courant
cd /chemin/vers/votre/depot
git secrets --install
git secrets --register-aws   # patterns AWS par defaut

# Ajouter des patterns personnalises
git secrets --add 'STRIPE_SECRET_KEY'
git secrets --add 'sk_live_[a-zA-Z0-9]{24,}'
git secrets --add 'mongodb+srv://[^@]+@'

# Tester la configuration
git secrets --scan

Activer GitHub Secret Scanning

Si votre dépôt est hébergé sur GitHub (public ou privé avec GitHub Advanced Security), activez Secret Scanning natif. Il détecte automatiquement les tokens de plus de 200 fournisseurs et peut même révoquer certains tokens en temps réel via les partenariats de GitHub. Pour les dépôts publics, cette fonctionnalité est gratuite. Pour les dépôts privés, elle nécessite une licence GitHub Advanced Security ou un plan Enterprise.

Si des secrets sont détectés, la procédure immédiate est : 1) révoquer le secret compromis chez le fournisseur concerné, 2) générer un nouveau secret et le stocker dans un gestionnaire de secrets (GitHub Secrets, HashiCorp Vault, AWS Secrets Manager), 3) nettoyer l'historique Git avec git filter-repo ou BFG Repo-Cleaner. Ne vous contentez jamais de supprimer le fichier dans un nouveau commit — l'historique conserve tout.

Étape 2 : Auditer les dépendances et le lockfile

Les dépendances transitives sont le vecteur d'attaque supply chain le plus courant. Votre projet peut dépendre de 20 packages directs, mais ces 20 packages entraînent 200 à 500 dépendances transitives — chacune étant un point d'entrée potentiel pour un attaquant. Les attaques comme event-stream, ua-parser-js et colors.js ont démontré la fragilité de cette chaîne d'approvisionnement.

Scanner les vulnérabilités connues

# Node.js / npm
npm audit --production
npm audit --json > npm-audit-report.json

# Python / pip
pip install pip-audit
pip-audit --strict --output json > pip-audit-report.json

# Go
govulncheck ./...

# Rust
cargo audit

# Multi-langage avec osv-scanner (Google)
osv-scanner --lockfile package-lock.json
osv-scanner --lockfile requirements.txt
osv-scanner -r .   # scan recursif

Vérifier l'intégrité du lockfile

Le fichier package-lock.json, yarn.lock ou poetry.lock est votre ancre de confiance. Vérifiez qu'il est toujours committé dans le dépôt et qu'il n'est pas listé dans le .gitignore. Un lockfile absent signifie que chaque installation peut résoudre des versions différentes — un vecteur classique pour les attaques par confusion de dépendances.

# Verifier que le lockfile est suivi par Git
git ls-files package-lock.json yarn.lock pnpm-lock.yaml

# Verifier la coherence lockfile <-> package.json
npm ci --dry-run 2>&1 | grep -i "error\|warn"

# Detecter les dependances qui pointent vers des registres non standard
grep -E '"resolved":\s*"https?://(?!registry\.npmjs\.org)' package-lock.json

Configurer Dependabot ou Renovate

Pour maintenir vos dépendances à jour automatiquement, configurez Dependabot (natif GitHub) ou Renovate (plus configurable). Créez un fichier .github/dependabot.yml à la racine du dépôt :

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    open-pull-requests-limit: 10
    reviewers:
      - "equipe-securite"
    labels:
      - "dependencies"
      - "security"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    labels:
      - "ci"
      - "security"

Notez que Dependabot doit également surveiller vos GitHub Actions (ecosystem github-actions). Nous aborderons ce point en détail à l'étape 4. Pour un guide plus approfondi sur l'audit des dépendances npm, consultez notre article dédié sur l'audit de dépendances npm et la sécurité supply chain.

Étape 3 : Vérifier les permissions et accès au dépôt

Un dépôt peut avoir un code parfaitement sûr mais être compromis par des permissions trop larges. L'audit des accès couvre trois dimensions : qui peut pousser du code, quelles branches sont protégées, et quels processus de review sont en place.

Auditer les collaborateurs et les tokens d'accès

# Lister les collaborateurs d'un depot avec leurs permissions
gh api repos/OWNER/REPO/collaborators --jq '.[] | {login: .login, role: .role_name}'

# Lister les tokens d'acces personnels (PAT) qui ont acces au depot
# (necessite les permissions admin)
gh api orgs/ORG/personal-access-tokens --jq '.[] | {owner: .owner.login, expires: .token_expired}'

# Lister les deploy keys
gh api repos/OWNER/REPO/keys --jq '.[] | {title: .title, read_only: .read_only, created: .created_at}'

# Lister les webhooks configures
gh api repos/OWNER/REPO/hooks --jq '.[] | {url: .config.url, events: .events, active: .active}'

Pour chaque collaborateur, vérifiez que le niveau d'accès correspond au principe du moindre privilège. Un développeur qui ne contribue plus depuis 6 mois devrait être retiré. Un prestataire externe devrait avoir un accès en écriture limité dans le temps. Les tokens d'accès personnels sans date d'expiration sont un risque majeur — privilégiez les fine-grained PAT avec une durée de vie de 90 jours maximum.

Configurer les branch protection rules

La branche main (ou master) doit être protégée avec au minimum ces règles :

• Require pull request reviews : au moins 1 review approuvée avant merge (2 pour les projets critiques).
• Require status checks : les tests CI doivent passer avant tout merge.
• Require signed commits : vérifie l'identité de l'auteur du commit (GPG ou SSH signing).
• Include administrators : les admins ne doivent pas pouvoir contourner les règles.
• Restrict push access : seuls les bots CI autorisés peuvent pousser directement sur main.

Mettre en place un fichier CODEOWNERS

# .github/CODEOWNERS
# Chaque modification de ces fichiers necessite une review de l'equipe securite

# Fichiers de configuration critique
.github/workflows/    @equipe-securite
.github/dependabot.yml @equipe-securite
Dockerfile            @equipe-securite @equipe-devops

# Code sensible (authentification, paiement)
src/auth/             @equipe-securite
src/payment/          @equipe-securite @lead-backend

# Infrastructure
terraform/            @equipe-devops @equipe-securite
k8s/                  @equipe-devops

Le fichier CODEOWNERS garantit qu'aucune modification des fichiers sensibles ne passe sans review de l'équipe compétente. Couplé aux branch protection rules, c'est un filet de sécurité indispensable pour les équipes de plus de 3 développeurs.

Étape 4 : Auditer les workflows GitHub Actions

Les workflows GitHub Actions sont l'un des vecteurs d'attaque les plus sous-estimés. Un workflow mal configuré peut exfiltrer des secrets d'environnement, modifier le code source via un bot, ou déployer du code malveillant en production. En 2025-2026, les attaques supply chain ciblant les GitHub Actions ont explosé — notamment l'incident tj-actions/changed-files qui a compromis plus de 23 000 dépôts. Pour un guide détaillé sur cette problématique, consultez notre article sur la sécurisation des pipelines CI/CD GitHub Actions.

4.1 — Épingler les actions tierces par hash SHA

Ne référencez jamais une action tierce par tag mutable (@v4, @main). Un attaquant qui compromet le dépôt de l'action peut modifier le code derrière le tag sans que vous ne le remarquiez. Épinglez chaque action par son hash SHA complet :

# MAUVAIS - tag mutable, vulnerable au tag hijacking
- uses: actions/checkout@v4

# BON - hash SHA immutable
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

# Verifier le hash d'une action
gh api repos/actions/checkout/git/ref/tags/v4.1.1 --jq '.object.sha'

4.2 — Configurer les permissions minimales

# Au niveau du workflow - permissions minimales par defaut
name: CI Pipeline
on: [push, pull_request]

permissions: read-all   # Defaut restrictif pour tout le workflow

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read       # Lecture du code uniquement
      checks: write        # Ecriture des resultats de tests
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

  deploy:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    permissions:
      contents: read
      id-token: write      # OIDC pour authentification cloud
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
        with:
          role-to-assume: arn:aws:iam::123456789:role/deploy
          aws-region: eu-west-3

4.3 — Sécuriser les self-hosted runners

Si vous utilisez des self-hosted runners, ils représentent un risque considérable : chaque workflow qui s'exécute dessus a potentiellement accès à la machine hôte, aux fichiers locaux et aux variables d'environnement. Les règles essentielles :

• Ne jamais utiliser de self-hosted runners sur des dépôts publics — n'importe quel fork peut déclencher un workflow.
• Utiliser des conteneurs éphémères — chaque job doit s'exécuter dans un conteneur frais, détruit après exécution.
• Isoler le réseau — le runner ne doit avoir accès qu'aux ressources strictement nécessaires.
• Utiliser OIDC au lieu de stocker des credentials longue durée sur le runner.

Pour approfondir la sécurisation des Actions, consultez également notre guide sur la protection des GitHub Actions contre les attaques supply chain en 6 étapes.

Étape 5 : Analyser le code avec SAST (Static Application Security Testing)

L'analyse statique de sécurité examine votre code source sans l'exécuter pour détecter les vulnérabilités : injections SQL, XSS, désérialisation non sûre, gestion incorrecte de la cryptographie, chemins de traversée de répertoires. Trois outils dominent l'écosystème en 2026 : CodeQL (GitHub), Semgrep (Semgrep Inc.) et SonarQube (SonarSource).

5.1 — Configurer CodeQL (gratuit pour les dépôts publics)

CodeQL est le moteur d'analyse sémantique de GitHub. Il modélise votre code comme une base de données relationnelle et permet des requêtes complexes pour détecter des patterns de vulnérabilités. Il est gratuit pour tous les dépôts publics et inclus dans GitHub Advanced Security pour les dépôts privés.

# .github/workflows/codeql-analysis.yml
name: "CodeQL Analysis"
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'   # Scan hebdomadaire le lundi a 6h

permissions:
  security-events: write
  contents: read

jobs:
  analyze:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        language: ['javascript', 'python']
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: security-extended   # Inclut les requetes de securite etendues
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3
        with:
          category: "/language:${{ matrix.language }}"

5.2 — Compléter avec Semgrep

Semgrep est un analyseur statique rapide et configurable qui supporte plus de 30 langages. Il est particulièrement efficace pour écrire des règles personnalisées adaptées à votre codebase. L'avantage de Semgrep par rapport à CodeQL : il est plus rapide à exécuter, plus simple à configurer, et son registre de règles communautaires couvre un large spectre de vulnérabilités.

# Installer Semgrep
pip install semgrep

# Scanner avec les regles de securite recommandees
semgrep --config auto --severity ERROR --severity WARNING .

# Scanner avec un ensemble specifique de regles
semgrep --config p/owasp-top-ten .
semgrep --config p/javascript .
semgrep --config p/python .

# Exporter les resultats en SARIF pour integration GitHub
semgrep --config auto --sarif --output semgrep-results.sarif .

# Integrer dans GitHub Actions
# .github/workflows/semgrep.yml
# name: Semgrep
# on: [push, pull_request]
# jobs:
#   semgrep:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v4
#       - uses: semgrep/semgrep-action@v1
#         with:
#           config: auto

5.3 — SonarQube pour une vue d'ensemble

SonarQube offre une vue consolidée de la qualité et de la sécurité du code avec des métriques de couverture, de dette technique et de vulnérabilités. La version Community est gratuite et suffisante pour un audit initial. Pour les équipes françaises travaillant dans des secteurs réglementés, SonarQube génère des rapports de conformité utiles pour les auditeurs.

La stratégie recommandée : utilisez CodeQL pour l'analyse sémantique profonde (il comprend les flux de données complexes), Semgrep pour les règles personnalisées et la vitesse d'exécution en CI, et SonarQube pour le tableau de bord consolidé et le suivi dans le temps. Ces trois outils sont complémentaires, pas concurrents.

Étape 6 : Vérifier la configuration du dépôt

Au-delà du code et des workflows, la configuration même du dépôt GitHub contient des paramètres de sécurité critiques souvent négligés. Cette étape vérifie l'hygiène générale du dépôt.

6.1 — Activer la signature des commits

La signature des commits garantit l'identité de l'auteur. Sans signature, n'importe qui peut usurper un nom d'utilisateur Git avec git config user.name. GitHub supporte la signature GPG et SSH :

# Configurer la signature SSH (plus simple que GPG)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

# Verifier qu'un commit est signe
git log --show-signature -1

# Dans les branch protection rules GitHub :
# Settings > Branches > Branch protection rules > Require signed commits

6.2 — Auditer les deploy keys et les webhooks

Les deploy keys sont des clés SSH associées à un dépôt spécifique. Vérifiez que chaque deploy key est en lecture seule sauf besoin explicite d'écriture, et que les clés obsolètes sont supprimées. Les webhooks envoient des notifications à des URLs externes à chaque événement du dépôt — vérifiez que chaque URL est légitime et que le secret du webhook est configuré pour valider l'authenticité des payloads.

# Lister les deploy keys et verifier leurs permissions
gh api repos/OWNER/REPO/keys --jq '.[] | "\(.title) | read_only=\(.read_only) | created=\(.created_at)"'

# Lister les webhooks et verifier les URLs cibles
gh api repos/OWNER/REPO/hooks --jq '.[] | "\(.config.url) | events=\(.events | join(",")) | active=\(.active)"'

# Verifier que les webhooks ont un secret configure
gh api repos/OWNER/REPO/hooks --jq '.[] | select(.config.secret == null or .config.secret == "") | .config.url'

6.3 — Vérifier les branch policies et les rulesets

Depuis 2024, GitHub propose les repository rulesets qui remplacent progressivement les branch protection rules. Les rulesets offrent plus de flexibilité : ils peuvent s'appliquer à plusieurs branches avec des patterns, cibler des tags, et être définis au niveau de l'organisation. Vérifiez que vos rulesets couvrent au minimum :

• Branches de production (main, release/*) : reviews obligatoires, status checks, signature de commits.
• Tags de release (v*) : restriction de création aux mainteneurs autorisés uniquement.
• Protection contre le force push et la suppression de branches sur main.
• Fichiers critiques verrouillés : .github/workflows/, Dockerfile, .github/CODEOWNERS ne peuvent être modifiés que par l'équipe sécurité.

Étape 7 : Documenter et automatiser l'audit récurrent

Un audit ponctuel a une valeur limitée. Le code change chaque jour, les dépendances se mettent à jour, de nouveaux collaborateurs rejoignent l'équipe, des workflows sont ajoutés. Pour que l'audit produise des résultats durables, il doit être documenté, automatisé et récurrent.

7.1 — Générer un SBOM (Software Bill of Materials)

Le SBOM est un inventaire complet de tous les composants logiciels de votre projet. Il est exigé par le Cyber Resilience Act européen pour les produits logiciels vendus dans l'UE à partir de 2027. Anticipez cette exigence dès maintenant :

# Generer un SBOM avec syft (format SPDX ou CycloneDX)
# Installer syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s

# SBOM au format CycloneDX (recommande par l'OWASP)
syft . -o cyclonedx-json > sbom-cyclonedx.json

# SBOM au format SPDX
syft . -o spdx-json > sbom-spdx.json

# Scanner le SBOM pour les vulnerabilites avec grype
grype sbom:sbom-cyclonedx.json --output json > vulnerabilities.json

# Integrer dans GitHub Actions
# .github/workflows/sbom.yml
# on:
#   release:
#     types: [published]
# jobs:
#   sbom:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v4
#       - uses: anchore/sbom-action@v0
#         with:
#           format: cyclonedx-json
#           output-file: sbom.json

7.2 — Créer une politique de sécurité (SECURITY.md)

Tout dépôt public doit avoir un fichier SECURITY.md qui explique comment signaler une vulnérabilité de manière responsable. Sans ce fichier, les chercheurs en sécurité qui découvrent un problème ne savent pas comment vous contacter — et certains publient directement le détail de la vulnérabilité dans une issue publique.

# SECURITY.md

## Politique de divulgation responsable

Merci de signaler les vulnerabilites de securite de maniere responsable.

### Comment signaler

- **Email** : security@votre-organisation.fr
- **GitHub Security Advisories** : utilisez l'onglet "Security" du depot
- **Delai de reponse** : 48 heures maximum pour un accuse de reception

### Perimetre

- Code source de ce depot
- Dependances directes
- Workflows CI/CD
- Infrastructure de deploiement

### Hors perimetre

- Attaques de type social engineering
- Vulnerabilites dans des services tiers

### Processus

1. Vous signalez la vulnerabilite via les canaux ci-dessus
2. Nous confirmons la reception sous 48h
3. Nous analysons et corrigeons sous 30 jours
4. Nous vous creditons dans l'advisory (si souhaite)
5. Nous publions le correctif et l'advisory

7.3 — Planifier des scans récurrents automatisés

Mettez en place un workflow GitHub Actions qui exécute l'ensemble des scans de sécurité de manière récurrente :

# .github/workflows/security-audit.yml
name: Security Audit Recurrent
on:
  schedule:
    - cron: '0 7 * * 1'   # Chaque lundi a 7h
  workflow_dispatch:        # Declenchement manuel possible

permissions:
  security-events: write
  contents: read

jobs:
  secrets-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
        with:
          fetch-depth: 0   # Historique complet pour truffleHog
      - name: Scan secrets avec truffleHog
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

  dependency-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
      - run: npm ci && npm audit --production --audit-level=high

  sast-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

  sbom-generation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
      - uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json

Ce workflow unique combine les quatre piliers de l'audit : secrets, dépendances, analyse statique et inventaire SBOM. Il s'exécute chaque lundi matin et peut être déclenché manuellement à tout moment. Les résultats remontent automatiquement dans l'onglet Security de votre dépôt GitHub.

Récapitulatif : les 7 étapes en un coup d'oeil

Pour les équipes françaises travaillant dans des secteurs réglementés — fintech à Paris soumise à DORA, healthtech à Lyon sous certification HDS, SaaS à Bordeaux ciblant le marché européen — cet audit n'est plus optionnel. Le Cyber Resilience Act et la directive NIS2 imposent une traçabilité complète de la supply chain logicielle, SBOM inclus, dès 2027. Les équipes qui mettent en place ces 7 étapes maintenant seront conformes sans effort supplémentaire.

Pour approfondir la sécurisation de vos pipelines, consultez nos guides spécialisés : sécuriser les pipelines CI/CD GitHub Actions et auditer les dépendances npm. L'OWASP Top 10 reste la référence incontournable pour prioriser les vulnérabilités applicatives, et la documentation GitHub Security couvre l'ensemble des fonctionnalités natives de la plateforme.

Conclusion : Auditer la sécurité d'un dépôt GitHub en 7 étapes est un investissement de 2 à 4 heures qui peut prévenir des compromissions coûteuses — fuite de credentials cloud, déploiement de code malveillant via un workflow compromis, exfiltration de données via une dépendance vérolée. Dans un contexte où les attaques supply chain se multiplient et où la réglementation européenne se durcit, chaque dépôt non audité est un risque accepté par défaut. Mettez en place les scans automatisés, épinglez vos actions par hash, activez la signature des commits, générez votre SBOM, et traitez chaque dépôt comme la surface d'attaque critique qu'il est devenu en 2026. Contactez D-Open si vous avez besoin d'un accompagnement pour sécuriser les dépôts de votre organisation.