01Les OWASP Top 10 CI/CD Security Risks
Avec les Top 10 CI/CD Security Risks (v1.0, 2022), l'OWASP Foundation a catalogué de manière systématique les vulnérabilités typiques des environnements de build et de déploiement : « Insufficient Flow Control Mechanisms » (CICD-SEC-1), « Inadequate Identity and Access Management » (CICD-SEC-2), « Dependency Chain Abuse » (CICD-SEC-3), « Poisoned Pipeline Execution » (CICD-SEC-4), « Insufficient PBAC (Pipeline-Based Access Controls) » (CICD-SEC-5), « Insufficient Credential Hygiene » (CICD-SEC-6), « Insecure System Configuration » (CICD-SEC-7), « Ungoverned Usage of 3rd Party Services » (CICD-SEC-8), « Improper Artifact Integrity Validation » (CICD-SEC-9) et « Insufficient Logging and Visibility » (CICD-SEC-10). Ce catalogue constitue une grille d'analyse idéale pour une évaluation structurée de votre propre paysage de pipelines – que vous utilisiez GitHub Actions, GitLab CI/CD ou Jenkins.
02Poisoned Pipeline Execution (CICD-SEC-4)
Dans une Poisoned Pipeline Execution, un attaquant disposant d'un accès au système de gestion du code source manipule le processus de build sans avoir à compromettre l'environnement de build lui-même. L'OWASP distingue trois variantes : dans la Direct PPE (D-PPE), l'attaquant modifie directement le fichier de configuration CI ; dans l'Indirect PPE (I-PPE), il injecte du code dans des fichiers référencés tels que des makefiles ou des scripts de test ; la Public PPE (3PE) exploite les pull requests de contributeurs anonymes dans des dépôts publics. Contre-mesures efficaces : n'exécuter le code non vérifié que sur des runners isolés sans accès aux secrets, ne lancer les pipelines des contributeurs externes qu'après validation manuelle et charger les configurations CI depuis des branches protégées.
03Dependency Confusion et Dependency Chain Abuse (CICD-SEC-3)
« Dependency Chain Abuse » regroupe les attaques via la chaîne d'approvisionnement des paquets : dependency confusion, dependency hijacking, typosquatting et brandjacking. Dans la dependency confusion, l'attaquant publie dans un registre public un paquet portant le nom d'un paquet interne avec un numéro de version supérieur – si le gestionnaire de paquets résout la dépendance en privilégiant la source publique, le code malveillant se retrouve dans le build. Le chercheur en sécurité Alex Birsan a démontré cette technique en 2021 dans les systèmes de build de plus de 35 organisations, dont Apple, Microsoft et PayPal. Les contre-mesures : un proxy de registre interne comme source d'approvisionnement unique, le verrouillage des versions de paquets via des fichiers de lock avec vérification des sommes de contrôle et des signatures, des scopes d'organisation pour les paquets privés, ainsi que l'exécution des scripts d'installation dans des contextes isolés sans accès aux secrets.
04Secrets dans les pipelines : des identifiants OIDC éphémères plutôt que des secrets statiques
Les pipelines ont besoin d'accéder aux registres, aux environnements cloud et aux cibles de déploiement – les identifiants s'y accumulent donc naturellement. « Insufficient Credential Hygiene » (CICD-SEC-6) en décrit les conséquences : des secrets de longue durée, dotés de privilèges étendus, qui peuvent se retrouver dans des logs, des artefacts ou des dépôts forkés. Le levier le plus efficace est le passage à des identifiants fédérés et éphémères : via OpenID Connect (OIDC), la plateforme CI émet pour chaque job un jeton d'identité signé, que le fournisseur cloud vérifie au regard d'une relation de confiance préalablement définie et échange contre un jeton d'accès de courte durée, valable uniquement pour ce job et expirant automatiquement. Les identifiants cloud stockés de manière statique et la rotation manuelle disparaissent ainsi en grande partie ; le secret scanning et une gestion centralisée des secrets restent nécessaires en mesures d'accompagnement.
05Durcissement : runners à moindre privilège, branch protection, signatures
Le principe du moindre privilège s'applique aussi à l'environnement d'exécution : les runners ne devraient recevoir, par pipeline, que les autorisations strictement nécessaires et être idéalement exploités de manière éphémère, c'est-à-dire détruits après chaque job. Des règles de branch protection avec revues et status checks obligatoires empêchent que des modifications non vérifiées – y compris des configurations CI manipulées – n'atteignent la branche principale ; les commits signés garantissent la paternité des modifications. Les artefacts signés et les attestations de provenance permettent de vérifier cryptographiquement, avant le déploiement, qu'un artefact provient bien du pipeline attendu – avec Sigstore/Cosign, même en mode « keyless », via des certificats éphémères liés à une identité OIDC et le journal de transparence public Rekor. Vous traitez ainsi en même temps « Improper Artifact Integrity Validation » (CICD-SEC-9) ; contre « Insufficient Logging and Visibility » (CICD-SEC-10), la réponse est une journalisation exhaustive et analysée de manière centralisée de toutes les activités des pipelines.
06SLSA comme cadre de référence pour l'intégrité des builds
Supply-chain Levels for Software Artifacts (SLSA) est une spécification intersectorielle placée sous l'égide de l'OpenSSF (Linux Foundation), qui traduit les mesures de durcissement en niveaux vérifiables. Le Build Track définit les niveaux L1 à L3 : de la provenance générée automatiquement, documentant comment un artefact a été construit (L1), à la provenance signée d'une plateforme de build hébergée (L2), jusqu'aux builds durcis et isolés les uns des autres, dans lesquels le matériel de signature reste hors de portée des étapes de build définies par l'utilisateur (L3). La version actuelle 1.2 (statut « Approved », 11/2025) ajoute pour la première fois un Source Track, qui traite de l'intégrité de la gestion du code source. NIST SP 800-204D (02/2024) fournit des aides à la mise en œuvre complémentaires ; vous trouverez une analyse approfondie dans notre article de connaissances consacré à la sécurité de la chaîne d'approvisionnement SLSA.
