DORA 2026 : Comment les éditeurs open source mettent leur DSI en conformité en 5 étapes

Le Digital Operational Resilience Act (DORA) impose aux entités financières européennes — et à leurs prestataires TIC — de démontrer leur capacité à résister, se remettre et s'adapter aux incidents de cybersécurité. Ce qui change en 2026 : les régulateurs ne se contentent plus de déclarations ; ils exigent des preuves.

Pour les DSI qui s'appuient sur une stack open source, DORA n'est pas une contrainte mais une opportunité : les outils souverains, auditables et transparents répondent structurellement mieux aux exigences réglementaires que les solutions propriétaires dont le code source est inaccessible. Voici les 5 étapes concrètes.

Étape 1 : Cartographier les dépendances critiques (SBOM)

L'article 8 de DORA exige une cartographie complète des actifs TIC, y compris les dépendances logicielles tierces. Pour une stack open source, cela se traduit par la production d'un Software Bill of Materials (SBOM) — un inventaire exhaustif de tous les composants, leurs versions et leurs licences.

Outils recommandés : Syft (génère des SBOM en format CycloneDX ou SPDX), Trivy (scanner de vulnérabilités avec output SBOM), Grype (corrélation CVE sur les SBOM existants). Ces trois outils sont open source, maintenant activement, et acceptés par les auditeurs DORA en 2026.

Fréquence : le SBOM doit être régénéré à chaque build de production (intégrez-le dans votre pipeline CI/CD) et conservé pendant minimum 5 ans pour les audits réglementaires. Un diff automatique entre deux SBOM successifs vous alerte sur l'introduction de nouvelles dépendances non validées.

Étape 2 : Tests de résilience et TLPT (Threat-Led Penetration Testing)

L'article 24 de DORA impose des tests de résilience opérationnelle numérique réguliers. Pour les entités financières significatives (celles qui traitent des infrastructures critiques), ces tests incluent des TLPT (Threat-Led Penetration Tests) tous les 3 ans minimum — des simulations d'attaque réalistes basées sur le renseignement sur les menaces.

Pour les prestataires TIC open source, l'obligation n'est pas de réaliser des TLPT eux-mêmes, mais de faciliter et documenter les tests que leurs clients réaliseront sur les composants fournis. Cela implique : une documentation technique complète de l'architecture, des environnements de test isolés disponibles, et des points de contact sécurité identifiés.

Pratique concrète : publiez un security.txt à la racine de votre dépôt Git et sur votre domaine. Maintenez un programme de divulgation responsable (CVD) avec des délais de réponse définis. Ces éléments sont explicitement mentionnés dans les guidelines DORA de l'EBA comme indicateurs de maturité sécurité.

Étape 3 : Gouvernance des incidents ICT — délais de notification

L'article 17 à 23 de DORA impose des délais de notification stricts : alerte initiale sous 4 heures après classification d'un incident majeur, rapport intermédiaire sous 72 heures, rapport final sous 1 mois. Ces délais s'appliquent aux entités financières, mais les prestataires TIC doivent les soutenir contractuellement.

Pour les éditeurs open source, cela signifie : définir des critères clairs de classification des incidents (qu'est-ce qu'un incident majeur ?), maintenir un journal des incidents horodaté et infalsifiable, et être en mesure de produire un rapport post-mortem structuré dans les délais.

Outils open source : TheHive pour la gestion des incidents (FOSS, déployable on-premise pour la souveraineté des données), MISP pour le partage de renseignement sur les menaces, et Cortex pour l'automatisation de la réponse. Ces outils génèrent nativement les rapports structurés compatibles avec les exigences DORA.

Étape 4 : Gestion des risques tiers (Third-Party Risk Management)

L'article 28 à 44 de DORA est le plus contraignant pour les prestataires TIC. Il impose aux entités financières de cartographier et surveiller tous leurs prestataires critiques, d'inclure des clauses contractuelles spécifiques (droit d'audit, notification des sous-traitants, plans de sortie), et de maintenir un registre des accords avec leurs prestataires.

Pour un éditeur open source qui vend du support ou des services autour de son logiciel, cela implique : fournir à vos clients financiers un questionnaire de sécurité pré-rempli (basé sur le registre standard TIBER-EU), documenter la liste de vos propres sous-traitants et leur localisation géographique, et prévoir contractuellement un droit d'audit.

Étape 5 : Documentation et registre des actifs numériques

L'article 8 de DORA exige un registre complet et à jour de tous les actifs TIC. Pour une DSI utilisant une stack open source, ce registre doit couvrir : les applications (avec leur version, leur criticité métier, leurs dépendances), les infrastructures (serveurs, cloud, réseaux), les contrats avec les prestataires, et la documentation de résilience.

Format recommandé : le registre peut être tenu dans un outil CMDB (Configuration Management Database) open source comme iTop ou NetBox, ou dans un simple spreadsheet structuré si le périmètre est limité. L'important est qu'il soit mis à jour à chaque changement d'infrastructure et que la traçabilité des modifications soit assurée (git pour les fichiers de configuration est une approche valide).

La documentation doit être accessible en moins de 24 heures en cas d'inspection réglementaire. Prévoyez un pack de preuves DORA prêt à partager : schéma d'architecture, SBOM récent, derniers rapports de tests de résilience, journal des incidents des 12 derniers mois, et liste des contrats prestataires avec clauses DORA.

Questions fréquentes sur DORA et l'open source