Aller au contenu
DevSecOps Logo Stéphane ROBERT
Docs
Blog

OWASP Top 10 CI/CD Security Risks

Mise à jour :

Les pipelines CI/CD (Intégration Continue / Déploiement Continu) sont devenus le cœur des processus de développement modernes. Ils automatisent l’intégration, les tests et le déploiement du code en production. Mais cette automatisation crée aussi une surface d’attaque considérable : un attaquant qui compromet votre pipeline peut injecter du code malveillant dans vos applications, voler vos secrets, ou perturber vos services en production.

L’OWASP Top 10 CI/CD Security Risks ↗ identifie les 10 risques majeurs qui menacent ces pipelines. Ce guide explique chaque risque, illustre les attaques réelles qui les exploitent, et propose des contre-mesures concrètes.

Surface d'attaque d'un pipeline CI/CD

Pourquoi sécuriser votre pipeline CI/CD ?

Un pipeline CI/CD compromis permet à un attaquant de :

  • Injecter du code malveillant directement dans vos artefacts de production
  • Voler des secrets (clés API, tokens, certificats) pour accéder à vos systèmes
  • Contaminer votre chaîne d’approvisionnement et tous vos clients en aval
  • Persister dans votre infrastructure via des backdoors indétectables

Attaques récentes : pourquoi ces risques sont réels

Avant d’analyser chaque risque, voici quatre attaques majeures qui illustrent la criticité de la sécurité CI/CD :

Attaque de la chaîne d’approvisionnement SolarWinds

Des attaquants (probablement étatiques) ont compromis le pipeline CI/CD de SolarWinds pour injecter une backdoor dans les mises à jour du logiciel Orion.

Impact : 18 000 organisations infectées, dont des agences gouvernementales américaines et des entreprises Fortune 500.

Risques OWASP exploités :

  • CICD-SEC-1 : Insufficient Flow Control Mechanisms
  • CICD-SEC-10 : Insufficient Logging and Visibility

Les 10 risques de sécurité CI/CD selon OWASP

Catégories des risques OWASP CI/CD

CICD-SEC-1 : Insufficient Flow Control Mechanisms

Mécanismes de contrôle de flux insuffisants

Le risque expliqué

Les pipelines CI/CD sont des chaînes d’étapes automatisées. Si ces étapes s’enchaînent sans « portes » (gates) de validation, un commit malveillant peut traverser tout le pipeline et atteindre la production en quelques minutes.

Problèmes courants

  • Déploiement automatique en production sans approbation humaine
  • Pas de séparation entre environnements (dev → staging → prod)
  • Absence de tests de sécurité bloquants dans le pipeline
  • Merge automatique sans revue de code obligatoire

Conséquences

  • Code vulnérable ou malveillant déployé en production
  • Impossibilité de détecter une compromission avant l’impact
  • Contamination croisée entre environnements

Recommandations

  1. Implémenter des gates obligatoires

    Ajoutez des étapes de validation (tests automatisés, scans de sécurité, revues de code) qui doivent réussir avant de passer à l’étape suivante.

  2. Exiger des approbations manuelles pour la production

    Configurez votre pipeline pour qu’un humain valide explicitement tout déploiement en production.

  3. Segmenter les environnements

    Séparez clairement dev, staging et production. Limitez la promotion automatique aux environnements non critiques.

  4. Utiliser des pipelines multi-stades

    Définissez des étapes distinctes avec des conditions de passage explicites : tests unitaires → tests d’intégration → scan de sécurité → approbation → déploiement.

CICD-SEC-2 : Inadequate Identity and Access Management

Gestion des identités et des accès inadéquate

Le risque expliqué

Les pipelines CI/CD manipulent du code source, des secrets, des artefacts et des accès à l’infrastructure de production. Si n’importe qui peut accéder à ces ressources, ou si des comptes compromis ont des privilèges excessifs, la surface d’attaque explose.

