Les défaillances au titre de l’article 28 de DORA proviennent rarement de politiques manquantes.
Elles proviennent de faiblesses cachées dans les pipelines CI/CD dépendants de tiers qui n’apparaissent qu’à l’occasion des audits ou des incidents.
Les auditeurs recherchent des signaux d’alerte — des indices que le risque ICT lié aux tiers n’est pas maîtrisé, pas appliqué ou non étayé par des preuves.
Les plateformes CI/CD sont une source fréquente de tels constats, car elles combinent services externes, exécution à privilèges et automatisation.
Cet article met en lumière les signaux d’alerte les plus courants au titre de l’article 28 en lien avec les pipelines CI/CD, explique pourquoi ils comptent et comment les auditeurs les interprètent, et vous fournit une checklist d’audit pour tester vos propres pipelines avant une évaluation.
Pourquoi les signaux d’alerte CI/CD comptent au titre de l’article 28
Sous DORA, le risque lié aux tiers n’est pas théorique.
Les auditeurs évaluent si une défaillance chez un prestataire tiers pourrait :
- perturber des services critiques,
- compromettre l’intégrité des systèmes,
- ou empêcher le respect des obligations réglementaires.
Les pipelines CI/CD constituent souvent des points uniques de défaillance dans la livraison logicielle. Ils détiennent des identifiants à privilèges, poussent du code en production et dépendent d’une chaîne de prestataires externes que la plupart des organisations ne cartographient jamais entièrement.
Les signaux d’alerte dans ce domaine sont donc traités comme des constats de sévérité élevée. Ils ne sont pas lus comme des lacunes techniques isolées, mais comme la preuve que le risque ICT lié aux tiers n’est pas gouverné au niveau que l’article 28 attend.
Signal d’alerte n° 1 — Aucun plan de sortie des plateformes CI/CD en SaaS
Ce que les auditeurs observent
Les organisations s’appuient fortement sur des plateformes CI/CD en SaaS mais ne parviennent pas à démontrer :
- comment migrer les pipelines,
- comment récupérer les journaux et artefacts historiques,
- comment maintenir la continuité si le prestataire devient indisponible.
Pourquoi c’est un signal d’alerte
L’article 28 de DORA exige explicitement des stratégies de sortie pour les prestataires tiers de services ICT critiques.
Un plan de sortie qui n’existe que sur le papier — sans faisabilité technique — est considéré comme insuffisant.
Conclusion typique de l’auditeur
« L’organisation est opérationnellement enfermée dans la dépendance à un prestataire ICT critique. »
À quoi ressemble une bonne pratique
Un plan de sortie crédible désigne une plateforme alternative, documente la façon dont les pipelines et les secrets y seraient reconstruits, et a été répété au moins une fois de sorte que le délai de reprise soit une valeur mesurée plutôt qu’une hypothèse. Les journaux et artefacts exportés sont conservés dans un emplacement contrôlé par l’organisation, indépendant du prestataire.
Signal d’alerte n° 2 — Runners CI partagés entre plusieurs clients
Ce que les auditeurs observent
Les jobs CI s’exécutent sur :
- des runners partagés,
- une infrastructure mutualisée,
- avec une visibilité limitée sur les contrôles d’isolation.
Souvent, les organisations ne peuvent pas expliquer :
- comment l’isolation des runners est appliquée,
- qui contrôle l’environnement d’exécution,
- si les fuites de données sont techniquement empêchées.
Pourquoi c’est un signal d’alerte
Les runners partagés augmentent :
- le risque pour la confidentialité,
- le risque pour l’intégrité,
- l’exposition aux déplacements latéraux.
Au titre de l’article 28, cela soulève des questions sur la classification du risque fournisseur et l’efficacité des contrôles.
À quoi ressemble une bonne pratique
Les pipelines critiques s’exécutent sur des runners dédiés ou éphémères dont le modèle d’isolation est documenté et attribuable à un responsable désigné. L’organisation peut expliquer, en langage clair, ce qui sépare une charge de travail d’une autre et comment cette séparation est vérifiée.
Signal d’alerte n° 3 — Aucune visibilité sur les sous-traitants ultérieurs
Ce que les auditeurs observent
Les organisations :
- contractent avec un prestataire CI/CD ou Git principal,
- mais manquent de visibilité sur les sous-traitants ultérieurs (fournisseurs cloud, runners, registres, services de supervision).
Les inventaires de fournisseurs s’arrêtent souvent au premier niveau.
Pourquoi c’est un signal d’alerte
L’article 28 de DORA exige une supervision non seulement des prestataires directs, mais aussi des chaînes de sous-traitance critiques.
L’absence de visibilité sur les sous-traitants ultérieurs indique :
- une évaluation du risque incomplète,
- une gouvernance des fournisseurs insuffisante.
À quoi ressemble une bonne pratique
L’inventaire des fournisseurs s’étend au-delà de la partie contractante jusqu’aux régions cloud, aux parcs de runners, aux registres et aux services de supervision qui se trouvent derrière elle. Les changements significatifs de cette chaîne de sous-traitants ultérieurs sont notifiés à l’organisation et déclenchent une revue plutôt que de passer inaperçus.
Signal d’alerte n° 4 — Aucun droit d’audit dans les contrats CI/CD
Ce que les auditeurs observent
Les contrats avec les prestataires CI/CD ou Git en SaaS :
- ne comportent pas de clauses d’audit ou d’inspection,
- ou contiennent des droits d’audit pratiquement inutilisables.
Dans certains cas, les équipes d’ingénierie ignorent les limitations contractuelles.
Pourquoi c’est un signal d’alerte
Sans droits d’audit :
- les contrôles ne peuvent être vérifiés de manière indépendante,
- la dépendance aux assurances du fournisseur devient inévitable.
Les auditeurs traitent cela comme un écart de conformité structurel, non comme un oubli procédural.
À quoi ressemble une bonne pratique
Les contrats accordent des droits d’audit ou d’inspection que l’organisation peut réellement exercer, ou prévoient un équivalent accepté tel que des audits mutualisés ou des rapports d’assurance indépendants. L’ingénierie et les achats partagent une même vision de ce que le contrat autorise, de sorte que la dépendance technique ne dépasse jamais le droit contractuel de la vérifier.
Signal d’alerte n° 5 — Aucune conservation des preuves pour les activités CI/CD
Ce que les auditeurs observent
Les plateformes CI/CD génèrent des journaux, des approbations et des traces d’exécution, mais :
- les journaux sont conservés sur de courtes périodes,
- les preuves sont écrasées ou inaccessibles,
- les politiques de conservation ne sont pas définies.
Les preuves sont souvent collectées après la notification d’audit, non en continu.
Pourquoi c’est un signal d’alerte
L’article 28 de DORA est guidé par la preuve.
Si une preuve ne peut être produite à la demande, les contrôles sont considérés comme inefficaces.
Ce signal d’alerte se traduit fréquemment par :
- des observations d’audit,
- des plans de remédiation,
- des revues de suivi.
À quoi ressemble une bonne pratique
Les journaux, approbations et traces d’exécution sont exportés vers un magasin indépendant et inviolable, avec une durée de conservation définie et alignée sur les obligations de l’organisation. Les preuves sont générées comme sous-produit du fonctionnement du pipeline, de sorte qu’elles sont déjà en place lorsqu’un auditeur les demande — et non assemblées en réponse à la demande.
Autres signaux d’alerte CI/CD fréquemment identifiés par les auditeurs
- Usage sans restriction des plugins de la marketplace CI/CD
- Absence de gates d’approbation pour les modifications du pipeline
- Secrets exposés à des contextes d’exécution tiers
- Absence de surveillance de la disponibilité de la plateforme CI/CD
- Application incohérente des contrôles d’un pipeline à l’autre
Chacun de ces points affaiblit la confiance dans la gestion du risque lié aux tiers.
Comment les auditeurs utilisent les signaux d’alerte
Les signaux d’alerte sont rarement évalués isolément.
Les auditeurs recherchent des tendances :
- plusieurs signaux d’alerte autour d’un même prestataire,
- des écarts entre les contrats et l’application technique,
- des liens manquants entre les contrôles et les preuves.
Lorsque des tendances émergent, les auditeurs peuvent :
- relever la criticité du fournisseur,
- élargir le périmètre de l’audit,
- exiger une remédiation dans des délais stricts.
Comment traiter ces signaux d’alerte de manière proactive
Les organisations qui obtiennent de bons résultats au titre de l’article 28 ont généralement les pratiques suivantes :
- inclure explicitement les plateformes CI/CD dans le périmètre des tiers ICT,
- appliquer les contrôles via la configuration du pipeline,
- aligner les contrats sur la réalité technique,
- générer des preuves continues et immuables.
Plus important encore, elles traitent la sécurité de la CI/CD comme une composante de la gouvernance du risque lié aux tiers, et non comme un simple outillage DevOps.
Rattacher les signaux d’alerte aux obligations de l’article 28
Chaque signal d’alerte ci-dessus renvoie à une attente précise de l’article 28 de DORA, ce qui explique pourquoi les auditeurs y accordent tant de poids.
L’absence de plan de sortie touche à l’exigence de maintenir des stratégies de sortie pour les prestataires ICT critiques. Les runners partagés et l’isolation non documentée touchent à l’efficacité des contrôles et à la classification exacte de la criticité des fournisseurs. L’absence de visibilité sur les sous-traitants ultérieurs touche à la supervision des chaînes de sous-traitance, et l’absence de droits d’audit à la capacité de vérifier les contrôles de manière indépendante plutôt que sur la confiance. Une conservation des preuves insuffisante mine tout le dispositif, car un contrôle qui ne peut être démontré à la demande est, aux fins de l’audit, un contrôle qui n’existe pas.
Vus sous cet angle, ces signaux d’alerte ne sont pas cinq problèmes techniques indépendants. Ce sont cinq manières différentes dont le même écart de gouvernance devient visible — l’écart entre ce que l’organisation croit contrôler et ce qu’elle peut réellement prouver.
Checklist d’audit des signaux d’alerte liés aux tiers en CI/CD
Les signaux d’alerte ci-dessus décrivent la façon dont des défaillances individuelles apparaissent au cours d’une évaluation. La checklist ci-dessous les transforme en une revue reproductible que vous pouvez mener avant un audit, après l’intégration d’un nouveau prestataire CI/CD ou lors d’une revue périodique du risque lié aux tiers.
Chaque case cochée correspond à une situation fréquemment identifiée comme une défaillance du risque ICT lié aux tiers. Lorsqu’un ou plusieurs éléments s’appliquent, les auditeurs peuvent classer la plateforme ou le fournisseur CI/CD comme à haut risque ou non conforme.
Gouvernance & stratégie de sortie
- ⬜ Aucun plan de sortie documenté pour les plateformes CI/CD en SaaS
- ⬜ Un plan de sortie existe mais n’a jamais été testé techniquement
- ⬜ Aucune capacité à exporter les journaux et artefacts CI/CD historiques
- ⬜ Les pipelines ne peuvent pas être redéployés sur une plateforme alternative
Infrastructure & isolation CI/CD
- ⬜ Les jobs CI s’exécutent sur des runners partagés ou mutualisés sans garanties d’isolation claires
- ⬜ Les mécanismes d’isolation des runners sont non documentés ou inconnus
- ⬜ L’environnement d’exécution CI est entièrement contrôlé par le prestataire
- ⬜ Des secrets sont exposés à des contextes d’exécution tiers
Visibilité sur les fournisseurs & sous-traitants ultérieurs
- ⬜ Le prestataire CI/CD en SaaS n’est pas répertorié dans l’inventaire des tiers ICT
- ⬜ Les sous-traitants ultérieurs (cloud, runners, registres) ne sont pas identifiés
- ⬜ Aucune classification du risque pour les tiers liés à la CI/CD
- ⬜ La criticité du fournisseur n’influence pas les contrôles appliqués
Contrôles contractuels & juridiques
- ⬜ Les contrats CI/CD n’incluent pas de droits d’audit ou d’inspection
- ⬜ Des droits d’audit existent mais ne sont pas exerçables en pratique
- ⬜ Aucun SLA contractuel de notification d’incident
- ⬜ Les clauses de sortie et de résiliation sont manquantes ou floues
Preuves & auditabilité
- ⬜ Les journaux CI/CD sont conservés pendant une durée courte ou indéterminée
- ⬜ Les enregistrements d’approbation et de modification ne sont pas traçables
- ⬜ Les métadonnées et la provenance des artefacts sont manquantes
- ⬜ Les preuves ne sont collectées manuellement que pendant les audits
Gouvernance & application des politiques CI/CD
- ⬜ Aucun gate d’approbation pour les modifications du pipeline
- ⬜ Usage sans restriction des plugins ou actions de la marketplace
- ⬜ Aucun épinglage de version ni revue pour les composants CI/CD tiers
- ⬜ Les contrôles varient d’un pipeline à l’autre sans justification
Checklist façon auditeur (Oui / Non)
| Point de contrôle | Oui | Non |
|---|---|---|
| Les plateformes CI/CD figurent dans l’inventaire des tiers ICT | ⬜ | ⬜ |
| Les fournisseurs CI/CD font l’objet d’une classification du risque | ⬜ | ⬜ |
| Des stratégies de sortie existent et sont techniquement réalisables | ⬜ | ⬜ |
| Les runners CI sont isolés et contrôlés | ⬜ | ⬜ |
| Les sous-traitants ultérieurs sont identifiés et gouvernés | ⬜ | ⬜ |
| Les droits d’audit sont définis contractuellement | ⬜ | ⬜ |
| Des SLA de notification d’incident sont en place | ⬜ | ⬜ |
| Les journaux CI/CD sont conservés et protégés | ⬜ | ⬜ |
| Les approbations et gates de politique sont appliqués | ⬜ | ⬜ |
| Les preuves peuvent être produites à la demande | ⬜ | ⬜ |
Signaux d’alerte expliqués (interprétation d’audit)
| Signal d’alerte | Pourquoi les auditeurs y prêtent attention | Contrôle attendu |
|---|---|---|
| Pas de plan de sortie | Risque de dépendance au fournisseur | Stratégie de sortie technique testée |
| Runners partagés | Risque pour la confidentialité & l’intégrité | Runners isolés ou dédiés |
| Aucune visibilité sur les sous-traitants ultérieurs | Exposition à un risque caché | Cartographie complète de la chaîne d’approvisionnement |
| Pas de droits d’audit | Aucune vérification indépendante | Clauses d’audit contraignantes |
| Pas de conservation des preuves | Les contrôles ne peuvent être prouvés | Conservation automatisée des journaux |
Comment utiliser cette checklist
Les auditeurs n’attendent pas un risque nul. Ils attendent que les risques soient identifiés, que les contrôles soient appliqués et que les preuves soient disponibles et cohérentes.
Plusieurs éléments non cochés dans une même catégorie aboutissent souvent à une classification à haut risque, à un plan de remédiation et à des audits de suivi. Utilisée en interne, la checklist est la plus efficace lorsque vous :
- l’exécutez avant un audit,
- l’exécutez après l’intégration d’un nouveau prestataire CI/CD,
- l’intégrez dans les revues du risque lié aux tiers,
- la reliez à votre checklist de sécurité CI/CD et à votre dossier de preuves.
À retenir
Les pipelines CI/CD comptent parmi les sources les plus courantes de constats d’audit au titre de l’article 28.
Des signaux d’alerte tels que :
- l’absence de stratégies de sortie,
- une isolation faible,
- l’absence de droits d’audit,
- une conservation des preuves insuffisante
signalent un risque lié aux tiers non maîtrisé.
Parcourir la checklist ci-dessus tôt — et combler les écarts qu’elle fait apparaître — transforme les pipelines CI/CD, de responsabilités d’audit en solides atouts de conformité.
Contenus liés
- Le risque lié aux tiers dans les pipelines CI/CD au titre de l’article 28 de DORA
- Dossier de preuves DORA article 28 — ce qu’il faut montrer aux auditeurs
- Architecture DORA article 28 : contrôles du risque lié aux tiers à travers les pipelines CI/CD
- Signaux d’alerte d’un audit CI/CD
- Checklist de sécurité CI/CD pour les entreprises
