OWASP Top 10 des Risques CI/CD Expliqués avec des Exemples Concrets

Les pipelines CI/CD sont devenus l’épine dorsale de la livraison logicielle moderne. Mais cette puissance s’accompagne de risques significatifs. Le projet OWASP Top 10 des Risques de Sécurité CI/CD répertorie les vecteurs d’attaque les plus critiques ciblant les systèmes d’intégration continue et de livraison continue. Dans ce guide, nous détaillons chaque risque avec des exemples concrets, des évaluations d’impact et des mesures correctives applicables dès aujourd’hui à GitHub Actions, GitLab CI et d’autres plateformes.

Tableau Récapitulatif : OWASP Top 10 des Risques CI/CD en un Coup d’Œil

ID	Nom du Risque	Problème Central	Sévérité
CICD-SEC-1	Mécanismes de Contrôle de Flux Insuffisants	Absence d’application des portes d’approbation avant que le code n’atteigne la production	Critique
CICD-SEC-2	Gestion Inadéquate des Identités et des Accès	Identités trop permissives à travers les systèmes de pipeline	Critique
CICD-SEC-3	Abus de la Chaîne de Dépendances	Paquets malveillants injectés via la chaîne d’approvisionnement logicielle	Élevée
CICD-SEC-4	Poisoned Pipeline Execution (PPE)	Les attaquants manipulent les définitions de pipeline pour exécuter du code malveillant	Critique
CICD-SEC-5	PBAC Insuffisant (Contrôles d’Accès Basés sur le Pipeline)	Pipelines dotés de permissions excessives au-delà des besoins des jobs	Élevée
CICD-SEC-6	Hygiène des Identifiants Insuffisante	Secrets exposés dans les logs, les dépôts ou partagés de manière excessive entre les pipelines	Critique
CICD-SEC-7	Configuration Système Non Sécurisée	Paramètres par défaut ou mal configurés de la plateforme CI/CD	Élevée
CICD-SEC-8	Utilisation Non Gouvernée de Services Tiers	Intégrations tierces non vérifiées avec accès au pipeline	Moyenne
CICD-SEC-9	Validation Inappropriée de l’Intégrité des Artefacts	Aucune vérification que les sorties de build n’ont pas été altérées	Élevée
CICD-SEC-10	Journalisation et Visibilité Insuffisantes	Incapacité à détecter ou investiguer les attaques basées sur le pipeline	Moyenne

Examinons chaque risque en détail.

CICD-SEC-1 : Mécanismes de Contrôle de Flux Insuffisants

De Quoi S’agit-il ?

Les mécanismes de contrôle de flux sont les portes et garde-fous qui régissent la manière dont le code passe du poste de travail d’un développeur à la production. Lorsque ces contrôles sont insuffisants, un attaquant — ou même un initié malveillant — peut pousser du code directement vers une branche de production sans revue par les pairs, contourner les approbations requises, ou ignorer des vérifications de sécurité critiques comme les analyses SAST et SCA.

Exemple Concret

En 2021, un chercheur a démontré comment un seul développeur d’une grande entreprise technologique pouvait contourner les règles de protection de branche en poussant directement vers la branche par défaut lorsque les protections de branche n’étaient pas appliquées aux administrateurs. Le résultat : du code non testé et non revu déployé directement en production, sans aucune trace d’audit d’approbation. De même, de nombreuses organisations configurent leurs pipelines pour un déploiement automatique lors du merge mais oublient d’imposer un nombre minimum de relecteurs ou des exigences de vérification de statut.

Impact

Un attaquant qui contourne les contrôles de flux peut injecter des portes dérobées, désactiver les outils de sécurité ou modifier les configurations de déploiement — le tout sans que personne ne s’en aperçoive jusqu’à ce qu’il soit trop tard. C’est le risque passerelle : si vos contrôles de flux sont faibles, chaque contrôle subséquent devient moins efficace.