Problèmes courants

  • Comptes partagés entre plusieurs personnes ou équipes
  • Absence d’authentification forte (MFA) sur les comptes privilégiés
  • Droits administratifs accordés par défaut à tous les membres d’un projet
  • Pas de révocation des accès lors des départs

Conséquences

  • Accès non autorisé aux secrets et aux scripts de build
  • Escalade de privilèges menant à une compromission totale
  • Impossibilité de tracer qui a fait quoi (auditabilité)

Recommandations

  1. Implémenter le RBAC (Role-Based Access Control)

    Définissez des rôles précis (développeur, reviewer, déployeur, admin) avec les permissions minimales nécessaires pour chaque rôle.

  2. Activer la MFA pour tous les comptes

    L’authentification multi-facteurs est non négociable pour tout accès au pipeline, au dépôt de code et aux secrets.

  3. Auditer régulièrement les accès

    Revoyez trimestriellement qui a accès à quoi. Supprimez les accès obsolètes.

  4. Utiliser des identités fédérées

    Connectez votre CI/CD à votre IdP (Identity Provider) pour centraliser la gestion des identités et automatiser les révocations.

CICD-SEC-3 : Dependency Chain Abuse

Abus de la chaîne de dépendances

Le risque expliqué

Un pipeline CI/CD télécharge typiquement des dizaines de dépendances : bibliothèques, images Docker, outils. Chaque dépendance est un point d’entrée potentiel pour un attaquant. Les attaques de type « dependency confusion », « typosquatting » ou la compromission de packages populaires sont en forte augmentation.

Problèmes courants

  • Téléchargement de packages depuis des registres publics sans vérification
  • Pas de verrouillage des versions (utilisation de latest)
  • Absence de scan des vulnérabilités connues
  • Pas de vérification de la provenance des packages

Conséquences

  • Introduction de backdoors dans votre build
  • Compromission en cascade de tous vos projets utilisant la même dépendance
  • Vol de secrets pendant le build

Exemples d’attaques récentes

AttaqueAnnéeMécanismeImpact
ua-parser-js2021Package npm compromisCrypto-miner installé
coa / rc2021Packages npm compromisExfiltration de données
colors / faker2022Sabotage par le mainteneurDoS sur des milliers d’apps
tj-actions2025GitHub Action compromiseSecrets exfiltrés

Recommandations

  1. Scanner les dépendances pour les vulnérabilités

    Utilisez des outils comme Trivy, Snyk ou OWASP Dependency-Check dans votre pipeline. Bloquez le build si des CVE critiques sont détectées.

  2. Verrouiller les versions

    Utilisez des fichiers de lock (package-lock.json, requirements.txt avec hashes, go.sum) et épinglez les versions exactes.

  3. Vérifier la provenance

    Privilégiez les packages signés. Vérifiez les attestations SLSA quand disponibles.

  4. Utiliser un proxy / miroir interne

    Mettez en cache vos dépendances dans un registre interne (Nexus, Artifactory) pour contrôler ce qui entre dans votre pipeline.

Scanner vos images avec Trivy Détectez les vulnérabilités dans vos conteneurs et dépendances
Scanner vos images avec Grype Alternative légère pour le scan de vulnérabilités

CICD-SEC-4 : Poisoned Pipeline Execution (PPE)

Exécution de pipeline empoisonné

Le risque expliqué

Les pipelines CI/CD sont souvent définis par des fichiers versionnés dans le dépôt de code (« Pipeline as Code »). Si un attaquant peut modifier ces fichiers — via une pull request malveillante, un compte compromis, ou une faille dans le système de revue — il peut faire exécuter n’importe quel code sur vos runners.

Types de PPE

TypeMécanismeRisque
Direct PPEModification directe du fichier pipelineContrôle total du build
Indirect PPEModification d’un script appelé par le pipelineInjection de code
Public PPEPull request malveillante depuis un forkExfiltration de secrets

Problèmes courants

  • Runners partagés entre projets sans isolation
  • Exécution automatique des pipelines sur les pull requests externes
  • Pas de validation des modifications des fichiers de pipeline
  • Secrets injectés dans l’environnement de tous les jobs

