Guide · Cybersécurité · DORA

Sécurité des applications sous DORA : SAST, DAST, SBOM et cycle de vie sécurisé dans la banque et l'assurance

DORA (règlement (UE) 2022/2554) s'applique depuis le 17 janvier 2025 et fait de la sécurité du logiciel une obligation supervisée : les entités financières doivent identifier, protéger, détecter et tester les systèmes TIC qui soutiennent leurs fonctions critiques ou importantes, et le démontrer par des preuves. Ce guide traduit ces obligations en pratiques concrètes de sécurité des applications (SAST, DAST, SBOM, gestion des secrets, tests de résilience) et explique comment nous les intégrons au cycle de vie du logiciel des banques et des assureurs.

Ceci n'est pas un conseil juridique : c'est un guide opérationnel destiné aux CISO, CTO, responsables du développement et de la conformité. Références réglementaires vérifiées le 15 septembre 2026 ; les obligations concrètes dépendent du type d'entité et de la criticité de chaque fonction.

Ce que DORA exige du logiciel, et où il le dit

DORA ne nomme ni outils ni méthodologies : il fixe des résultats. Son cadre de gestion du risque lié aux TIC (articles 5 à 16) oblige à inventorier les actifs, à les protéger, à détecter les anomalies et à se rétablir ; le chapitre sur les incidents (articles 17 à 23) exige de les classer et de les notifier ; celui sur les tests de résilience opérationnelle numérique (articles 24 à 27) exige un programme de tests annuel ; et celui sur les tiers (articles 28 à 30) étend tout ce qui précède au logiciel et aux services que l'entité achète.

Le règlement délégué (UE) 2024/1774, qui précise le cadre de gestion du risque lié aux TIC, descend au niveau de détail qui intéresse une équipe de développement : la politique relative aux projets TIC doit couvrir l'acquisition, le développement et la maintenance des systèmes ; toutes les exigences, y compris celles de sécurité, doivent être testées avant d'approuver la mise en production ; et les résultats des tests de sécurité doivent faire l'objet d'un suivi et se traduire par des mesures actualisées sans retard injustifié lorsque le système soutient une fonction critique ou importante.

Article 8 — identification : inventaire des actifs TIC, des dépendances et des fonctions qu'ils soutiennent, tenu à jour.
Article 9 — protection et prévention : politiques de sécurité, gestion des correctifs et des mises à jour, segmentation et contrôle des accès.
Article 10 — détection : mécanismes de détection des anomalies avec seuils d'alerte et surveillance continue.
Article 11 — réponse et rétablissement : plans de continuité des activités TIC et de rétablissement testés.
Articles 24 et 25 — tests : programme annuel comprenant, entre autres, des évaluations et analyses de vulnérabilité, des analyses de sources ouvertes, des examens du code source lorsque cela est possible, des tests fondés sur des scénarios, des tests de bout en bout et des tests de pénétration.
Article 26 — TLPT : tests de pénétration fondés sur la menace (cadre TIBER-EU) au moins tous les trois ans pour les entités désignées par l'autorité.
Articles 28 à 30 — tiers : les logiciels et services TIC contractés entrent dans le même cadre, avec des clauses contractuelles minimales et un registre des accords.

De la norme à la pratique : neuf contrôles de sécurité des applications

Voici les contrôles qui couvrent les obligations précédentes dans un cycle de vie logiciel moderne. L'ordre compte : chacun produit les preuves dont le suivant a besoin et que le superviseur demandera.

1. Inventaire et classification par fonction critique

Chaque application, service et composant relié à la fonction métier qu'il soutient et à sa criticité. Sans cela, impossible de prioriser ni de justifier le périmètre des tests (article 8).

2. Modélisation des menaces dès la conception

Avant d'écrire du code : quels actifs l'application manipule, qui peut l'attaquer et par où. C'est le contrôle le moins coûteux et celui qui évite le plus de défauts ; il alimente les exigences de sécurité que le RTS impose de tester.

3. SAST à chaque changement de code

Analyse statique intégrée au pipeline, avec des quality gates qui bloquent la mise en production selon la sévérité. C'est la manière pratique de satisfaire à l'examen du code source que DORA demande « lorsque cela est possible » (article 25) et de conserver la trace de chaque constat et de sa correction.

4. SCA et SBOM : la chaîne d'approvisionnement logicielle

Inventaire des composants tiers (SBOM) et analyse de composition pour connaître leurs vulnérabilités dans le temps. Il couvre le risque lié aux tiers des articles 28 à 30 et la sécurité de la chaîne d'approvisionnement qu'exige également NIS2.

5. Gestion des secrets et infrastructure as code

Aucun secret dans les dépôts ni dans les images ; des identifiants renouvelés par rotation et gérés de manière centralisée ; une infrastructure déclarée en code et analysée comme le logiciel lui-même (article 9).

6. DAST et tests de pénétration avant la production

Tests dynamiques contre l'environnement de préproduction à chaque version significative et test de pénétration planifié dans le programme annuel (articles 24 et 25). Les constats entrent dans le même flux de correction que ceux du SAST.

7. Gestion des vulnérabilités avec des délais selon la criticité

Un registre unique des vulnérabilités (code, composants, infrastructure) avec des délais de correction selon la sévérité et la criticité de la fonction, et des preuves de l'application des correctifs (article 9).

8. Journalisation, détection et réponse

Journaux centralisés, détection continue (SIEM/SOC) et playbooks de réponse testés lors d'exercices (articles 10 et 11). Les incidents majeurs sont classés et notifiés à l'autorité dans les délais fixés par les normes techniques de DORA : notification initiale en quelques heures, puis rapport intermédiaire et rapport final.

9. Tests de résilience et TLPT