Mesures Correctives

Appliquer les règles de protection de branche sur toutes les branches critiques. Exiger au moins deux revues approbatrices avant le merge, et ne pas permettre aux administrateurs de contourner ces règles.
Exiger la réussite des vérifications de statut avant le merge, y compris SAST, le linting et les tests unitaires.
Utiliser des fichiers CODEOWNERS pour imposer les revues d’équipes spécifiques pour les chemins sensibles (par ex., .github/workflows/, Dockerfile, fichiers Terraform).
Activer les commits signés et les vérifier dans votre pipeline. Consultez notre guide sur les Laboratoires de Pipelines Sécurisés pour une démonstration pratique.

CICD-SEC-2 : Gestion Inadéquate des Identités et des Accès

De Quoi S’agit-il ?

Les environnements CI/CD couvrent plusieurs systèmes — contrôle de source, serveurs de build, registres d’artefacts, fournisseurs cloud et cibles de déploiement. Chaque système possède son propre modèle d’identité. Une gestion IAM inadéquate signifie que les identités (humaines ou machines) disposent de privilèges excessifs, que des comptes obsolètes persistent, ou qu’il n’existe aucune gouvernance centralisée sur qui ou quoi peut faire quoi à travers le pipeline.

Exemple Concret

L’attaque de la chaîne d’approvisionnement Codecov (avril 2021) a exploité un compte de service trop permissif. Les attaquants ont modifié le script Codecov Bash Uploader pour exfiltrer les variables d’environnement — y compris les tokens CI et les secrets — de milliers de pipelines CI/CD clients. Parce que ces tokens CI avaient des permissions étendues (souvent un accès en écriture aux dépôts et registres de paquets), les attaquants pouvaient se déplacer latéralement à travers toute la chaîne de livraison.

Impact

Des privilèges excessifs signifient qu’une seule identité compromise peut lire des secrets, modifier du code, altérer les définitions de pipeline, pousser des artefacts malveillants et pivoter vers les environnements cloud de production. Le rayon d’impact est énorme.

Mesures Correctives

Appliquer le principe du moindre privilège à chaque identité — utilisateurs humains, comptes bot et tokens de service.
Utiliser des identifiants à courte durée de vie et à portée limitée au lieu de tokens d’accès personnels à longue durée de vie. L’intégration OIDC de GitHub avec les fournisseurs cloud est un modèle robuste.
Auditer et effectuer la rotation des identifiants régulièrement. Révoquer immédiatement l’accès des membres d’équipe ayant quitté l’organisation.
Centraliser la gestion des identités via SSO/SAML et imposer le MFA pour tout accès aux plateformes CI/CD. En savoir plus dans nos guides Identité et Accès.

CICD-SEC-3 : Abus de la Chaîne de Dépendances

De Quoi S’agit-il ?

Les applications modernes tirent des centaines ou des milliers de dépendances depuis des registres publics (npm, PyPI, Maven Central, Docker Hub). L’abus de la chaîne de dépendances se produit lorsqu’un attaquant injecte du code malveillant dans un paquet que votre pipeline installe automatiquement — par le biais du typosquatting, de la confusion de dépendances ou de la compromission d’un compte de mainteneur existant.

Exemple Concret

Lors de l’incident ua-parser-js (octobre 2021), un paquet npm largement utilisé avec plus de 7 millions de téléchargements hebdomadaires a été compromis lorsqu’un attaquant a obtenu l’accès au compte npm du mainteneur. Il a publié des versions malveillantes qui installaient des cryptomineurs et des voleurs d’identifiants. Tout pipeline CI/CD exécutant npm install sans versions épinglées téléchargeait automatiquement le paquet trojanisé.

Impact

Les dépendances compromises s’exécutent dans votre environnement de build avec un accès complet aux variables d’environnement, aux secrets et à la connectivité réseau. Elles peuvent exfiltrer des identifiants, injecter des portes dérobées dans vos propres artefacts de build, ou miner de la cryptomonnaie sur votre infrastructure.

