L’article 28 de DORA impose aux entités financières de gérer les risques introduits par les prestataires tiers de services TIC.
Dans la livraison logicielle moderne, les pipelines CI/CD figurent parmi les systèmes les plus dépendants de tiers de l’organisation.
Les plateformes Git, les exécuteurs CI, les plugins et les registres d’artefacts ne sont pas de simples choix d’outillage : ce sont des services externes intégrés qui influent directement sur l’intégrité, la disponibilité et la résilience opérationnelle du logiciel.
Cet article porte spécifiquement sur le risque tiers au sein des pipelines CI/CD : il explique où ces risques apparaissent, comment s’applique l’article 28 de DORA et quels contrôles les auditeurs s’attendent à voir appliqués.
Pourquoi les pipelines CI/CD sont un point de concentration du risque tiers
Les pipelines CI/CD agrègent de multiples dépendances externes dans un flux d’exécution unique :
- le code source est hébergé à l’extérieur,
- les builds s’exécutent souvent sur une infrastructure partagée ou gérée,
- du code tiers est récupéré automatiquement,
- les artefacts sont stockés et distribués par des services externes.
Du point de vue de DORA, les pipelines CI/CD représentent :
- des dépendances TIC à fort impact,
- dotées d’un accès privilégié,
- fonctionnant à vitesse machine,
- et capables de propager des défaillances ou des compromissions directement en production.
Par conséquent, les plateformes CI/CD doivent être traitées comme des services TIC tiers dans le périmètre de l’article 28.
GitHub / GitLab SaaS en tant que prestataires tiers de services TIC
Exposition au risque
Les plateformes SaaS GitHub et GitLab contrôlent :
- l’accès au code source,
- les workflows d’approbation des changements,
- l’application des identités et des permissions.
Une compromission ou une mauvaise configuration peut entraîner :
- des modifications de code non autorisées,
- le contournement des approbations,
- une perte de traçabilité.
Attentes de l’article 28
Les auditeurs attendent :
- que les plateformes d’hébergement Git figurent dans l’inventaire des tiers,
- une classification claire du risque (souvent critique),
- l’application de la séparation des tâches,
- des preuves de contrôle d’accès et d’approbations.
Les journaux d’accès, les approbations de pull requests et les paramètres de protection des branches sont traités comme des preuves d’audit, et non comme de simples détails opérationnels.
Exécuteurs CI dans le cloud
Exposition au risque
Les exécuteurs CI gérés ou hébergés dans le cloud :
- exécutent du code non fiable,
- accèdent aux secrets et aux identifiants,
- interagissent avec des systèmes internes et externes.
Ils s’exécutent souvent sur une infrastructure partagée, ce qui accroît l’exposition.
Attentes de l’article 28
Au titre de l’article 28, les organisations doivent démontrer :
- l’isolation entre les exécuteurs,
- un accès contrôlé aux secrets,
- la surveillance des environnements d’exécution,
- la capacité de restreindre ou de révoquer l’accès des exécuteurs.
Les auditeurs demandent fréquemment :
« Qui contrôle l’environnement d’exécution dans lequel votre code est construit ? »
Actions et plugins de la marketplace
Exposition au risque
Les marketplaces CI/CD introduisent du code tiers non vérifié directement dans les pipelines.
Les risques incluent :
- les attaques de la chaîne d’approvisionnement,
- les mises à jour malveillantes,
- l’absence de gestion des versions,
- une propriété peu claire.
Attentes de l’article 28
Les auditeurs attendent :
- une gouvernance sur les plugins autorisés,
- une évaluation des risques pour les actions critiques,
- l’épinglage des versions et des processus de revue,
- la surveillance des changements dans le temps.
Un usage non restreint de la marketplace est souvent signalé comme une faiblesse majeure au regard de l’article 28.
Registres d’artefacts
Exposition au risque
Les registres d’artefacts stockent et distribuent :
- les résultats de build,
- les images de conteneurs,
- les bibliothèques internes.
En cas de compromission, ils peuvent :
- propager des artefacts malveillants,
- rompre l’intégrité du déploiement,
- affecter plusieurs systèmes simultanément.
Attentes de l’article 28
Les auditeurs attendent des contrôles couvrant :
- les restrictions d’accès,
- les politiques d’immuabilité,
- la signature et la vérification des artefacts,
- la conservation des métadonnées d’artefacts.
Les registres d’artefacts sont traités comme des composants centraux de la chaîne d’approvisionnement, et non comme un stockage passif.
Proxys de dépendances et dépôts externes
Exposition au risque
Les proxys de dépendances et les dépôts externes :
- récupèrent du code hors de l’organisation,
- introduisent des dépendances tierces indirectes,
- peuvent modifier leur contenu sans préavis.
Cela crée une exposition tierce cachée.
Attentes de l’article 28
Les auditeurs attendent :
- une visibilité sur les sources de dépendances,
- des contrôles pour restreindre ou mettre en cache les dépendances externes,
- une traçabilité reliant les dépendances aux builds,
- la surveillance des changements de dépendances.
Les SBOM et les journaux de dépendances sont souvent examinés en tant que preuves au titre de l’article 28.
Contrôles CI/CD essentiels attendus au titre de l’article 28
Pour l’ensemble des services tiers liés au CI/CD, les auditeurs s’attendent à voir :
- une inclusion explicite dans les inventaires de tiers,
- une classification et une gouvernance fondées sur le risque,
- une isolation des accès et le moindre privilège,
- des politiques applicables (approbations, points de contrôle),
- une surveillance continue,
- une génération automatisée des preuves.
Les pipelines CI/CD doivent appliquer ces contrôles dès la conception, et non par des procédures manuelles.
Preuves fréquemment demandées par les auditeurs
Pour le risque tiers CI/CD, les auditeurs demandent fréquemment :
- les journaux d’accès des plateformes Git,
- les journaux d’exécution CI et les métadonnées des exécuteurs,
- les registres d’approbation et les résultats des points de contrôle de politique,
- les données de signature et de provenance des artefacts,
- les alertes de surveillance impliquant des services CI/CD.
Ces artefacts servent à valider que les contrôles fonctionnent, et pas seulement qu’ils sont définis.
Lien avec les autres contrôles de l’article 28 de DORA
Les pipelines CI/CD jouent souvent le rôle de couche d’application pour :
- les exigences contractuelles,
- les politiques de sécurité,
- les contraintes de la stratégie de sortie.
Ils font le pont entre les domaines juridique, sécurité et ingénierie, ce qui les rend centraux pour la conformité à l’article 28.
À retenir
Au titre de l’article 28 de DORA, les pipelines CI/CD ne sont pas des outils d’automatisation neutres.
Ce sont des points d’intégration TIC tiers à haut risque.
Les organisations qui :
- gouvernent explicitement les services tiers CI/CD,
- appliquent les contrôles au sein des pipelines,
- et génèrent des preuves en continu
sont nettement mieux placées pour réussir les audits de l’article 28 et maîtriser le risque opérationnel réel.
Contenu associé
- Architecture de l’article 28 de DORA : contrôles du risque tiers dans les pipelines CI/CD
- Dossier de preuves de l’article 28 de DORA — ce qu’il faut présenter aux auditeurs
- Check-list de sécurité CI/CD pour les entreprises
- Signaux d’alerte des audits CI/CD
