Contrôles automatiques et signature

La leçon sur le DevSecOps désigne comme premier palier « les crochets de pré-commit pour les secrets : trente minutes ». Voici ce geste, en détail.

Crochets client et crochets serveur

Un crochet (hook) est un script que Git exécute à un moment donné du cycle. Ceux du client vivent dans .git/hooks/ — et ce répertoire n'est pas versionné, ce qui est le point à comprendre.

Un crochet client est une commodité : il donne un retour en deux secondes, au meilleur moment. Ce n'est pas un contrôle de sécurité, puisque --no-verify suffit à le sauter et qu'un nouveau venu ne l'a même pas installé.

La garantie vient du serveur, ou de la chaîne d'intégration. C'est exactement la distinction entre barrière et garde-fou de Bloquer n'est pas sécuriser : le crochet client guide, le contrôle serveur garantit. Il faut les deux, pour des raisons différentes.

# .pre-commit-config.yaml — versionné, donc partagé
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks

La version est épinglée : un crochet exécute du code tiers sur le poste des développeurs, à chaque commit. C'est une dépendance comme une autre, avec la même exigence d'épinglage que dans la chaîne d'approvisionnement.

Détecter un secret avant qu'il n'entre

Un outil de détection compare le contenu ajouté à des motifs connus — formes de clés d'API, blocs de clé privée, entropie élevée. Il produit des faux positifs, et c'est acceptable : le coût d'une alerte injustifiée est sans commune mesure avec celui d'une clé publiée.

Rappel de l'hygiène du dépôt : si le secret est déjà poussé, on révoque d'abord. La détection sert à ce que ce cas n'arrive pas.

Signer ses commits

git config --global commit.gpgsign true
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub

Signer prouve qu'un commit vient bien du détenteur d'une clé. Sans signature, les champs auteur et validateur sont du texte libre : rien n'empêche de commiter au nom de quelqu'un d'autre. C'est une manipulation d'une ligne.

La forge affiche alors « vérifié » pour les commits dont la clé est enregistrée.

Le piège classique

Signer les commits et signer les artefacts sont deux maillons différents de la même chaîne. La signature de commit couvre l'amont — qui a écrit ce code ; la signature d'artefact couvre l'aval — qui a produit ce binaire, ce dont parle la chaîne d'approvisionnement. L'une ne remplace pas l'autre : entre les deux, il y a une chaîne d'intégration, qui est elle-même une surface d'attaque.