Mesures Correctives

Épingler les dépendances à des versions exactes et utiliser des fichiers de verrouillage (package-lock.json, Pipfile.lock, go.sum).
Activer la revue des dépendances dans les pull requests en utilisant des outils comme dependency-review-action pour GitHub Actions.
Utiliser un registre privé ou un proxy (Artifactory, Nexus) pour mettre en cache et analyser les paquets avant qu’ils n’entrent dans votre build.
Implémenter l’Analyse de Composition Logicielle (SCA) dans chaque exécution de pipeline. Consultez nos guides de Sécurité de la Chaîne d’Approvisionnement pour les modèles d’intégration.

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

De Quoi S’agit-il ?

Le Poisoned Pipeline Execution est l’un des risques CI/CD les plus dangereux. Il se produit lorsqu’un attaquant peut modifier le fichier de configuration du pipeline CI/CD (par ex., .github/workflows/, .gitlab-ci.yml, Jenkinsfile) et que cette modification est exécutée par le pipeline. Il existe trois variantes : le Direct PPE (D-PPE), où l’attaquant modifie directement le fichier de pipeline ; l’Indirect PPE (I-PPE), où l’attaquant modifie des fichiers référencés par le pipeline (scripts, Makefiles) ; et le Public PPE (3PE), où les pull requests basées sur des forks déclenchent des pipelines dans le dépôt cible.

Exemple Concret

Lors de la vague de vulnérabilités pull_request_target de GitHub Actions (2020-2021), des chercheurs en sécurité ont démontré que les dépôts publics utilisant le déclencheur pull_request_target avec un checkout explicite du code de la PR (via actions/checkout avec ref: ${{ github.event.pull_request.head.sha }}) permettaient à tout contributeur externe d’exécuter du code arbitraire dans le contexte du dépôt cible — avec accès à ses secrets. De grands projets open source, dont plusieurs dépôts de la Fondation Apache, se sont avérés vulnérables.

Impact

Le PPE donne aux attaquants l’exécution de code à l’intérieur de votre pipeline avec accès aux secrets, aux identifiants de déploiement et la capacité de modifier les sorties de build. C’est effectivement de l’exécution de code à distance sur votre infrastructure CI/CD.

Mesures Correctives

Ne jamais utiliser pull_request_target avec actions/checkout de la ref head de la PR. Utiliser pull_request à la place pour le code non fiable.
Exiger l’approbation pour les workflows de PR basés sur des forks dans les paramètres GitHub Actions (Settings > Actions > Fork pull request workflows).
Conserver les définitions de pipeline dans des branches protégées et restreindre qui peut les modifier.
Séparer les pipelines de build et de déploiement : le pipeline de build (qui exécute du code non fiable) ne devrait jamais avoir accès aux identifiants de déploiement en production. Consultez nos laboratoires pratiques pour les modèles de séparation de pipeline.

CICD-SEC-5 : Contrôles d’Accès Basés sur le Pipeline (PBAC) Insuffisants

De Quoi S’agit-il ?

Le PBAC fait référence aux contrôles d’accès appliqués à l’environnement d’exécution du pipeline lui-même. Un PBAC insuffisant signifie que les pipelines ont accès à des ressources, des secrets et des systèmes qui ne sont pas nécessaires à leur job spécifique. C’est l’équivalent pipeline de la violation du moindre privilège — par exemple, un job de build pour un service frontend a accès aux identifiants de la base de données de production.

Exemple Concret

Considérons une organisation exécutant 50 microservices dans un monorepo, tous partageant une seule configuration CI/CD. Chaque job de pipeline — quel que soit le service qu’il construit — a accès à tous les secrets du dépôt : URL de bases de données de production, clés root AWS, certificats de signature. Lorsqu’un job de test d’un développeur junior échoue et affiche les variables d’environnement dans le log pour le débogage, les secrets des 50 services sont exposés.

