Conformité DORA pour les équipes mobiles : comprendre le périmètre et ce qu'il faut faire

Introduction à la série sur la conformité DORA :

Le règlement DORA soulève une question légitime pour les équipes mobiles : que signifie-t-il concrètement pour la livraison iOS et Android ?

Cette série en quatre parties répond à cette question de façon pratique. Pas de plongée dans les textes réglementaires, pas de théorie. Simplement une approche de la conformité DORA pensée pour le mobile, qui fonctionne pour les équipes mobiles et AppSec et pour les responsables qui les encadrent.

• Article 1 : comprendre le périmètre et ce que vous devez réellement faire (vous êtes ici)
• Article 2 : le modèle le plus simple de référentiel de base, de verdict et d'exceptions pour les releases mobiles
• Article 3 : la bibliothèque d'exercices de résilience la plus simple pour les parcours mobiles BFSI
• Article 4 : risque lié aux tiers, gouvernance des SDK et dossiers de preuves prêts pour l'audit
  
  

---

Si vous développez ou sécurisez une application mobile de banque, services financiers et assurance (BFSI), vous connaissez déjà la partie « amusante » où la conformité rencontre l'ingénierie moderne. Votre application est à la fois un produit, une frontière de sécurité, un aimant à demandes de support et un collecteur de dépendances.

Voici maintenant le règlement DORA, suivi de près par l'expression conformité DORA, généralement livrée avec une échéance et un tableur.

Cet article est un guide orienté mobile pour rester pragmatique. Nous allons définir un périmètre mobile strict, appliquer DORA au contexte mobile et aboutir à un modèle opérationnel simple, qui fonctionne aussi bien pour les équipes mobiles que pour les décideurs.

Nous resterons ancrés dans la seule chose vers laquelle les équipes mobiles reviennent toujours : la release.

Alors, pourquoi cela semble-t-il pénible dès le départ ?

Pourquoi DORA est pénible pour les équipes mobiles et AppSec

DORA paraît souvent pénible parce qu'il arrive sous la forme d'un problème de conformité, alors que le travail mobile s'organise autour des releases. Les équipes mobiles pensent en versions d'application, numéros de build, plans de déploiement, parcours critiques et playbooks d'incident. Les demandes de conformité prennent souvent la forme de « prouvez X », sans préciser ce que X signifie pour iOS et Android.

Cela devient aussi confus parce que le risque mobile se situe rarement uniquement dans le code mobile. Un parcours mobile peut échouer à cause des services d'identité, de retards d'OTP, de la distribution des notifications push, des API backend, de la détection de fraude, d'erreurs de configuration à distance ou d'une panne chez un fournisseur tiers. Lorsqu'une exigence dit « garantir la résilience », la première question des équipes mobiles est : « La résilience de quoi, exactement, et mesurée comment ? »

La façon la plus simple de réduire cette difficulté n'est pas de combattre DORA. Il s'agit de traduire le règlement DORA en un périmètre mobile dont vous pouvez réellement être responsable, puis de produire des preuves reproductibles à chaque release, afin que la conformité DORA devienne une routine.

Bien, alors qu'est-ce que DORA en termes simples, sans transformer cet article en club de lecture réglementaire ?

DORA en langage clair, traduit dans la réalité du mobile

À un niveau général, le règlement DORA pousse les organisations vers deux résultats :

1. Maintenir les services numériques en fonctionnement en toute sécurité, y compris en cas de perturbation.
2. Démontrer cette capacité par des preuves reproductibles et vérifiables.

Pour les équipes mobiles, les « services numériques » désignent l'expérience mobile de bout en bout, pas seulement le binaire de l'application. Votre application dépend de l'identité et de l'authentification, des API backend, des OTP et des notifications push, des systèmes de fraude et de risque, des services de paiement et des SDK tiers livrés dans l'application.

Une traduction de DORA orientée mobile ressemble à ceci :

