Le dev a commité sur GitHub, le fichier config inclus contient le mot de passe de la BDD. C'est visible sur le repo public. Je fais quoi direct ?
J'ai changé le mot de passe dans la BDD, mais il est toujours visible dans l'historique GitHub. Je supprime l'historique des commits ?
On peut faire de la détection de secrets avec des outils automatisés ? Pour les repérer avant ?
Intervention en cas de fuite d'informations sensibles (Secret Leak) : une intervention rapide est cruciale. Étapes : 1) IMMÉDIAT (1-5 min) : a) Changer le mot de passe de la base de données, b) Révoquer l'accès au repo GitHub (vérifier les collaborateurs), c) Activer les alertes de secret scanning GitHub si disponibles (Settings → Security → Secret scanning), 2) COURT TERME (5-30 min) : a) Nettoyer l'historique Git (BFG Repo-Cleaner : bfg --delete-files 'config.yml' — réécriture de l'historique), b) Force push (git push --force-with-lease) — ATTENTION : coordination d'équipe requise, c) Vérifier les autres repos (grep -r password *.git), 3) ANALYSE (30-60 min) : a) Vérification du log Git (qui a push, quand), b) Logs d'accès (base de données) : y a-t-il des tentatives de connexion suspectes ?, c) Vérification AWS CloudTrail, GCP Cloud Audit Logs, 4) NOTIFICATION : a) Informer l'équipe (alerte de réécriture Git, rebase nécessaire), b) Équipe base de données (rotation des mots de passe). Outils de prévention : 1) .gitignore (exclure les fichiers de config), 2) Variables d'environnement (.env, ignoré par git), 3) Secret scanning GitHub (natif + tiers : TruffleHog, GitGuardian), 4) Hooks de commit (framework pre-commit : détecter les secrets avant le commit), 5) Scan automatique (CI/CD : scanner les commits pour des patterns). Réduction des risques : Logs d'accès à la base de données (IP suspectes, patterns de requêtes), Rate limiting API (prévention brute force), MFA sur la base de données (si supporté).
change le mot de passe direct dans la db. pour effacer l'historique sur github utilise bfg-repo-cleaner ou git-filter-branch. dis à l'équipe qu'il faut faire un git rebase. active le secret scanning sur github, bfg le fait automatiquement dans l'historique.....
Remédiation des secrets : 1) BFG Repo-Cleaner (bfg --replace-text passwords.txt --no-blob-protection repo.git), 2) git-filter-branch (legacy, plus lent mais précis), 3) Scan de secrets GitHub + révocation automatique (si token, auto-révocation), 4) Audit : git log -S 'password' --all (recherche dans les commits), 5) Notification : vérifier si des attaquants ont accédé à la base de données (logs de requêtes, tentatives de connexion échouées, géolocalisation IP). Implémentation de la prévention : hook pre-commit (framework pre-commit + plugins : detect-secrets, truffleHog), scan CI/CD (GitHub Actions : Trivy, GitGuardian), template .gitignore (.env, *.key, config.local.yml). Communication d'équipe : la réécriture de l'historique git nécessite que tous les utilisateurs fassent un force-pull + rebase (surcharge de coordination).
Doki · Application mobile · 2026
change le mot de passe direct utilise BFG pour effacer l'historique. préviens l'équipe qu'il faut un git rebase. active le secret scanning sur GitHub. installe un hook pre-commit (truffleHog, detect-secrets) pour détecter ça à l'avenir. ajoute un scan CI/CD...
Automatisation de la détection de secrets : 1) Pre-commit local (framework pre-commit + plugin detect-secrets) 2) Pipeline CI/CD (GitHub Actions, GitLab CI : TruffleHog, GitGuardian), 3) Scan de repository (scan de secrets natif GitHub, scan de sécurité GitLab) 4) Audit de l'historique Git (git-secrets, git-dumper). Automatisation de la réponse : Scan de secrets GitHub → auto-révocation (pour les tokens GitHub), alerte équipe, création d'un incident. Bonnes pratiques : template .gitignore (exclure *.key *.pem, .env, config/*local*), stratégie de variables d'environnement (tous les secrets depuis les variables d'env CI/CD jamais dans le code), service de gestion de secrets (HashiCorp Vault, AWS Secrets Manager).
Je suis une petite entreprise laissez-moi expliquer de mon point de vue. Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.
C'est confirmé par l'expérience.
Merci beaucoup, cela m'a été très utile. Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.
Voilà, désolé si je me suis étendu.
Séparons les concepts, ils sont souvent confondus. Si vous grondez les fausses alertes, plus personne ne signalera rien.
Corrigez-moi si je me trompe.
Doki · Identité de marque · 2026
Je vais raconter ce qui m'est arrivé, ça pourrait vous servir. L'erreur commise du côté de mot de passe oublié dans le code source est généralement réversible, mais coûteuse.
Commencez par un petit test, ne vous engagez pas sur tout d'un coup. Voilà, désolé si je me suis étendu.
Ce conseil ne convient pas à tout le monde, je pense. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.
Il faut faire une distinction ici. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.
À votre place, j'irais par cette voie.
Je suis une petite entreprise, laissez-moi expliquer de mon point de vue. Une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine.
Je vais raconter ce qui m'est arrivé, ça pourrait vous servir. Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.
Les gens défendent l'habitude, pas le processus. La résistance vient de là. C'est mon avis, je ne l'écris pas comme une vérité absolue.
En regardant le processus, le tableau change. La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.
Bien sûr, cela change si votre situation est différente.