Impact

Lorsqu’un seul job de pipeline est compromis (par PPE, abus de dépendances ou un initié malveillant), un PBAC insuffisant signifie que l’attaquant obtient l’accès à bien plus que le service spécifique en cours de construction. Le rayon d’impact s’étend à chaque système que le pipeline peut atteindre.

Mesures Correctives

Limiter la portée des secrets à des environnements et jobs spécifiques. Dans GitHub Actions, utiliser des secrets à portée d’environnement avec des relecteurs requis pour les environnements de production.
Utiliser la fédération OIDC pour l’accès cloud au lieu de stocker des identifiants cloud statiques. Limiter la portée des claims OIDC à des dépôts, branches et environnements spécifiques.
Restreindre les permissions du GITHUB_TOKEN en utilisant la clé permissions au niveau du workflow et du job. Définir par défaut read-all et n’accorder l’écriture que lorsque nécessaire.
Isoler les runners de pipeline par niveau de sensibilité — ne pas exécuter les jobs de déploiement en production sur les mêmes runners que les jobs de validation de PR. Consultez nos guides de Sécurité CI/CD pour les modèles d’architecture.

CICD-SEC-6 : Hygiène des Identifiants Insuffisante

De Quoi S’agit-il ?

Les identifiants (clés API, tokens, mots de passe, certificats) sont le sang vital des pipelines CI/CD. L’hygiène insuffisante des identifiants fait référence aux secrets codés en dur dans le code, stockés en clair, affichés dans les logs, partagés trop largement, jamais renouvelés, ou qui persistent longtemps après qu’ils auraient dû être révoqués.

Exemple Concret

La fuite Samsung (mars 2022) a vu le groupe Lapsus$ extraire près de 200 Go de code source des dépôts de Samsung, qui contenaient des identifiants codés en dur, notamment des clés de signature privées et des clés API intégrées directement dans le code source. Dans les contextes CI/CD, les chercheurs trouvent régulièrement des secrets affichés dans les logs de build via des sorties de débogage, des commandes env, ou des messages d’erreur qui incluent des en-têtes d’authentification.

Impact

Des identifiants exposés donnent aux attaquants un accès direct aux systèmes en aval — comptes cloud, registres d’artefacts, bases de données et cibles de déploiement — sans avoir besoin d’exploiter d’autres vulnérabilités. Une seule clé AWS divulguée peut compromettre un environnement cloud entier.

Mesures Correctives

Ne jamais coder les secrets en dur. Utiliser le gestionnaire de secrets natif de votre plateforme (GitHub Encrypted Secrets, GitLab CI/CD Variables avec masquage, HashiCorp Vault).
Activer l’analyse de secrets sur tous les dépôts pour détecter les identifiants accidentellement commités. La protection push de GitHub bloque les commits contenant des modèles de secrets connus.
Masquer les secrets dans les logs. La plupart des plateformes CI supportent le masquage automatique, mais vérifiez qu’il fonctionne pour vos sorties personnalisées.
Effectuer la rotation des identifiants selon un calendrier et immédiatement en cas de suspicion d’exposition. Utiliser des tokens à courte durée de vie (OIDC, STS) dans la mesure du possible.
Exécuter des outils comme trufflehog ou gitleaks dans votre pipeline pour détecter les secrets avant qu’ils n’atteignent la branche par défaut. Consultez nos guides de Gestion des Secrets pour les détails d’implémentation.

CICD-SEC-7 : Configuration Système Non Sécurisée

De Quoi S’agit-il ?