Conséquences

  • Exécution de code malveillant sur vos serveurs de build
  • Vol de secrets, exfiltration de code source propriétaire
  • Compromission de l’infrastructure de build

Recommandations

  1. Isoler les runners

    Utilisez des runners éphémères (conteneurs ou VMs jetables). Chaque job doit démarrer dans un environnement propre.

  2. Restreindre les pull requests externes

    Exigez une approbation manuelle avant d’exécuter le pipeline sur les PR provenant de forks. Limitez l’accès aux secrets pour ces PR.

  3. Protéger les fichiers de pipeline

    Utilisez les mécanismes de protection de branches pour exiger une revue de code sur les modifications des fichiers CI/CD.

  4. Séparer les secrets par contexte

    Ne donnez accès aux secrets de production qu’aux jobs qui en ont réellement besoin, pas à l’ensemble du pipeline.

CICD-SEC-5 : Insufficient PBAC (Pipeline-Based Access Controls)

Contrôles d’accès basés sur le pipeline insuffisants

Le risque expliqué

Le PBAC (Pipeline-Based Access Control) définit quels jobs, étapes et environnements sont accessibles à quel moment et avec quels privilèges. Sans segmentation fine, un attaquant qui compromet un job de test peut pivoter vers les jobs de déploiement.

Problèmes courants

  • Tous les jobs ont accès aux mêmes secrets
  • Pas de séparation entre les jobs « build » et « deploy »
  • Tokens avec des permissions excessives (lecture + écriture sur tout)
  • Pas de restrictions sur quels jobs peuvent modifier quels artefacts

Conséquences

  • Escalade de privilèges via un job non critique
  • Déploiements non autorisés en production
  • Modification malveillante des artefacts de build

Recommandations

  1. Appliquer le moindre privilège par job

    Chaque job ne doit avoir accès qu’aux ressources strictement nécessaires à sa tâche. Un job de lint n’a pas besoin des secrets de déploiement.

  2. Séparer les runners par niveau de criticité

    Utilisez des runners différents pour les jobs sensibles (déploiement, accès production) et les jobs non sensibles (tests, lint).

  3. Utiliser des tokens à durée limitée

    Privilégiez les tokens éphémères (OIDC) plutôt que des secrets statiques. Limitez leur durée de vie au minimum nécessaire.

  4. Monitorer l’utilisation des ressources

    Alertez sur les accès inhabituels : job de test qui accède à des secrets de production, accès à des ressources en dehors des heures normales.

CICD-SEC-6 : Insufficient Credential Hygiene

Hygiène des identifiants insuffisante

Le risque expliqué

Un pipeline CI/CD manipule de nombreux secrets : clés API, tokens d’accès aux clouds, certificats, credentials de bases de données. Ces secrets sont souvent mal protégés : stockés en clair, partagés entre équipes, jamais renouvelés. L’attaque tj-actions de 2025 a spécifiquement ciblé l’exfiltration de secrets depuis la mémoire des runners.

Problèmes courants

  • Secrets en clair dans les fichiers de configuration (.yml, .env, Dockerfile)
  • Partage des mêmes clés entre plusieurs équipes ou projets
  • Pas de rotation périodique (certains secrets ont 5+ ans)
  • Secrets affichés dans les logs de build

Conséquences

  • Accès frauduleux aux services cloud, bases de données, APIs
  • Mouvements latéraux vers d’autres systèmes
  • Persistance de l’attaquant même après détection

Recommandations

  1. Utiliser un gestionnaire de secrets

    HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GitLab/GitHub native secrets. Ne stockez jamais de secrets dans le code.

  2. Scanner le code pour détecter les secrets exposés

    Intégrez Gitleaks, TruffleHog ou GitHub Secret Scanning dans votre pipeline. Bloquez les commits contenant des secrets.

  3. Automatiser la rotation

    Configurez une rotation automatique des secrets critiques (tokens cloud, clés API). Idéalement tous les 30-90 jours.

  4. Masquer les secrets dans les logs

    Configurez votre CI/CD pour masquer automatiquement les valeurs des secrets dans les outputs. Attention : l’attaque tj-actions a contourné ce mécanisme en encodant les secrets.