Programme annuel documenté pour tous les systèmes critiques ou importants (article 24) et, pour les entités désignées, tests fondés sur la menace tous les trois ans (article 26), avec les constats intégrés au plan de remédiation.

Recoupements utiles : NIS2 et ISO/IEC 27001

Pour les entités financières, DORA est la norme sectorielle et prévaut sur NIS2 (directive (UE) 2022/2555) dans ce qu'il régit, mais il convient de connaître les deux : NIS2 s'applique à d'autres sociétés du groupe et à de nombreux fournisseurs, et son article 21 énumère des mesures qui coïncident point par point avec les contrôles précédents : sécurité de l'acquisition, du développement et de la maintenance des systèmes, gestion et divulgation des vulnérabilités, sécurité de la chaîne d'approvisionnement, cryptographie, contrôle des accès et authentification multifacteur.

ISO/IEC 27001:2022 est la manière la plus efficace d'ordonner les preuves : les contrôles de l'annexe A sur le cycle de vie de développement sécurisé, les exigences de sécurité des applications, l'architecture sécurisée, le codage sécurisé, les tests de sécurité dans le développement et l'acceptation, le développement externalisé et la séparation des environnements (8.25 à 8.31) sont exactement ce qu'un inspecteur DORA veut voir documenté. Vermont Solutions opère sous certification ISO/IEC 27001:2022.

Check-list en douze points pour le CISO et le CTO

Inventaire des applications relié aux fonctions critiques ou importantes, revu au moins une fois par an.
Exigences de sécurité définies par application et testées avant chaque mise en production.
SAST avec quality gates dans le pipeline et preuve de correction pour chaque constat.
SBOM généré à chaque build et analyse de composition avec alertes sur les nouvelles vulnérabilités.
Gestion centralisée des secrets et analyse de l'infrastructure as code.
DAST en préproduction et test de pénétration annuel documentés dans le programme de tests.
Registre unique des vulnérabilités avec des délais de correction selon la sévérité et la criticité.
Journaux centralisés, détection continue et playbooks de réponse testés lors d'exercices.
Procédure de classification et de notification des incidents majeurs, avec délais et responsables.
Clauses de sécurité, d'audit et de sortie dans les contrats de logiciels et de services TIC.
Programme annuel de tests de résilience approuvé par la direction et, le cas échéant, TLPT planifié.
Preuves de tout ce qui précède générées par le processus lui-même, et non rassemblées à la main avant l'inspection.

Comment nous procédons chez Vermont Solutions

Nous intégrons les contrôles au pipeline de livraison de l'entité, et non dans un projet à part : SAST, analyse de composition et SBOM à chaque build, DAST en préproduction, gestion des secrets et analyse de l'infrastructure as code, avec des quality gates qui laissent des preuves automatiques. Nous concevons des modèles d'identité à moindre privilège (IAM/PAM, Zero Trust) et déployons une visibilité et une détection continues (SIEM/SOC) avec des processus de réponse alignés sur la continuité d'activité.

Nous travaillons sur des plateformes critiques de banque et d'assurance qui ne peuvent pas s'arrêter (cores legacy, grids de calcul, Kubernetes hybride) et sous certification ISO/IEC 27001:2022. Chez un assureur européen, le renforcement des accès (MFA sur les rôles critiques et retrait des protocoles hérités) a fait progresser le score de sécurité Microsoft 365 de 30 % par rapport à une base de 11,48 %, sans friction pour les utilisateurs.

Questions fréquentes

DORA impose-t-il le SAST et le DAST ?

Il ne nomme aucun outil. Il exige de tester les exigences de sécurité avant la production, d'examiner le code source lorsque cela est possible et de réaliser des tests de pénétration dans le cadre d'un programme annuel. Le SAST et le DAST sont la manière pratique et traçable de s'y conformer.

À quelle fréquence faut-il réaliser des tests de sécurité ?

Le programme de tests de résilience opérationnelle numérique est annuel pour les systèmes qui soutiennent des fonctions critiques ou importantes (article 24), avec des évaluations de vulnérabilité et des tests de pénétration en son sein. Les entités désignées par leur autorité réalisent en outre des tests de pénétration fondés sur la menace (TLPT) au moins tous les trois ans (article 26).

Qu'en est-il du logiciel que nous achetons à des tiers ?

Il entre dans le même cadre : les articles 28 à 30 exigent une due diligence, des clauses contractuelles minimales (sécurité, audit, incidents, sortie) et un registre des accords. En pratique, cela se couvre par le SBOM, l'analyse de composition et des clauses de sécurité dans les contrats.

NIS2 s'applique-t-elle aussi à une banque ou à un assureur ?

Pour les entités financières, DORA est la norme sectorielle et prévaut dans ce qu'il régit. NIS2 reste pertinente pour d'autres sociétés du groupe et pour de nombreux fournisseurs, et ses mesures de l'article 21 coïncident avec les contrôles de ce guide.

Quels sont les délais pour notifier un incident majeur ?

Les normes techniques de DORA fixent une notification initiale dans les quelques heures qui suivent la classification de l'incident comme majeur, un rapport intermédiaire sous quelques jours et un rapport final environ un mois plus tard. Les délais exacts dépendent de la norme technique en vigueur et de l'autorité compétente ; la procédure interne doit les fixer avec des noms et des heures.

Assessment de sécurité des applications sous DORA

Nous examinons votre inventaire d'applications critiques, votre pipeline de livraison et les preuves disponibles, et nous vous remettons le plan de contrôles avec responsables et délais. Sans rien changer en production tant que le plan n'est pas approuvé.

Demander un assessment →

Contenus associés

Dernière mise à jour : 2026-09-15. Contenu éditorial de Vermont Solutions, citable sous attribution avec un lien vers cette page. Ne constitue pas un conseil juridique.