Les plateformes CI/CD (Jenkins, GitHub Actions, GitLab CI, CircleCI, ArgoCD) sont livrées avec des configurations par défaut qui privilégient la facilité d’utilisation au détriment de la sécurité. La configuration système non sécurisée couvre les mauvaises configurations telles que : versions logicielles obsolètes avec des CVE connues, accès réseau trop permissif, runners auto-hébergés sans durcissement, journalisation d’audit désactivée et interfaces d’administration exposées.

Exemple Concret

Des milliers d’instances Jenkins sont exposées à Internet avec des configurations par défaut, beaucoup exécutant des versions obsolètes avec des vulnérabilités d’exécution de code à distance connues (par ex., CVE-2024-23897, une lecture de fichier arbitraire dans le CLI de Jenkins). Les recherches Shodan révèlent régulièrement des serveurs Jenkins avec un accès non authentifié aux logs de build, aux définitions de pipeline et aux identifiants stockés. En 2022, des chercheurs ont trouvé plus de 30 000 instances Jenkins exposées, dont beaucoup appartenaient à des entreprises du Fortune 500.

Impact

Une plateforme CI/CD mal configurée peut exposer des identifiants, permettre l’exécution non autorisée de pipelines, fournir aux attaquants un point d’ancrage dans votre réseau interne et leur donner la capacité d’altérer chaque artefact que votre organisation produit.

Mesures Correctives

Durcir les runners/agents auto-hébergés. Utiliser des conteneurs éphémères qui sont détruits après chaque job. Ne jamais installer de runners sur des VM à longue durée de vie qui accumulent de l’état.
Maintenir les plateformes CI/CD à jour et s’abonner aux avis de sécurité pour vos plateformes spécifiques.
Restreindre l’accès réseau aux interfaces d’administration CI/CD. Utiliser un VPN ou un accès réseau zero-trust.
Désactiver les fonctionnalités inutiles — si votre organisation n’utilise pas le CLI Jenkins, désactivez-le. Si vous n’avez pas besoin d’un accès SSH aux runners, coupez-le.
Appliquer les benchmarks CIS pour vos plateformes CI/CD lorsqu’ils sont disponibles. Référez-vous à nos guides de Durcissement de Pipeline pour des listes de contrôle spécifiques à chaque plateforme.

CICD-SEC-8 : Utilisation Non Gouvernée de Services Tiers

De Quoi S’agit-il ?

Les pipelines CI/CD modernes s’intègrent avec des dizaines de services tiers : outils de qualité de code, scanners de sécurité, systèmes de notification, plateformes de déploiement et actions du marketplace. L’utilisation non gouvernée signifie que ces intégrations sont adoptées sans revue de sécurité, se voient accorder des scopes OAuth excessifs et ne sont pas surveillées pour des changements de comportement ou de propriétaire.

Exemple Concret

La compromission de tj-actions/changed-files (mars 2025) a illustré ce risque de manière dramatique. Une GitHub Action largement utilisée a été compromise par une chaîne d’événements : les attaquants ont d’abord compromis l’action reviewdog/action-setup, l’ont utilisée pour voler un PAT du mainteneur de tj-actions, puis ont injecté du code malveillant dans tj-actions/changed-files. Le code malveillant affichait les secrets CI/CD dans les logs de build. Parce que des milliers de dépôts utilisaient cette action avec des références de version par défaut (non épinglées), le rayon d’impact était énorme.

Impact

Une intégration tierce compromise peut lire votre code source, voler des secrets, modifier les sorties de build et déployer du code malveillant — le tout dans le contexte de confiance de votre pipeline. Parce que ces outils ont souvent des scopes OAuth larges, une seule compromission peut se propager à travers toute votre organisation.

Mesures Correctives

Épingler les actions tierces à des SHA de commit complets, pas à des tags ou des noms de branches. Les tags peuvent être déplacés pour pointer vers des commits malveillants.
Utiliser la politique actions/allowed-actions de GitHub pour restreindre les actions pouvant s’exécuter dans votre organisation.
Auditer régulièrement les permissions des applications OAuth. Révoquer l’accès des outils qui ne sont plus utilisés.
Activer Dependabot ou Renovate pour suivre les mises à jour de vos dépendances d’actions et examiner attentivement les changements avant de les merger. Consultez notre section Sécurité de la Chaîne d’Approvisionnement pour les cadres de gouvernance.