• La gestion des risques liés aux TIC définit un socle de contrôles de release mobile, avec des responsables clairement identifiés.
• La préparation aux incidents impose une évaluation d'impact par version, des échéances et un dossier de preuves que vous pouvez constituer sans exploit héroïque.
• Les tests de résilience opérationnelle consistent en des exercices sur les parcours mobiles critiques, et pas seulement en tests ponctuels.
• Le risque lié aux tiers TIC couvre la gouvernance des SDK embarqués et des fournisseurs d'exécution qui peuvent interrompre des parcours critiques.
• L'amélioration continue crée une boucle où les incidents et les exercices mettent à jour les contrôles, la supervision et les runbooks.

Si vous faites tout cela de façon constante, vous ne faites pas « seulement » de la paperasse. Vous construisez un modèle opérationnel mobile qui soutient la conformité DORA.

Définir le « périmètre DORA mobile » sur une page (ce qui est inclus, ce qui est exclu)

La clarté du périmètre est le moyen le plus rapide de réduire les remous de conformité. Voici un périmètre strict et pratique pour le travail de conformité DORA qui revient aux équipes mobiles.

Dans le périmètre des équipes mobiles

• Les artefacts de release mobile que vous livrez
  Les IPA iOS et les AAB ou APK Android, rattachés à une version et à un numéro de build précis.
• Les preuves du processus de release
  La provenance du build, la signature, les validations et la trace des contrôles exécutés pour un candidat à la release.
• Les SDK et bibliothèques tiers embarqués
  Ce qui se trouve dans l'application, ce qui a changé depuis la dernière release et qui l'a approuvé.
• Les dépendances d'exécution qui affectent les parcours mobiles critiques
  Identité et authentification, API backend, OTP et push, systèmes de fraude et de risque, paiements, configuration à distance et feature flags.
• Les parcours critiques
  Connexion, authentification renforcée, récupération de compte, paiements et virements, ainsi que l'onboarding si votre application l'inclut.

Maintenant que le périmètre est clair, nous pouvons poser la question qui garde DORA pragmatique pour les équipes mobiles.

Une seule question au niveau de la release pour garder la conformité DORA pragmatique

Pour répondre à la question « Cette release de l'application mobile est-elle conforme à nos contrôles de sécurité applicative et de résilience alignés sur DORA ? », vous devez être :

• Précis : la réponse s'applique à une version et à un build iOS ou Android particuliers.
• Reproductible : vous y répondez à chaque release, pas seulement quand la conformité le demande.
• Actionnable : elle renvoie à des contrôles et à des responsables.
• Vérifiable : le Risque et la direction peuvent évaluer à chaque fois des preuves de même forme.

Cette question ne réduit pas le règlement DORA au « mobile uniquement ». Elle définit simplement ce que les équipes mobiles peuvent crédiblement assumer : l'assurance au niveau de la release pour les artefacts mobiles et les parcours mobiles.

Pour répondre à cette question sans transformer le jour de la release en rituel, il faut un modèle opérationnel minimal.

Le modèle opérationnel minimal (fiche de release, verdict, dossier de preuves)

Pour que la question au niveau de la release trouve une réponse, il vous faut trois briques. Gardez-les légères, puis automatisez-les au fil du temps.

1) Fiche de release

C'est la « fiche d'index » de la release. Elle relie l'artefact, les preuves et la décision.

Champs minimaux :

• Identifiant de l'application (bundle id ou nom de package)
• Plateforme (iOS ou Android)
• Version et numéro de build
• Identifiant ou empreinte de l'artefact (hash ou ID de build unique)
• Référence source (dépôt et SHA du commit)
• ID d'exécution du pipeline
• Responsable de la release et date

Si vous ne pouvez pas rattacher les preuves à un artefact précis, vous ne pourrez rien prouver de façon fiable par la suite. C'est ennuyeux, mais c'est le bon genre d'ennuyeux.

2) Verdict de release

Utilisez un modèle de verdict qui correspond à la réalité et soutient la gouvernance :

• PASS
• FAIL
• PASS_WITH_EXCEPTIONS

