Introduction
Le Digital Operational Resilience Act (DORA) introduit un cadre complet pour renforcer la résilience numérique des entités financières à travers l’Union européenne. Alors que l’attention se porte souvent sur la gestion interne des risques ICT sous l’Article 21, l’Article 28 déplace le focus vers l’extérieur, traitant des risques introduits par les fournisseurs de services ICT tiers.
Dans les environnements d’entreprise modernes, la livraison logicielle repose fortement sur des plateformes externes telles que les fournisseurs cloud, les outils CI/CD SaaS, les services d’hébergement de code source et les solutions de sécurité managées. DORA Article 28 intègre formellement ces dépendances dans le périmètre, exigeant des organisations qu’elles identifient, évaluent, contrôlent et surveillent continuellement les risques ICT tiers.
Cet article explique ce que DORA Article 28 exige réellement, pourquoi les pipelines CI/CD et les outils DevSecOps sont directement impactés, et comment les organisations doivent aborder la conformité dans les environnements réglementés.
Ce que couvre DORA Article 28
DORA Article 28 établit un cadre structuré pour la gestion des risques tiers ICT. Son objectif est de garantir que les entités financières maintiennent leur résilience opérationnelle même lorsque des services critiques sont fournis par des prestataires externes.
À haut niveau, l’Article 28 exige des organisations qu’elles :
- Identifient et maintiennent un inventaire des fournisseurs de services ICT tiers
- Classifient les fournisseurs selon leur criticité et leur risque
- Réalisent une due diligence avant l’intégration
- Définissent des clauses de sécurité et d’audit obligatoires dans les contrats
- Surveillent continuellement les risques tiers
- Gèrent le risque de concentration et les chaînes de dépendances
- Préparent et testent des stratégies de sortie
Contrairement aux approches traditionnelles de gestion des fournisseurs, DORA Article 28 traite les fournisseurs ICT comme des composants intégraux du paysage de risque opérationnel, et non comme des préoccupations périphériques d’externalisation.
Pourquoi le CI/CD et le DevSecOps sont explicitement dans le périmètre
Bien que DORA ne mentionne pas explicitement CI/CD ou DevSecOps, l’Article 28 s’applique clairement à eux en pratique.
Les pipelines CI/CD modernes dépendent de multiples services ICT tiers, notamment :
- Plateformes d’hébergement de code source (ex. hébergement Git SaaS)
- Plateformes d’orchestration CI/CD
- Runners de build et environnements d’exécution managés
- Dépôts d’artefacts et registres de conteneurs
- Gestion des dépendances et écosystèmes de packages
- Infrastructure cloud et services d’exécution managés
Chacun de ces services peut impacter :
- L’intégrité du code
- La sécurité de la chaîne d’approvisionnement logicielle
- La disponibilité des pipelines de livraison
- Les délais de réponse aux incidents
- Les preuves et l’auditabilité
Sous l’Article 28, ces plateformes doivent être traitées comme des fournisseurs de services ICT tiers, et leurs risques doivent être gouvernés avec la même rigueur que les systèmes internes.
Classification et criticité des tiers ICT
Une exigence clé de l’Article 28 est la classification des fournisseurs ICT tiers.
Les organisations doivent évaluer :
- Si un fournisseur soutient des fonctions critiques ou importantes
- L’impact potentiel d’une défaillance du fournisseur
- Le niveau de substituabilité
- La dépendance envers les sous-traitants et les quatrièmes parties
Dans les contextes CI/CD, les plateformes qui influencent directement le code, les builds ou les déploiements sont souvent classées comme fournisseurs ICT à fort impact ou critiques, même s’il s’agit de services SaaS largement utilisés.
Cette classification détermine la profondeur des contrôles requis, y compris les clauses contractuelles, les droits d’audit et les obligations de surveillance.
Exigences contractuelles et de gouvernance
L’Article 28 met fortement l’accent sur la gouvernance contractuelle.
Les contrats avec les fournisseurs ICT tiers doivent inclure des dispositions couvrant :
- Les exigences de sécurité de l’information
- Le contrôle d’accès et la séparation des fonctions
- Les délais de notification des incidents
- Les droits d’audit et d’inspection
- Les contraintes de localisation et de traitement des données
- La continuité d’activité et la reprise après sinistre
- Les conditions de sortie et de résiliation
Pour les outils CI/CD et DevSecOps, cela signifie que les contrats doivent explicitement traiter :
- La sécurité des environnements de build et de déploiement
- La protection contre l’injection de code non autorisée
- La rétention des preuves à des fins d’audit
- La transparence concernant les sous-traitants et l’infrastructure partagée
Surveillance continue et collecte de preuves
DORA Article 28 does not allow for “set-and-forget” vendor risk management.
Les organisations doivent :
- Surveiller continuellement la performance et la sécurité des tiers ICT
- Suivre les incidents impliquant des services tiers
- Maintenir des preuves auditables des activités de supervision
- Réévaluer les profils de risque dans le temps
Dans les environnements CI/CD, cela inclut généralement :
- Les logs des plateformes CI/CD tierces
- Les enregistrements d’accès et d’activité
- Les preuves d’intégrité des artefacts (signatures, SBOM)
- Les rapports d’incidents impliquant des services externes
- Les enregistrements de changements et d’approbations liés aux outils fournis par les prestataires
Cette exigence s’aligne étroitement avec les pratiques DevSecOps qui mettent l’accent sur l’automatisation, la traçabilité et la gouvernance basée sur les preuves.
Stratégies de sortie et risque de concentration
L’Article 28 exige explicitement des organisations qu’elles préparent des stratégies de sortie pour les services ICT tiers.
Cela inclut :
- La capacité de résilier les contrats sans perturbation inacceptable
- Des plans de migration vers des fournisseurs alternatifs
- Des contrôles pour éviter un risque de concentration excessif
En pratique, c’est l’un des aspects les plus difficiles de la conformité Article 28, particulièrement pour les plateformes CI/CD et cloud où le verrouillage fournisseur est courant.
Les organisations doivent démontrer que :
- Les pipelines de livraison critiques ne dépendent pas d’un seul fournisseur sans mesure d’atténuation
- Les plans de sortie sont documentés, réalistes et périodiquement révisés
- Les dépendances envers les sous-traitants sont comprises et gérées
Relation avec DORA Article 21
DORA Article 28 ne fonctionne pas seul. Il étend et complète l’Article 21.
- L’Article 21 se concentre sur la gestion interne des risques ICT et les contrôles
- L’Article 28 applique ces principes aux fournisseurs de services ICT externes
Dans les environnements DevSecOps réglementés, cela signifie que :
- Les contrôles de sécurité appliqués en interne doivent aussi être appliqués via les plateformes tierces
- Les preuves collectées des pipelines CI/CD doivent inclure les outils tiers
- La gouvernance et la responsabilité doivent s’étendre au-delà des frontières organisationnelles
Ensemble, les Articles 21 et 28 forment un modèle de gestion continue des risques sur l’ensemble de la chaîne de livraison numérique.
Pièges courants de l’Article 28 dans les environnements CI/CD
Les organisations rencontrent fréquemment des difficultés avec l’Article 28 en raison de :
- Treating CI/CD SaaS platforms as “low-risk utilities”
- Manquer de visibilité sur les sous-traitants utilisés par les prestataires
- L’absence de droits d’audit dans les contrats SaaS standard
- Aucune stratégie de sortie définie pour les outils CI/CD critiques
- Rétention insuffisante des preuves liées aux services tiers
Ces lacunes apparaissent souvent lors des revues réglementaires ou des audits, même dans des organisations DevSecOps par ailleurs matures.
La suite
Cet article fournit les fondations conceptuelles de DORA Article 28. Dans les prochains articles de cette série, nous explorerons :
- Modèles d’architecture DORA Article 28 pour les environnements CI/CD et cloud
- Un pack de preuves Article 28 : ce que les auditeurs attendent réellement
- Une checklist d’audit pratique pour le risque tiers ICT
- Scénarios de risque tiers spécifiques au CI/CD et signaux d’alerte
Ensemble, ces ressources fournissent une feuille de route pratique pour mettre en œuvre une gestion des risques tiers alignée sur DORA dans les environnements DevSecOps modernes.