CICD-SEC-9 : Validation Inappropriée de l’Intégrité des Artefacts

De Quoi S’agit-il ?

Les artefacts de build — images de conteneurs, binaires, paquets — transitent par plusieurs systèmes entre l’étape de build et le déploiement. La validation inappropriée de l’intégrité des artefacts signifie qu’il n’existe aucun mécanisme pour vérifier que l’artefact déployé en production est exactement celui produit par le pipeline de build de confiance, sans altération entre les deux.

Exemple Concret

L’attaque SolarWinds SUNBURST (décembre 2020) est l’exemple par excellence. Les attaquants ont compromis le système de build de SolarWinds et injecté une porte dérobée dans le logiciel Orion pendant le processus de build. Parce qu’il n’y avait aucune vérification indépendante de l’intégrité des sorties de build, la mise à jour trojanisée a été signée avec le certificat légitime de SolarWinds et distribuée à environ 18 000 organisations, dont plusieurs agences gouvernementales américaines.

Impact

Sans validation de l’intégrité des artefacts, les attaquants peuvent remplacer des builds légitimes par des builds malveillants, injecter des portes dérobées pendant le transit build-déploiement, ou rejouer des versions plus anciennes (vulnérables) d’artefacts. Les consommateurs de votre logiciel n’ont aucun moyen de vérifier qu’ils ont reçu ce que vous aviez l’intention de livrer.

Mesures Correctives

Signer tous les artefacts de build en utilisant des outils comme Sigstore/Cosign pour les conteneurs ou GPG pour les paquets traditionnels.
Générer et distribuer des SBOM (Software Bills of Materials) avec chaque release en utilisant le format SPDX ou CycloneDX.
Implémenter les attestations de provenance SLSA (Supply-chain Levels for Software Artifacts). SLSA Niveau 2+ garantit que la provenance de build est générée par le service de build lui-même, pas par le développeur.
Vérifier les checksums des artefacts à chaque étape du pipeline de livraison — après le build, après le push vers le registre, et avant le déploiement.
Utiliser des contrôleurs d’admission (par ex., Kyverno, OPA Gatekeeper) dans Kubernetes pour rejeter les images non signées ou non attestées. Consultez nos guides de Sécurité des Artefacts pour des démonstrations d’implémentation.

CICD-SEC-10 : Journalisation et Visibilité Insuffisantes

De Quoi S’agit-il ?

Si vous ne pouvez pas voir ce qui se passe dans vos pipelines, vous ne pouvez pas détecter les attaques, investiguer les incidents, ni démontrer la conformité. La journalisation et la visibilité insuffisantes signifient que les événements CI/CD — exécutions de pipelines, changements de configuration, accès aux secrets, connexions utilisateurs, modifications de permissions — ne sont pas capturés, pas centralisés, pas surveillés, ou pas conservés assez longtemps pour supporter la réponse aux incidents.

Exemple Concret

De nombreuses organisations découvrent les compromissions CI/CD des semaines ou des mois après les faits — si elles les découvrent. Lors de la fuite Codecov, les entreprises affectées ont eu du mal à déterminer l’exposition parce que leurs logs CI/CD soit ne capturaient pas quelles variables d’environnement étaient présentes lors des builds affectés, soit ces logs avaient déjà été purgés par rotation. Sans journalisation centralisée, les équipes en étaient réduites à deviner quels secrets nécessitaient une rotation.

Impact

Sans visibilité, chaque autre risque de cette liste devient plus difficile à détecter et à traiter. Les attaquants peuvent opérer sans être détectés, le temps de persistance augmente, et la réponse aux incidents devient de la conjecture plutôt qu’une investigation fondée sur des preuves. Les cadres de conformité (SOC 2, ISO 27001) exigent également des pistes d’audit démontrables pour la livraison logicielle.