PASS_WITH_EXCEPTIONS est valide lorsqu'il est maîtrisé. Cela suppose un responsable, une date d'expiration, des contrôles compensatoires et un plan de remédiation. Si les exceptions n'expirent jamais, elles deviennent la véritable référence.

3) Dossier de preuves

Le dossier de preuves est ce qui rend votre verdict défendable et votre récit de conformité DORA crédible.

Le dossier doit répondre aux questions suivantes :

• Qu'est-ce qui a été livré ?
• Quels contrôles ont été exécutés et qu'ont-ils trouvé ?
• En cas de risque, comment a-t-il été traité et qui l'a approuvé ?

Preuves minimales à conserver pour chaque release :

• Provenance du build et preuve de signature
• Résultats des tests de sécurité rattachés à l'artefact exact
• Liste des vulnérabilités avec sévérité et catégorie
• Écart par rapport à la précédente release approuvée, c'est-à-dire ce qui a changé
• Inventaire des SDK de la release, avec ce qui a changé depuis la dernière release
• Preuve que les exercices de résilience et les runbooks sont à jour pour les parcours critiques
• Approbations d'exceptions et dates d'expiration, le cas échéant

Pour les équipes mobiles, le gain est que cela devient reproductible. Pour les décideurs, le gain est que la revue devient cohérente et auditable.

Si vous pensez « cela ressemble encore à du travail », c'est légitime. Définissons à quoi ressemble le « bon niveau » à 30 jours pour que l'objectif reste atteignable.

Pièges courants qui créent un travail inutile, et l'alternative plus simple

Piège 1 : « Un scan dit que nous sommes conformes à DORA. »

Un scan est une preuve précieuse, mais la conformité DORA est plus large que n'importe quel résultat isolé.

Alternative plus simple : gardez l'affirmation limitée à la release. Utilisez les scans comme éléments de preuve alimentant votre verdict de release et votre dossier de preuves.

Piège 2 : une dérive du périmètre jusqu'à ce que le mobile s'occupe de tout

Lorsque la responsabilité n'est pas claire, les équipes mobiles finissent par coordonner la moitié de l'organisation.

Alternative plus simple : gardez un périmètre mobile strict. Prenez en charge les releases mobiles, les parcours mobiles critiques, la gouvernance des SDK embarqués et les preuves au niveau de la release. Travaillez avec les responsables de l'identité, de la plateforme et des fournisseurs pour les contrôles en amont.

Piège 3 : des contrôles impossibles à prouver

Si un contrôle ne peut pas être rattaché à un artefact, un rapport, un ticket ou un journal, il devient un débat récurrent.

Alternative plus simple : réécrivez les contrôles jusqu'à ce que la preuve soit évidente. Si vous ne pouvez pas le prouver, ce n'est pas encore un contrôle.

Piège 4 : des exceptions qui n'expirent jamais

Les exceptions permanentes se transforment en risque permanent.

Alternative plus simple : chaque exception nécessite un responsable, une date d'expiration, des contrôles compensatoires et un plan de remédiation. Suivez le respect des expirations.

Piège 5 : tester des composants au lieu de parcours

Les tests de composants sont utiles, mais les clients vivent des parcours.

Alternative plus simple : définissez les parcours critiques et simulez par des exercices les modes de défaillance qui les interrompent, comme la dégradation de l'identité, la latence des OTP, la perturbation des push et les pannes de fournisseurs.

Si vous ne deviez retenir qu'une chose de cet article, retenez ceci : DORA n'a pas à devenir un « projet de conformité » parallèle qui vit en dehors de votre cycle de release mobile. Lorsque vous gardez le périmètre mobile, que vous faites de la release l'unité de gouvernance et que vous générez les preuves au fil des livraisons, les exigences du règlement DORA deviennent gérables et la conformité DORA devient reproductible.

Dans le prochain article, nous allons rendre tout cela encore plus concret. Nous définirons un référentiel de contrôles de release mobile aligné sur DORA simple, nous montrerons comment le transformer en verdicts clairs PASS, FAIL, PASS_WITH_EXCEPTIONS, et nous partagerons la façon la plus simple de gérer les exceptions sans ralentir la livraison.

