Aller au contenu
DevSecOps Logo Stéphane ROBERT
Docs
Blog

Gestion des secrets

Mise à jour :

Un développeur commit “temporairement” un mot de passe de base de données pour tester son code. Trois ans plus tard, un attaquant scanne GitHub, trouve ce secret dans l’historique Git, et accède à la base de production. Le commit avait été supprimé, mais l’historique Git conserve tout.

85% des fuites de données impliquent des credentials compromis. La gestion des secrets n’est pas une option, c’est une nécessité.

Pourquoi les secrets sont une cible prioritaire

Un secret est toute information qui permet d’accéder à un système : mot de passe, clé API, token, certificat, clé SSH. Contrairement à une vulnérabilité logicielle qui nécessite une exploitation technique, un secret exposé donne un accès immédiat.

RisqueImpact
Secret dans le codeAccessible à tous ceux qui ont accès au repo (y compris l’historique)
Secret dans les logsVisible par les équipes ops, archivé, potentiellement public
Secret partagé par chatAucune traçabilité, impossible à révoquer proprement
Secret jamais rotéUn secret compromis reste valide des années
Secret trop permissifUn token admin quand un accès lecture suffit

Qui est concerné

ProfilResponsabilitéPriorité
DéveloppeurNe jamais commiter de secrets, utiliser des variables d’environnementQuotidienne
Ops / SREConfigurer les coffres-forts, automatiser la rotationCritique
DevSecOpsDétecter les secrets exposés, intégrer les scans CI/CDContinue
RSSIPolitique de gestion des secrets, audit de conformitéStratégique
Tech LeadRevue de code, culture équipe, choix d’outilsEncadrement

Comment fonctionne une gestion saine des secrets

Principe : séparation code/secrets

Le code source ne doit jamais contenir de secrets. Les secrets sont injectés au runtime depuis une source externe sécurisée.

Terminal window
# ❌ Mauvais : secret en dur
DB_PASSWORD="mon-super-mot-de-passe"


# ✅ Bon : référence à un coffre-fort
DB_PASSWORD=$(vault kv get -field=password secret/db/prod)

Cycle de vie d’un secret

  1. Génération : créer un secret fort (aléatoire, longueur suffisante)
  2. Stockage : coffre-fort chiffré avec contrôle d’accès
  3. Distribution : injection au runtime, jamais en clair dans les configs
  4. Utilisation : accès tracé, durée de vie limitée
  5. Rotation : changement régulier, automatisé si possible
  6. Révocation : suppression immédiate si compromission suspectée

Scénario concret : application web avec base de données

Situation : une API Node.js doit se connecter à PostgreSQL.

Mauvaise pratique :

// ❌ Secret en dur dans le code
const db = new Pool({
  password: 'prod-password-123'
});

Bonne pratique avec HashiCorp Vault :

// ✅ Secret injecté depuis l'environnement
const db = new Pool({
  password: process.env.DB_PASSWORD
});
# Injection via Kubernetes avec External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
spec:
  secretStoreRef:
    name: vault-backend
  target:
    name: db-credentials
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: secret/data/prod/db
        property: password

Vérification :

Terminal window
# Le secret n'apparaît pas dans les sources
grep -r "password" --include="*.js" .
# Résultat : aucune correspondance avec des valeurs en clair

Pièges courants

PiègeConséquenceSolution
Commiter “temporairement”L’historique Git conserve toutPre-commit hooks avec Gitleaks
Variables d’env non protégéesVisibles dans logs, dumps, /procCoffre-fort avec injection runtime
Partage par Slack/emailAucune traçabilité ni révocationCoffre-fort avec accès partagé
Jamais de rotationSecret compromis = accès permanentRotation automatique (Vault, AWS SM)
Même secret partoutDev compromis = prod compromisSecrets séparés par environnement
Token admin par défautSurface d’attaque maximaleMoindre privilège, scopes limités
Secrets dans les images DockerExtraits avec docker historyMulti-stage builds, injection runtime

Outils disponibles

Détection de secrets

Gitleaks Détection de secrets dans les dépôts Git, rapide et efficace
TruffleHog Scanner de secrets avec vérification active des credentials

Coffres-forts et gestionnaires

HashiCorp Vault Gestion centralisée des secrets avec rotation automatique
Mozilla SOPS Chiffrement de fichiers de configuration (YAML, JSON)
Infisical Plateforme moderne de gestion des secrets pour équipes
Passbolt Gestionnaire de mots de passe open source pour équipes

Outils à explorer

OutilUsageFournisseur
AWS Secrets ManagerSecrets AWS avec rotation automatiqueAmazon
Azure Key VaultGestion clés/secrets écosystème AzureMicrosoft
Google Secret ManagerSecrets GCP avec IAM intégréGoogle
Kubernetes SecretsSecrets natifs K8s (chiffrer etcd !)CNCF
Ansible VaultChiffrement des variables AnsibleRed Hat
VaultWardenAlternative légère à BitwardenOpen source

À retenir

  1. Jamais dans le code — les secrets sont injectés au runtime depuis un coffre-fort
  2. Détection continue — scannez chaque commit avec Gitleaks ou TruffleHog en CI
  3. Rotation automatique — un secret a une durée de vie limitée
  4. Moindre privilège — chaque secret donne accès au strict nécessaire
  5. Audit et traçabilité — sachez qui accède à quoi, quand, et pourquoi

Liens utiles

Guides internes

Ressources externes