Détecter les secrets avec Gitleaks Scanner votre code à la recherche de secrets exposés
TruffleHog pour l'analyse de secrets Outil complémentaire pour la détection de secrets

CICD-SEC-7 : Insecure System Configuration

Configuration système non sécurisée

Le risque expliqué

Jenkins, GitLab CI, CircleCI, GitHub Actions : toutes ces plateformes ont des configurations par défaut pensées pour la facilité d’utilisation, pas pour la sécurité. Mots de passe par défaut, ports d’administration exposés, chiffrement désactivé — autant de vecteurs d’attaque si vous ne durcissez pas votre installation.

Problèmes courants

  • Mots de passe par défaut non modifiés (admin/admin)
  • Interfaces d’administration exposées sur Internet
  • Communications non chiffrées entre composants
  • Plugins obsolètes avec des vulnérabilités connues
  • Debug / verbose logging activé en production

Conséquences

  • Prise de contrôle directe de la plateforme CI/CD
  • Interception et modification du trafic en transit
  • Exécution de code via des plugins vulnérables

Recommandations

  1. Changer tous les mots de passe par défaut

    Dès l’installation, remplacez tous les credentials par défaut par des mots de passe forts et uniques.

  2. Activer TLS partout

    Chiffrez toutes les communications : UI web, API, communication avec les runners, accès aux registres d’artefacts.

  3. Restreindre l’accès réseau

    Placez votre CI/CD derrière un VPN ou un bastion. N’exposez jamais l’interface d’administration sur Internet.

  4. Maintenir les plugins à jour

    Les plugins sont souvent le maillon faible. Auditez-les régulièrement, supprimez ceux inutilisés, mettez à jour les autres.

Sécuriser Jenkins Guide de durcissement pour Jenkins CI
GitLab CI/CD Bonnes pratiques pour GitLab CI

CICD-SEC-8 : Ungoverned Usage of 3rd Party Services

Usage non gouverné des services tiers

Le risque expliqué

Les pipelines modernes intègrent de nombreux services tiers : actions GitHub de la marketplace, plugins Jenkins, services SaaS de scan ou d’analyse. Chaque intégration est une extension de confiance : vous autorisez ce service à accéder à votre code, vos secrets, vos artefacts. L’attaque tj-actions a démontré que même des actions très populaires (23 000+ dépôts) peuvent être compromises.

Problèmes courants

  • Utilisation d’actions/plugins sans audit préalable
  • Confiance aveugle dans les services « populaires »
  • Pas de contrat ou SLA avec les fournisseurs tiers
  • Absence de monitoring de ces intégrations

Conséquences

  • Fuite de données vers un fournisseur non fiable
  • Compromission en cascade via un service tiers piraté
  • Dépendance à un service qui disparaît ou change ses conditions

Recommandations

  1. Auditer avant d’intégrer

    Avant d’ajouter une action GitHub ou un plugin, vérifiez : qui la maintient ? Depuis combien de temps ? Le code est-il auditable ?

  2. Épingler les versions

    Ne référencez jamais une action par son tag (@v1). Utilisez le SHA du commit pour éviter les attaques par modification de tag : uses: owner/action@sha256:...

  3. Limiter les permissions

    Utilisez les permissions minimales pour chaque intégration. Une action de lint n’a pas besoin de write sur le dépôt.

  4. Monitorer les dépendances tierces

    Suivez les CVE et advisories des services que vous utilisez. Configurez Dependabot ou Renovate pour les actions GitHub.

CICD-SEC-9 : Improper Artifact Integrity Validation

Validation incorrecte de l’intégrité des artefacts

Le risque expliqué

