Revue de Code Source DORA pour le SDLC Sécurisé et le Test Applicatif

Le Digital Operational Resilience Act (DORA) exige des entités financières qu’elles intègrent des pratiques de revue de code source DORA au sein d’un SDLC sécurisé (Secure SDLC) DORA afin d’atténuer les risques liés aux vulnérabilités applicatives et au code malveillant.

Signification de “dans la mesure du possible”

L’article 25 du DORA stipule que les programmes de test de logiciels doivent inclure des revues de code source “dans la mesure du possible”. Cette contrainte s’applique lorsque le code source est effectivement disponible pour l’entité financière. Par conséquent, la revue de code est obligatoire pour les logiciels développés en interne et pour les développements sur mesure réalisés par des tiers, tandis qu’elle peut être exclue pour les progiciels “sur étagère” (off-the-shelf) lorsque le code n’est pas fourni.

Revue de code, SAST, DAST et revue manuelle

Les entités financières doivent adopter une approche rigoureuse des tests de logiciels DORA, conformément au Règlement délégué (UE) 2024/1774 :

  • Static Application Security Testing (SAST) : Analyse statique du code source pour détecter les vulnérabilités logiques et de sécurité sans exécution du programme.
  • Dynamic Application Security Testing (DAST) : Tests dynamiques effectués avec le logiciel en cours d’exécution pour identifier les failles qui apparaissent lors de l’exécution.
  • Tests de sécurité pour les systèmes exposés : Des vérifications de sécurité approfondies sont requises pour les applications et les systèmes accessibles via Internet avant leur mise en production.

Applications personnalisées et fonctions critiques

Le niveau et l’intensité des tests doivent être corrélés à la criticité des fonctions métier soutenues par les actifs TIC. Pour les applications qui soutiennent des fonctions critiques ou importantes, le DORA prévoit :

  • Une vérification par le biais de tests que les nouveaux systèmes sont adéquats pour fonctionner comme prévu.
  • Une analyse de la qualité du logiciel développé en interne pour prévenir les erreurs pouvant causer des interruptions opérationnelles.
  • La mise en œuvre de contrôles pour sauvegarder l’intégrité du code source, en empêchant les manipulations non autorisées pendant le développement et le déploiement.

Intégration dans le cycle de développement (Secure SDLC)

  • Ségrégation des environnements : Les environnements de développement et de test doivent être rigoureusement séparés de l’environnement de production.
  • Gestion des données de test : L’utilisation de données réelles dans les environnements hors production est interdite, sauf si elles sont anonymisées, pseudonymisées ou randomisées, dans le respect de l’intégrité et de la confidentialité.
  • Gouvernance des projets : Les projets TIC ayant un impact sur des fonctions critiques doivent être rapportés régulièrement à l’organe de direction.

Preuves pour l’audit et gestion de la remédiation

  • Identification des anomalies : Chaque vulnérabilité ou anomalie détectée doit être analysée.
  • Plan d’action : Il est obligatoire d’établir un plan d’action pour corriger les lacunes, en définissant les responsabilités et les délais.
  • Suivi : La mise en œuvre des mesures correctives doit être constamment surveillée pour s’assurer que le risque résiduel reste dans les limites prévues.

FAQ

  • La revue de code est-elle obligatoire ?
  • Oui, elle est nécessaire pour tous les logiciels développés en interne ou sur mesure. Pour les logiciels tiers, elle est obligatoire “dans la mesure du possible”, c’est-à-dire lorsque le fournisseur met le code source à disposition.
  • Le SAST suffit-il ?
  • Non. Il est requis que les revues de code comprennent à la fois le SAST et le DAST pour une évaluation complète de la sécurité applicative.
  • Comment définir les priorités ?
  • Les priorités doivent suivre une approche basée sur le risque, en donnant la priorité aux systèmes qui soutiennent des fonctions critiques ou importantes et à ceux exposés sur des réseaux externes ou Internet.

Construisez des logiciels résilients : demandez une évaluation de votre SDLC sécurisé et de votre programme de test applicatif pour aligner vos processus de développement sur les exigences techniques du DORA.

Leave a Reply

Your email address will not be published. Required fields are marked *