Mesures Correctives

Centraliser les logs CI/CD dans un SIEM ou une plateforme de gestion des logs (Splunk, Elastic, Datadog). Ne pas se fier uniquement à la rétention native des logs de la plateforme CI.
Surveiller les comportements de pipeline anormaux : temps d’exécution inhabituels, nouveaux fichiers de workflow, accès inattendus aux secrets, builds déclenchés à des heures inhabituelles, ou pipelines s’exécutant depuis des branches non reconnues.
Activer la journalisation d’audit sur toutes les plateformes CI/CD et les systèmes SCM. Le journal d’audit de GitHub Enterprise, les événements d’audit de GitLab et le plugin de piste d’audit de Jenkins sont des points de départ.
Configurer des alertes pour les événements à haut risque : modifications de fichiers de workflow, nouvelles installations d’applications OAuth, modifications des règles de protection de branche et échecs d’approbation de déploiement.
Conserver les logs pendant au moins 90 jours (plus longtemps pour les industries réglementées). S’assurer que les logs sont immuables et à l’épreuve de la falsification. Consultez nos guides de Surveillance et Journalisation pour les modèles d’architecture.

Construire un Programme Complet de Sécurité CI/CD

Traiter les risques du OWASP Top 10 CI/CD n’est pas un projet ponctuel — c’est un programme continu. Voici une approche priorisée :

Commencer par la visibilité (CICD-SEC-10) : Vous ne pouvez pas corriger ce que vous ne pouvez pas voir. Centralisez d’abord la journalisation pour avoir une ligne de base.
Verrouiller les accès (CICD-SEC-2, CICD-SEC-5, CICD-SEC-6) : Implémentez le moindre privilège pour les identités, limitez les permissions des pipelines et assainissez l’hygiène des identifiants. Ces trois risques couvrent ensemble les surfaces d’attaque les plus courantes.
Durcir le pipeline (CICD-SEC-1, CICD-SEC-4, CICD-SEC-7) : Appliquez les contrôles de flux, prévenez le Poisoned Pipeline Execution et durcissez les configurations de vos plateformes CI/CD.
Sécuriser la chaîne d’approvisionnement (CICD-SEC-3, CICD-SEC-8, CICD-SEC-9) : Épinglez les dépendances, gouvernez les intégrations tierces et implémentez la signature et la vérification des artefacts.

Chaque couche s’appuie sur la précédente. Sans visibilité, vous ne pouvez pas valider que vos contrôles d’accès fonctionnent. Sans contrôles d’accès, le durcissement est facilement contourné. Et sans un pipeline durci, les contrôles de la chaîne d’approvisionnement peuvent être contournés.

Conclusion

Le OWASP Top 10 des Risques de Sécurité CI/CD fournit un cadre complet pour comprendre et traiter les menaces pesant sur les pipelines de livraison logicielle modernes. Comme les attaques SolarWinds, Codecov et tj-actions l’ont montré, les pipelines CI/CD sont des cibles de haute valeur que les attaquants exploitent activement.

La bonne nouvelle : chaque risque de cette liste dispose de mesures correctives pratiques et implémentables. En travaillant systématiquement sur ces risques — en commençant par la visibilité et les contrôles d’accès, puis en durcissant les pipelines et en sécurisant la chaîne d’approvisionnement — vous pouvez réduire considérablement l’exposition de votre organisation aux attaques basées sur le CI/CD.

Prêt à passer à la pratique ? Explorez nos laboratoires pratiques pour implémenter ces mesures correctives dans de vrais environnements GitHub Actions et GitLab CI, ou parcourez nos guides de Sécurité CI/CD pour des détails d’implémentation spécifiques à chaque plateforme.