Checklist de sécurité des pipelines CI/CD

Workflows

• Épinglez les actions tierces à un SHA de commit complet. GitHub y voit actuellement le seul moyen d'utiliser une action comme une release immuable. Un tag peut être modifié pour pointer vers un autre code. En mars 2025, la CISA a signalé que toutes les versions de tj-actions/changed-files avaient été compromises pendant trois jours.
• Donnez à GITHUB_TOKEN le moindre privilège. Par défaut, la lecture seule pour le contenu, et davantage par job.
• N'extrayez jamais de code non fiable dans pull_request_target. Ces workflows s'exécutent avec des secrets et des autorisations élevées.
• Tenez les entrées non fiables à l'écart des scripts. Transmettez les titres, les noms de branche et les autres valeurs contrôlées par les utilisateurs via une variable d'environnement au lieu de les développer dans une commande shell.
• Examinez les modifications des fichiers de workflow. Exigez une revue par un code owner pour .github/workflows.

Secrets

• Préférez les identifiants de courte durée. Utilisez OpenID Connect pour que les jobs obtiennent de votre fournisseur cloud des tokens de courte durée et à portée limitée, au lieu de clés de longue durée stockées comme secrets.
• Limitez les secrets à des environnements. Placez les identifiants de production derrière un environnement avec des relecteurs obligatoires.
• Renouvelez-les après un incident. Après la compromission de tj-actions, la CISA a conseillé de considérer les secrets exposés comme compromis et de les renouveler immédiatement.

Runners

• Utilisez des runners éphémères. Une machine neuve par job ne laisse rien derrière elle pour le suivant.
• Tenez les runners auto-hébergés à l'écart des dépôts publics. Selon GitHub, ils ne devraient presque jamais y être utilisés, car n'importe qui peut ouvrir une pull request sur le dépôt.
• Isolez les jobs. Un job ne doit pas pouvoir lire l'espace de travail ni les identifiants d'un autre job.

Réseau

• Contrôlez le trafic sortant. Autorisez les sources de paquets et les services dont un job a besoin et bloquez le reste, pour qu'une dépendance compromise ne puisse pas faire sortir de secrets. Comment une politique de trafic sortant arrête l'exfiltration
• Enregistrez les connexions. Conservez une trace de ce à quoi chaque job s'est connecté, pour pouvoir enquêter plus tard.

Dépendances

• Commitez les lockfiles. Les builds doivent résoudre les mêmes versions à chaque fois.
• Examinez les nouvelles dépendances. Vérifiez ce qu'une pull request ajoute avant de la fusionner.
• Soumettez les builds à des gates sur les résultats. Bloquez un build lorsqu'il récupère un paquet présentant une vulnérabilité critique connue, avant que l'artefact ne soit livré.

Preuves de build

• Enregistrez une SBOM de ce que le build a récupéré. Un scan de fichiers après coup décrit ce qui a été déclaré, pas ce que le build a utilisé.
• Signez la provenance. Reliez chaque artefact au build qui l'a produit, pour pouvoir vérifier plus tard que ce qui s'exécute est bien ce qui a été construit.
• Surveillez ce qui a été livré. Revérifiez les builds publiés lorsque de nouvelles vulnérabilités paraissent.

Quels outils couvrent quels points

Les scanners couvrent les points sur les dépendances, les outils de durcissement des pipelines couvrent les points sur les workflows, et les agents sur le runner ou un runner sécurisé couvrent les points sur le réseau et les preuves. CRACI est le runner : il applique une politique de trafic sortant qui bloque tout en cas d'échec, enregistre une SBOM de ce que chaque job a récupéré, permet aux gates de politique de bloquer un build en fonction des résultats, et renvoie les SBOM, les traces réseau et la provenance via son API. Il ne scanne ni le code ni les workflows. Voir le comparatif des outils de sécurité CI/CD pour savoir quel outil couvre quoi.

Sécurité des pipelines CI/CD : questions fréquentes

Qu'est-ce que la sécurité des pipelines CI/CD ?

C'est la protection des systèmes qui construisent et livrent votre logiciel : les définitions de workflow, les secrets qu'elles utilisent, les runners qui les exécutent, les dépendances qu'elles téléchargent et les artefacts qu'elles produisent. Un pipeline compromis peut livrer du code malveillant sous votre nom sans toucher à votre code source.

Pourquoi épingler les GitHub Actions à un SHA de commit ?

Les tags peuvent être modifiés pour pointer vers un autre code. GitHub indique qu'épingler une action à un SHA de commit complet est actuellement le seul moyen d'utiliser une action comme une release immuable. En mars 2025, la CISA a signalé que toutes les versions de tj-actions/changed-files avaient été compromises pendant trois jours.

Quelles autorisations donner à GITHUB_TOKEN ?

Le minimum dont chaque job a besoin. Réglez la valeur par défaut sur la lecture seule pour le contenu du dépôt et accordez davantage par job, uniquement là où un job en a besoin.

Le contrôle du trafic sortant est-il nécessaire en CI ?

Si vos jobs détiennent des secrets et exécutent du code tiers, oui. La plupart des jobs n'ont besoin d'atteindre qu'un ensemble connu de registres de paquets et de services. Une politique de trafic sortant bloque tout le reste : une dépendance compromise ne peut donc pas envoyer de secrets vers le serveur d'un attaquant.