Les artefacts (binaires, images Docker, packages) sont le produit final de votre pipeline. S’ils ne sont pas signés et si leur intégrité n’est pas vérifiée à chaque étape, un attaquant peut les remplacer par des versions malveillantes — soit dans le stockage, soit pendant le transit.

Problèmes courants

  • Pas de signature cryptographique des artefacts
  • Stockage dans des registres sans contrôle d’accès
  • Pas de vérification d’intégrité avant déploiement
  • Images Docker avec le tag latest (mutable)

Conséquences

  • Déploiement d’artefacts falsifiés contenant des backdoors
  • Impossibilité de prouver l’origine légitime d’un artefact
  • Contamination de toute la chaîne de distribution

Recommandations

  1. Signer tous les artefacts

    Utilisez Cosign (Sigstore) pour signer vos images Docker. Utilisez GPG ou Sigstore pour les binaires et packages.

  2. Générer des attestations SLSA

    Créez des attestations de provenance qui prouvent où, quand et comment l’artefact a été construit.

  3. Vérifier avant de déployer

    Intégrez la vérification de signature dans votre pipeline de déploiement. Refusez tout artefact non signé ou avec une signature invalide.

  4. Utiliser des tags immuables

    Préférez les digests (image@sha256:...) aux tags mutables (image:latest). Ou utilisez des tags basés sur le commit/version.

Signer avec Cosign Signature cryptographique des images conteneurs
Comprendre SLSA Framework de niveaux de maturité supply chain

CICD-SEC-10 : Insufficient Logging and Visibility

Journalisation et visibilité insuffisantes

Le risque expliqué

Les attaques sur les pipelines CI/CD sont souvent discrètes : modification d’un fichier de config, exfiltration progressive de secrets, injection de code dans un job spécifique. Sans une journalisation exhaustive et une surveillance active, ces attaques passent inaperçues pendant des mois. SolarWinds est resté compromis pendant 9 mois avant détection.

Problèmes courants

  • Logs éparpillés entre différents systèmes, non corrélés
  • Pas de surveillance en temps réel des événements critiques
  • Rétention des logs trop courte pour l’investigation
  • Logs incomplets (pas de trace de qui a fait quoi)

Conséquences

  • Détection tardive ou inexistante des compromissions
  • Impossibilité de reconstituer le scénario d’attaque
  • Difficultés à évaluer l’étendue de l’impact

Recommandations

  1. Centraliser les logs

    Agrégez tous les logs (CI/CD, git, registres, runners) dans une plateforme centrale : ELK Stack, Splunk, Datadog, etc.

  2. Configurer des alertes

    Alertez sur les événements suspects : connexions inhabituelles, échecs d’authentification répétés, modifications de fichiers de pipeline, accès à des secrets depuis des jobs inattendus.

  3. Conserver les logs suffisamment longtemps

    Minimum 6 mois, idéalement 12 mois. Les attaques sophistiquées sont souvent découvertes bien après leur début.

  4. Inclure le contexte dans les logs

    Chaque entrée doit inclure : qui (identité), quoi (action), quand (timestamp précis), où (job, runner, IP), résultat (succès/échec).

À retenir

L’OWASP Top 10 CI/CD Security Risks couvre trois grandes catégories de menaces :

  1. Contrôle et accès (SEC-1, SEC-2, SEC-5, SEC-10) : qui peut faire quoi, à quel moment, avec quelle traçabilité.

  2. Code et dépendances (SEC-3, SEC-4, SEC-8, SEC-9) : d’où vient ce qui entre et sort de votre pipeline, et comment le vérifier.

  3. Secrets et configuration (SEC-6, SEC-7) : comment protéger les informations sensibles et durcir votre infrastructure.

Liens utiles

Par où commencer Parcours progressif pour sécuriser votre supply chain
Introduction à la supply chain Comprendre les menaces et les attaquants
Comprendre les CVE Identifier et évaluer les vulnérabilités
Principe du moindre privilège Fondement de la sécurité des accès

Ressources externes