Où Ostorlab s'inscrit dans ce périmètre DORA mobile

Un scan est un élément de preuve, pas un verdict DORA (piège 1). Voici les parties du dossier de preuves qu'Ostorlab peut produire pour vos releases mobiles, ce dont il a besoin de votre part et ce qui reste à la charge de votre équipe.

Ce que vous obtenez pour le dossier de preuves.

• Résultats de tests de sécurité rattachés au build : résultats de scan par build et par release sur le store, chaque vulnérabilité étant classée critique, élevée, moyenne ou faible, et les vulnérabilités potentielles étant conservées séparément. Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans code source, et Mobile DAST exécute l'application et capture le trafic, les stack traces et les captures d'écran.
• Inventaire des SDK par release : les SDK et bibliothèques natives de chaque release, avec leurs versions et leur emplacement dans le bundle de l'application, associés aux vulnérabilités connues et suivis d'une release à l'autre.
• Test des parcours critiques derrière la connexion : Ostorlab se connecte avec vos comptes de test, saisit les codes à usage unique reçus par SMS, e-mail ou TOTP, et teste la connexion, le renouvellement de jeton, l'invalidation de session et l'application de la MFA, y compris les parcours d'authentification renforcée. Un pentest par agents IA de l'application et de ses API ajoute un exploit fonctionnel que vous pouvez rejouer pour chaque vulnérabilité trouvée par un agent IA.
• Preuve de remédiation : les vulnérabilités sont suivies sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et un nouveau test après correction confirme si le problème est résolu.

Ce dont vous avez besoin.

• L'artefact de release (APK, AAB ou IPA), ou l'application depuis le store ou TestFlight.
• Des scans intégrés à votre pipeline CI/CD, afin que chaque build soit scanné ; des exécutions de pipeline planifiées maintiennent une cadence hebdomadaire les semaines sans release.
• Des comptes de test et la réception des codes à usage unique, afin que la connexion, les paiements et les modifications de compte soient testés, et pas seulement l'écran de connexion.

Ce qui reste à la charge de votre équipe. Ostorlab couvre les applications mobiles et les API qui les soutiennent. Le verdict de release, les approbations d'exceptions, la classification des fonctions métier et votre programme de tests restent de votre ressort. Ostorlab ne réalise pas de tests d'intrusion fondés sur la menace (TLPT) et ne les remplace pas : il vous aide à aborder un TLPT avec les problèmes connus de l'application et des API déjà corrigés, puis à retester ensuite les éléments du plan de remédiation relatifs à l'application et aux API. Les exigences au-delà de la couche applicative, comme le réseau, la sécurité physique, la sauvegarde et la gestion des incidents, restent du ressort d'autres outils et équipes.

Preuves.

• Tests de résilience DORA pour les applications de mobile banking associe chaque exigence de test DORA à ce que fait Ostorlab et à ce qui reste à votre charge.
• L'étude de cas Bumble montre un point de contrôle de release en pratique : les releases sont bloquées tant que les vulnérabilités High et Critical ne sont pas corrigées et que la correction n'est pas confirmée.
• Pour votre revue du risque lié aux tiers TIC : Ostorlab dispose d'un rapport SOC 2 Type II (critères de sécurité), du 18 nov. 2024 au 18 avr. 2025, et l'audit de la période en cours est en cours. Avec le plan Enterprise, vous pouvez choisir la résidence des données dans l'UE ou exécuter les scans en local.

Prochaine étape. Établissez un point de départ : scannez chaque application destinée aux clients une fois avec un scan gratuit depuis le store, puis réservez une démo pour planifier les tests sur vos releases.

À suivre : Conformité DORA pour les releases mobiles : le modèle le plus simple de référentiel, de verdict et d'exceptions Si vous êtes responsable de la préparation des releases mobiles, des points de contrôle AppSec ou de la validation par le Risque, c'est l'article qui fait passer DORA de « nous devrions faire quelque chose » à « voici exactement comment nous gérons nos releases ».