Sécuriser une pipeline

Une pipeline est un moteur d'exécution qui a accès à tout ce qui compte : vos secrets — mots de passe, clés d'API, jetons —, votre code source, et vos environnements de production. Si elle est compromise, l'attaquant injecte du code malveillant dans tout ce que vous livrez sans jamais toucher directement à vos serveurs. C'est empoisonner la source plutôt que chaque verre.

La pipeline comme surface d'attaque

Une chaîne d'intégration concentre trois choses qu'un attaquant recherche : des identifiants vers la production, un droit d'écriture sur les artefacts livrés, et une exécution de code automatique que personne ne relit. C'est la combinaison, plus que chaque élément isolé, qui en fait une cible de premier plan.

Quatre ressources, un seul point d'entrée.

Les quatre piliers

La sécurité d'une pipeline repose sur quatre piliers. Chacun correspond à une décision de confiance qui doit être explicite et vérifiable.

Négliger un pilier suffit : les quatre portent la même chaîne.

Pilier 1 — identités et permissions

La question n'est pas de savoir si la pipeline doit s'authentifier, mais avec quoi et pour combien de temps. Un secret de longue durée reste valable après le départ de son auteur, et après la compromission qui l'a fait fuiter.

Moindre privilège

{Chaque job n'obtient que ce dont il a besoin — rien de plus.}
# À ÉVITER : tous les droits, pour tout le monde
permissions: write-all

# CORRECT : le strict necessaire
permissions:
  contents: read      # lire le code, pas le modifier
  packages: write     # publier des paquets, rien d'autre

Jetons éphémères plutôt que secrets permanents

OIDC permet de demander un jeton temporaire à chaque exécution, au lieu de stocker un secret permanent.

Séparation par environnement

Les secrets de staging doivent différer de ceux de production : si un secret de développement fuite, la production reste protégée. C'est le même principe que celui posé au chapitre , appliqué ici comme contrôle de sécurité et non comme commodité.

Pilier 2 — dépendances

Le code que vous écrivez ne représente qu'une fraction de ce qui s'exécute. Le reste vient de paquets tiers dont vous ne contrôlez ni les mainteneurs, ni les mises à jour, ni les scripts d'installation. Chaque npm install, chaque pip install, chaque action tierce est du code qui s'exécute avec les permissions de votre pipeline.

Épingler par empreinte, pas par tag

Un tag comme @v4 est mutable : le mainteneur peut le déplacer à tout moment. Une empreinte SHA est immuable.

{Le tag désigne une intention   l'empreinte désigne un contenu.}
# À ÉVITER : tag mutable, peut changer sans prevenir
- uses: actions/checkout@v4

# CORRECT : empreinte immuable, toujours le meme code
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

L'empreinte se relève sur la page des publications du dépôt de l'action : on copie le SHA complet du commit correspondant à la version voulue.

Versionner les fichiers de verrouillage

Le fichier de verrouillage est une mesure de sécurité autant qu'une mesure de reproductibilité.

Auditer avant d'ajouter

Quatre questions à se poser avant d'ajouter une ligne à un fichier de dépendances.

Pilier 3 — runners et isolation

Le runner exécute le code de vos jobs avec ses propres droits, sur sa propre machine. Tout ce qu'il conserve d'une exécution à l'autre — cache, identifiants, fichiers temporaires — devient accessible au job suivant, y compris s'il provient d'une contribution externe.

L'éphémérité supprime le vecteur principal de contamination d'un job à l'autre.

Deux mesures complètent l'éphémérité. L'isolation réseau : le runner n'accède qu'aux ressources strictement nécessaires, jamais au réseau interne par défaut. La séparation des contextes : quand une personne extérieure ouvre une demande de fusion depuis un fork, le code qu'elle propose s'exécute sur vos runners — il ne doit jamais voir vos secrets.

Par défaut, certaines plateformes donnent accès aux secrets même depuis un fork : c'est à vérifier explicitement.

Pilier 4 — artefacts et chaîne de confiance

Entre la construction d'un artefact et son déploiement, rien ne prouve par défaut qu'il s'agit du même contenu. Sans empreinte vérifiable ni signature, un remplacement en cours de route est indétectable par celui qui l'installe.

Signer, c'est apposer une empreinte qui rend toute modification ultérieure détectable.

Deux compléments à la signature. L'attestation de provenance décrit comment l'artefact a été construit : quel commit, quelle pipeline, dans quel environnement, avec quelles dépendances. Le SBOM — inventaire logiciel — énumère tous les composants inclus, comme la liste des ingrédients sur un emballage : quand une vulnérabilité majeure est publiée, vous savez en quelques secondes si vos artefacts sont concernés.

Trois preuves distinctes : l'origine, le procédé, le contenu.

Contrôles structurels et contrôles ponctuels

Il existe deux types de contrôles, et ils ne se valent pas. Les contrôles ponctuels sont des vérifications exécutées à un moment précis : scan de vulnérabilités avant déploiement, analyse statique, tests de sécurité sur une demande de fusion. Leur limite : un contrôle ponctuel peut être contourné, désactivé, ou simplement oublié. Les contrôles structurels sont des contraintes architecturales qu'on ne peut pas contourner.

Privilégiez le structurel : le ponctuel est un filet supplémentaire, pas un rempart.

Modèle de maturité

Pour aller plus loin

Huit points d'entrée pour approfondir, du modèle de garanties à l'outillage.