La complexité croissante des infrastructures informatiques dans le secteur financier impose une évaluation approfondie des dépendances logicielles. Avec le Digital Operational Resilience Act (DORA), la gestion des bibliothèques tierces et l’analyse open source deviennent des éléments centraux pour garantir la résilience opérationnelle et la sécurité des actifs numériques, comme prévu par l’article 25 du règlement.

Analyse open source prévue par DORA

DORA établit que les analyses de logiciels open source doivent être incluses dans le programme de test de la résilience opérationnelle numérique. L’objectif est de gérer les risques liés à la chaîne d’approvisionnement logicielle : une vulnérabilité dans une bibliothèque partagée peut compromettre l’ensemble de l’infrastructure d’une entité financière. Selon les exigences réglementaires, l’analyse open source permet d’identifier préventivement les failles de sécurité dans les composants tiers afin de garder le contrôle sur les risques opérationnels.

Dépendances logicielles et Règlement délégué (UE) 2024/1773

Le Règlement délégué (UE) 2024/1773 impose aux entités financières d’analyser le code source et les logiciels propriétaires provenant de tiers ou de projets open source avant la mise en production, en recherchant les vulnérabilités et le code malveillant. Des tests statiques et dynamiques, la détection d’anomalies et l’adoption de plans de remédiation sont requis.

Inventaire des dépendances et suivi des vulnérabilités CVE

Une gestion efficace des dépendances nécessite le suivi systématique des bibliothèques tierces, le monitoring des versions, des mises à jour opportunes et l’enregistrement ponctuel de chaque vulnérabilité impactant les systèmes TIC. Les procédures doivent prévoir :

• Le suivi et le traçage constants des bibliothèques, y compris open source, avec la gestion des mises à jour correspondantes.
• L’enregistrement de chaque vulnérabilité détectée.
• La priorisation du déploiement des correctifs (patchs) en fonction de la criticité de la vulnérabilité et du profil de risque des actifs concernés.
• Pour les actifs critiques ou importants, le suivi doit être rigoureux ; pour les actifs “off-the-shelf” non critiques, le traçage doit tout de même être garanti dans la mesure du possible.

SBOM : état de l’art pour la conformité

Bien que DORA et les RTS ne mentionnent pas explicitement la SBOM (Software Bill of Materials), la nécessité de tracer les bibliothèques et les versions fait de la SBOM la norme technique la plus efficace et la plus utilisée pour assurer la conformité. Une SBOM fonctionne comme un inventaire complet des composants logiciels, facilitant le monitoring proactif et la réponse rapide aux nouvelles vulnérabilités publiques (CVE) impliquant des bibliothèques spécifiques utilisées par l’entité.

Intégration dans le cycle de vie du développement (SDLC) et gestion des correctifs

L’analyse open source requise par DORA doit être intégrée dans le cycle de vie du développement logiciel (SDLC). Les entités sont tenues de protéger l’intégrité du code source — interne comme tiers — et de lier ces activités à la gestion des correctifs. Les mises à jour logicielles doivent être testées et déployées dans des environnements de pré-production (staging) représentatifs avant la mise en production, afin d’éviter les interruptions opérationnelles. Si une vulnérabilité open source n’est pas couverte par un correctif, il est obligatoire d’identifier et d’activer d’autres mesures d’atténuation.

FAQ

• DORA impose-t-il la SBOM ?
• La réglementation exige de tracer l’utilisation des bibliothèques tierces et open source, en surveillant leurs versions et mises à jour. Bien qu’elle n’utilise pas le terme “SBOM”, la création d’une nomenclature logicielle représente la solution technique la plus efficace pour respecter cette exigence.
• Comment gérer les bibliothèques dans les applications héritées (legacy) ?
• Les entités doivent surveiller si les actifs TIC sont toujours supportés par les fournisseurs ou les développeurs. Pour les actifs hérités ou non supportés, un plan de gestion des risques visant à atténuer leur obsolescence est indispensable.
• L’analyse open source remplace-t-elle le test d’intrusion (pentest) ?
• Non. L’analyse open source se concentre sur les dépendances et le code, et fait partie des tests ordinaires de résilience prévus par l’article 25. Ces activités doivent être intégrées avec des évaluations de vulnérabilité et des tests d’intrusion pour évaluer la sécurité globale des systèmes.

Gérez votre chaîne d’approvisionnement logicielle : demandez une révision du risque logiciel et des dépendances critiques pour aligner votre développement sur les exigences de sécurité de DORA.