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.

Pre-commit Security Hooks

devsecops

Définition

Les Pre-commit Security Hooks sont des scripts exécutés automatiquement par le gestionnaire de hooks Git (ou le framework pre-commit) avant chaque commit, vérifiant que les modifications apportées ne contiennent pas de secrets (credentials, tokens, clés API), de fichiers sensibles, ou d'autres problèmes de sécurité immédiatement détectables. En DevSecOps, les pre-commit hooks représentent le premier filet de sécurité de la chaîne — ils bloquent l'introduction de problèmes de sécurité au moment le plus proche de leur création, avant même que le code n'atteigne un dépôt. Le framework pre-commit (pip install pre-commit) standardise la configuration et le partage des hooks via un fichier .pre-commit-config.yaml versionné dans le dépôt. Cette approche garantit que tous les développeurs d'un projet utilisent les mêmes hooks, dans les mêmes versions, sans configuration manuelle par poste de travail. Les hooks se téléchargent automatiquement depuis leurs sources (GitHub) lors du premier pré-commit install. Les hooks de sécurité essentiels pour un projet DevSecOps incluent : detect-secrets (Yelp) qui maintient une baseline des "secrets" connus dans le dépôt et détecte tout nouveau secret non référencé, gitleaks qui scanne les modifications avec des règles regex pour les patterns de secrets communs (AWS access keys, GitHub tokens, passwords), ou truffleHog qui utilise une analyse d'entropie pour détecter les secrets non-typés. Ces hooks sont complétés par des hooks de qualité de code (flake8, eslint) et de formatage (black, prettier) qui constituent le "shift-left" complet. La gestion des faux positifs dans les pre-commit hooks est cruciale pour l'adoption : trop de faux positifs poussent les développeurs à désactiver les hooks. detect-secrets gère les faux positifs via une baseline (detect-secrets baseline .secrets.baseline — initialise la liste des "faux positifs" connus à ignorer), et les hooks peuvent être bypassés pour les cas légitimes avec git commit --no-verify (déconseillé mais possible), avec traçabilité dans les logs de commit.

Configuration .pre-commit-config.yaml pour DevSecOps

Configuration pre-commit optimale pour DevSecOps : repos: - repo: https://github.com/Yelp/detect-secrets rev: v1.4.0 hooks: - id: detect-secrets args: ['--baseline', '.secrets.baseline'] - repo: https://github.com/gitleaks/gitleaks rev: v8.18.0 hooks: - id: gitleaks - repo: https://github.com/antonbabenko/pre-commit-terraform rev: v1.83.0 hooks: - id: terraform_checkov - id: terraform_tfsec Installation : pre-commit install (active les hooks pour le repo courant), pre-commit run --all-files (scan de tous les fichiers existants lors de l'adoption initiale).

Detect-secrets : gestion de la baseline

Detect-secrets gère les faux positifs via une baseline : detect-secrets scan > .secrets.baseline (initialise la baseline listant tous les "secrets" actuels, encodés et référencés — y compris les faux positifs intentionnellement ignorés). Les entrées de la baseline sont revues par un humain et committées dans Git — elles documentent explicitement pourquoi chaque "secret" détecté est un faux positif. Lors des commits suivants, detect-secrets ne signale que les nouveaux secrets non présents dans la baseline. Pour mettre à jour la baseline après des modifications légitimes : detect-secrets scan --baseline .secrets.baseline.

Adoption et culture des pre-commit hooks

L'adoption des pre-commit hooks dans une équipe nécessite : 1) Commencer avec un ensemble minimal de hooks (detect-secrets uniquement) pour minimiser la friction initiale. 2) Ajuster la configuration pour minimiser les faux positifs (baseline bien configurée). 3) Automatiser l'installation (Makefile: make setup installe pre-commit + hooks). 4) Intégrer les mêmes checks dans la CI (pre-commit run --all-files dans le pipeline — filet de secours si un développeur bypasse les hooks locaux). 5) Former l'équipe sur l'utilité et le fonctionnement. La friction des pre-commit hooks est acceptable si le ratio signal/bruit est maintenu élevé (>90% de vrais positifs).

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis