Bangladesh Bank ICT Security : testez votre application bancaire mobile comme le décrit la ligne directrice.
La Guideline on ICT Security, version 4.0, de Bangladesh Bank demande aux banques et aux autres organisations régulées d'appliquer SAST et DAST au code de leur application mobile, de mettre en œuvre le durcissement ou le blindage de l'application, d'imposer l'authentification multifacteur et des contrôles de session, et de réaliser des tests de pénétration au moins une fois par an et après tout changement important. Le Cybersecurity Framework, version 1.0 (2026), doit être respecté au plus tard le 31 décembre 2026. Ostorlab teste ces contrôles dans votre application et dans les API qui la sous-tendent, à chaque version.
- Tests statiques et dynamiques de la version que vous livrez, sans besoin du code source
- Vérifie la détection du root et du jailbreak, l'anti-altération, l'anti-instrumentation et le pinning, ainsi que la réaction de l'application lorsqu'elles se déclenchent
- Teste la connexion, les codes à usage unique, la MFA et la gestion des sessions avec vos comptes de test
- Suit l'application jusque dans ses API, même avec TLS pinning, avec un exploit rejouable pour chaque résultat d'un agent IA
- Qui est concerné
- Les banques, NBFI, fournisseurs de MFS, PSP, PSO et autres prestataires de services financiers régulés par Bangladesh Bank
- Date clé
- Mise en conformité avec le Cybersecurity Framework au plus tard le 31 décembre 2026 (circulaire BRPD-2 n° 02)
- Objet
- Banque en ligne et sur application, services financiers mobiles, VAPT et API
- Référence principale
- Guideline on ICT Security, version 4.0 (2023), publiée par la circulaire BRPD n° 10 du 19 juin 2023
La construction des règles de Bangladesh Bank
L'ICT Security Guideline fixe le socle technique, et le Cybersecurity Framework de 2026 s'appuie sur elle. Les dates ci-dessous concernent les textes cités sur cette page.
- 16 mars 2023
Lignes directrices sur le cloud computing
La circulaire BRPD n° 05 de 2023 publie les lignes directrices sur le cloud, et les services cloud déjà utilisés devaient s'y conformer au plus tard le 31 décembre 2023.
- 19 juin 2023
ICT Security Guideline, version 4.0
La circulaire BRPD n° 10 enjoint à toutes les banques agréées (scheduled banks) de suivre la version 4.0, qui remplace la version de 2015, avec effet immédiat.
- 13 juillet 2023
La version 4.0 pour les institutions financières
La circulaire DFIM n° 08 donne la même instruction aux institutions financières, également avec effet immédiat.
- 29 mars 2026
Cybersecurity Framework, version 1.0
La circulaire BRPD-2 n° 02 adresse le cadre aux banques, aux sociétés de financement, aux fournisseurs de MFS, aux prestataires de services de paiement et aux opérateurs de systèmes de paiement.
- 31 décembre 2026
Échéance de mise en conformité avec le cadre
La conformité avec le Cybersecurity Framework doit être assurée au plus tard à cette date.
- Chaque année
Tests de pénétration
Des tests de pénétration internes et externes au moins une fois par an et après toute mise à niveau importante de l'infrastructure ou d'une application, et des scans de vulnérabilité internes au moins une fois par semestre.
Les règles de Bangladesh Bank, appliquées à votre application mobile
Pour chaque règle : ce que dit le texte, ce que cela implique pour une application bancaire mobile, comment Ostorlab vous aide et ce qui reste du ressort de votre équipe.
- Guideline on ICT Security v4.0, 11.4.12 et 11.4.13
Appliquer SAST et DAST à l'application mobile
Ce que dit le texte
Appliquez des pratiques de développement sécurisé, comme la validation des entrées, l'encodage des sorties et le stockage sécurisé des données sensibles dans l'application. Réalisez régulièrement des tests de sécurité statiques et dynamiques des applications (SAST et DAST) pour identifier et corriger les vulnérabilités de sécurité du code de l'application mobile.
Ce que cela implique pour votre application mobile
Rares sont les régulateurs qui citent aussi directement SAST et DAST pour l'application mobile. « Régulièrement » correspond à un rythme de release : testez chaque build avant qu'il n'arrive sur le store.
Comment Ostorlab vous aide
Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans besoin du code source, y compris par analyse de propagation (taint) à travers les SDK intégrés. Mobile DAST exécute l'application, maintient les sessions authentifiées et capture le trafic, les traces d'appels et les captures d'écran. Les deux s'exécutent depuis votre pipeline CI/CD à chaque build.
Ce qui reste de votre ressort
La formation au développement sécurisé et les revues du code de votre backend.
- Guideline on ICT Security v4.0, 11.4.14 et 11.7.8
Durcir et blinder l'application
Ce que dit le texte
Mettez en œuvre des mécanismes de durcissement (ou de blindage) de l'application pour la protéger contre l'altération, les usages abusifs, le vol de propriété intellectuelle et l'exploitation de vulnérabilités. Pour les services financiers mobiles, prenez des mesures pour que les appareils mal configurés ne puissent pas accéder aux ressources de l'entreprise, et refusez activement l'accès aux données de l'entreprise à tout appareil qui se trouve dans un état non sécurisé.
Ce que cela implique pour votre application mobile
Le blindage est attendu. Ce qui compte, c'est qu'il tienne lorsque quelqu'un reconditionne l'application, l'instrumente à l'exécution ou l'exécute sur un téléphone rooté ou jailbreaké.
Comment Ostorlab vous aide
Mobile Shielding Scan exécute l'application dans des environnements rootés et jailbreakés, tente de contourner la détection du root et du jailbreak, l'anti-altération, l'anti-instrumentation et le TLS pinning, et montre si l'application bloque le parcours, refuse de démarrer ou continue de fonctionner. Vous obtenez un score de durcissement et des preuves de contournement.
Ce qui reste de votre ressort
Le choix et la configuration de votre produit de blindage ou de protection à l'exécution.
- Guideline on ICT Security v4.0, 11.4.2, 11.4.6, 11.4.7 et 11.4.11
Imposer la MFA et sécuriser les sessions pour les transactions en ligne
Ce que dit le texte
Mettez en œuvre l'authentification multifacteur pour toutes les transactions financières en ligne. Une session en ligne doit se terminer automatiquement après une durée fixe, sauf si le client se réauthentifie, et une gestion sécurisée des sessions doit empêcher le détournement de session, avec des identifiants de session uniques, des cookies sécurisés et l'application effective de l'expiration des sessions. Les comptes de banque en ligne sont bloqués après plusieurs saisies erronées du code PIN.
Source :Guideline on ICT Security v4.0, 11.4.2, 11.4.6, 11.4.7 et 11.4.11
Ce que cela implique pour votre application mobile
La MFA sur chaque transaction financière, l'expiration des sessions et le verrouillage sont des paramètres concrets que vous pouvez tester dans l'application et son backend.
Comment Ostorlab vous aide
Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et l'application effective de la MFA, et l'analyse du trafic montre comment les identifiants transitent de l'application vers le backend.
Ce qui reste de votre ressort
Le choix des méthodes d'authentification et des valeurs de la politique, comme les délais d'expiration et les seuils de verrouillage.
- Guideline on ICT Security v4.0, 11.7.18 et 11.7.19
Authentifier les paiements mobiles côté serveur
Ce que dit le texte
Mettez en place une authentification à la connexion et une authentification des transactions fondée sur le risque et sur le montant. Protégez les paiements mobiles et l'accès aux données sensibles par une authentification robuste du client, notamment la MFA pour l'enregistrement dans l'application, un code PIN, un mot de passe, un schéma ou une donnée biométrique configurables, des mots de passe à usage unique basés sur le temps, la récupération automatique de l'OTP, un nombre maximal de tentatives échouées, une durée maximale pour les sessions inactives, et une authentification traitée uniquement côté serveur du propriétaire de l'application.
Ce que cela implique pour votre application mobile
Chaque élément de la liste peut être vérifié sur l'application en cours d'exécution. Le dernier est essentiel : l'application ne doit pas décider seule qu'un utilisateur est authentifié.
Comment Ostorlab vous aide
Ostorlab saisit les codes à usage unique reçus par SMS, e-mail ou TOTP avec vos comptes de test et teste l'application effective de la MFA et les parcours d'authentification renforcée, y compris les tentatives de manipulation par un attaquant, ainsi que les appels d'API derrière les modifications de compte.
Ce qui reste de votre ressort
Le choix des méthodes d'authentification et des plafonds de transaction.
- Guideline on ICT Security v4.0, 11.7.16, 11.7.17 et 11.7.23
Lier les appareils et signaler les nouveaux
Ce que dit le texte
Mettez en œuvre l'enregistrement ou la liaison des appareils à partir de plusieurs propriétés propres à l'appareil, afin que seuls les appareils enregistrés puissent accéder aux serveurs backend. Informez l'utilisateur de chaque enregistrement d'un nouvel appareil, tenez un registre des appareils enregistrés, et détectez les tentatives de connexion simultanées multiples en avertissant l'utilisateur par un canal alternatif, comme un rappel téléphonique, un SMS ou un e-mail.
Source :Guideline on ICT Security v4.0, 11.7.16, 11.7.17 et 11.7.23
Ce que cela implique pour votre application mobile
La liaison de l'appareil est appliquée par le backend. Une requête provenant d'un appareil non enregistré, ou un jeton rejoué, devrait être refusé par l'API, et pas seulement masqué dans l'application.
Comment Ostorlab vous aide
Ostorlab intercepte le trafic de l'application, même avec TLS pinning, et teste les API à la recherche de contrôles d'autorisation défaillants (BOLA, BFLA, IDOR), d'usages abusifs des jetons et des sessions, et d'abus comme l'énumération, le rejeu et l'automatisation, avec les requêtes et réponses à l'appui de chaque résultat.
Ce qui reste de votre ressort
La conception de la liaison, les notifications de nouvel appareil et la surveillance des anomalies de connexion.
- Guideline on ICT Security v4.0, 11.7.10, 11.7.11 et 11.7.20 à 11.7.22
Ne laisser aucune donnée sensible sur l'appareil
Ce que dit le texte
Désactivez la saisie automatique des identifiants de connexion et des mots de passe, ainsi que le presse-papiers pour les données sensibles, avec en option un clavier intégré à l'application. Ne stockez pas d'informations sensibles dans un espace de stockage partagé avec d'autres applications, supprimez les données confidentielles des caches et de la mémoire après usage, et effacez les données sensibles propres à l'application de la mémoire temporaire et permanente à la déconnexion ou à la fin de l'instance de l'application.
Source :Guideline on ICT Security v4.0, 11.7.10, 11.7.11 et 11.7.20 à 11.7.22
Ce que cela implique pour votre application mobile
Les jetons, données de compte et données personnelles laissés dans le stockage, les caches ou les journaux peuvent être lus par un malware ou par toute personne qui détient le téléphone.
Comment Ostorlab vous aide
Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, détecte les erreurs de configuration qui affaiblissent la protection du transport et des sessions, et teste les API derrière les transactions.
Ce qui reste de votre ressort
La conception du clavier intégré et les paramètres de saisie de chaque écran.
- Guideline on ICT Security v4.0, 6.2.1 à 6.2.3 et 6.2.7 ; Cybersecurity Framework v1.0, 5.1.2.25
Scanner et réaliser des tests de pénétration à un rythme fixe
Ce que dit le texte
Réalisez des scans de vulnérabilité périodiquement et après tout changement important, des scans internes au moins une fois par semestre, avec de nouveaux scans jusqu'à la résolution de toutes les vulnérabilités à risque élevé, et un scan des systèmes et applications critiques une fois par an par une partie indépendante, avec un plan de correction assorti d'échéances. Réalisez des tests de pénétration internes et externes au moins une fois par an et après toute mise à niveau ou modification importante de l'infrastructure ou d'une application. Le Cybersecurity Framework de 2026 reprend la règle des tests de pénétration annuels.
Source :Guideline on ICT Security v4.0, 6.2.1 à 6.2.3 et 6.2.7 ; Cybersecurity Framework v1.0, 5.1.2.25
Ce que cela implique pour votre application mobile
L'application et ses API sont des applications. Une version majeure est une modification importante d'une application, ce qui déclenche un nouveau test de pénétration en plus du test annuel.
Comment Ostorlab vous aide
Lancez des scans automatisés depuis votre pipeline CI/CD à chaque build et surveillez les versions publiées sur les stores sans déclenchement manuel. Les résultats reçoivent un niveau critique, élevé, moyen ou faible, sont suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et sont retestés une fois le correctif livré.
Ce qui reste de votre ressort
Le scan annuel indépendant, les tests de l'infrastructure et du réseau, et le plan de correction.
- Guideline on ICT Security v4.0, 6.2.6 et 11.7.15
Faire tester les applications par des évaluateurs internes et indépendants
Ce que dit le texte
L'organisation peut s'assurer que ses applications ont passé avec succès des évaluations de vulnérabilité, des scans et des tests d'intrusion approfondis et répétés pour identifier les faiblesses, par l'intermédiaire d'évaluateurs internes et indépendants. La méthodologie de test de pénétration repose sur une approche reconnue par la profession, comme NIST SP800-115, couvre les systèmes critiques, teste depuis l'intérieur et l'extérieur du réseau, tient compte des menaces des 12 derniers mois et précise la conservation des résultats des tests et des corrections.
Ce que cela implique pour votre application mobile
Les tests sont censés être répétés, et non ponctuels, et les résultats et correctifs doivent être conservés.
Comment Ostorlab vous aide
Les scans rapides se terminent généralement en 1 à 5 minutes et les scans complets en 15 à 45 minutes : ils s'intègrent donc à chaque version. Un pentest par agents IA va plus loin, généralement en quelques heures, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, pour les changements critiques et vos tests approfondis périodiques.
Ce qui reste de votre ressort
Le choix de l'évaluateur indépendant et la rédaction de la méthodologie.
- Guideline on ICT Security v4.0, 10.8.3, 10.8.4 et 10.8.12
Sécuriser et tester les API avant la production
Ce que dit le texte
Fixez des normes de sécurité pour la conception et le développement des API, y compris la protection des clés d'API et des jetons d'accès et une expiration des jetons raisonnable et effectivement appliquée. Mettez en œuvre une authentification forte et un contrôle d'accès pour les services d'API, et réalisez un contrôle et des tests de sécurité de l'API entre l'organisation et ses tiers avant son déploiement en production.
Source :Guideline on ICT Security v4.0, 10.8.3, 10.8.4 et 10.8.12
Ce que cela implique pour votre application mobile
Les API derrière l'application véhiculent les mêmes fonds et les mêmes données que l'application. Elles doivent être testées avant la mise en production et après chaque changement.
Comment Ostorlab vous aide
Les tests authentifiés suivent l'application jusque dans ses API pour tester les autorisations, les sessions et l'application effective de la MFA, avec les journaux des requêtes et réponses et les étapes de reproduction pour chaque résultat.
Ce qui reste de votre ressort
L'évaluation des tiers, la surveillance et les alertes sur les API, et la protection contre le déni de service.
Synthèse des textes publics de Bangladesh Bank, vérifiés le 27 septembre 2026. Certaines dispositions emploient « should » ou « may » plutôt que « shall », comme cité. Cette page ne constitue pas un avis juridique.
Les règles de Bangladesh Bank, contrôle par contrôle
Les contrôles visés par les textes de Bangladesh Bank, la manière dont Ostorlab les teste dans votre application et ses API, et les preuves que vous pouvez conserver.
| Contrôle | Comment Ostorlab vous aide | Preuves conservées |
|---|---|---|
| SAST et DAST de l'application mobileICT Guideline 11.4.13 | Mobile SAST sur le binaire et Mobile DAST sur l'application en cours d'exécution, avant la mise en production. Détails | Résultats avec contexte du code décompilé, trafic, traces d'appels et captures d'écran |
| Durcissement et blindage de l'applicationICT Guideline 11.4.14 | Modifie le binaire, injecte des débogueurs et des hooks, et tente de contourner le TLS pinning. Détails | Preuves des protections qui ont tenu et de celles qui ont été contournées |
| Refus des appareils dans un état non sécuriséICT Guideline 11.7.8 | Exécute l'application dans des environnements rootés et jailbreakés et tente de contourner la détection du root et du jailbreak. Détails | Score de durcissement, et preuves de contournement pour chaque protection qui a échoué |
| MFA et expiration des sessionsICT Guideline 11.4.6, 11.4.7, 11.4.11 | Teste la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions. Détails | Résultats sur les sessions et les jetons, avec journaux des requêtes et réponses |
| Authentification des paiements mobilesICT Guideline 11.7.19 | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Détails | Résultats sur les parcours de connexion et d'authentification renforcée, avec étapes de reproduction |
| Jetons d'API, contrôle d'accès et liaison de l'appareilICT Guideline 10.8.3, 10.8.4, 11.7.16 | Intercepte le trafic même avec TLS pinning et teste les autorisations, les usages abusifs des jetons et les abus comme l'énumération et le rejeu. Détails | Requêtes et réponses à l'appui de chaque résultat d'API |
| Données sensibles sur l'appareilICT Guideline 11.7.20 à 11.7.22 | Recherche les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie la protection du transport. Détails | Preuves sur le système de fichiers montrant ce qui a été écrit, où et quand |
| Stockage sécurisé des données sensibles dans l'applicationICT Guideline 11.4.12 | Détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels. Détails | Secrets validés, avec les permissions et les services qu'ils exposent |
| Aucune bibliothèque en fin de vieICT Guideline 6.1.7 | Identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, d'une version à l'autre. Détails | Vulnérabilités identifiées avec recommandations de mise à niveau ou de remplacement, et résolution suivie d'une version à l'autre |
| Tests de pénétration annuels et après les changements importantsICT Guideline 6.2.7 ; CSF 5.1.2.25 | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
Ostorlab teste les contrôles de l'application et de ses API. La détection d'intrusion et les pare-feu applicatifs web, la surveillance de la fraude et des anomalies, la gestion des journaux, les accords de remplacement de carte SIM avec les opérateurs mobiles, l'audit SI externe, la continuité d'activité et le reporting à Bangladesh Bank restent du ressort de vos équipes.
Les contrôles de Bangladesh Bank à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque TIC, fondée sur l'ICT Security Guideline et le Cybersecurity Framework.
SAST et DAST à chaque build
Lancez des tests statiques et dynamiques sur chaque build de l'application avant qu'il n'arrive sur le store, et corrigez ce qu'ils détectent.
Le blindage face aux attaques
Exécutez l'application sur des appareils rootés et jailbreakés, essayez un build modifié et des hooks à l'exécution, et vérifiez que l'application réagit.
MFA et sessions
Vérifiez la MFA sur chaque transaction financière, l'expiration des sessions, la réauthentification et le verrouillage après des saisies erronées du code PIN.
Authentification côté serveur
Confirmez que l'authentification est décidée par votre serveur, et que les tentatives échouées et les sessions inactives y sont limitées.
Liaison de l'appareil au niveau de l'API
Envoyez des requêtes depuis un appareil non enregistré et rejouez des jetons, et vérifiez que le backend les refuse.
Données laissées sur l'appareil
Recherchez les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, y compris après la déconnexion.
Calendrier des tests
Planifiez des tests de pénétration au moins une fois par an et après les mises à niveau importantes, des scans internes au moins une fois par semestre, et le scan indépendant annuel des applications critiques.
Les API avant la mise en production
Testez les autorisations et la gestion des jetons de chaque API avant la production, et vérifiez que les jetons expirent.
Une liste indicative, et non un modèle de Bangladesh Bank. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- Mobile SASTAnalyse statique des binaires APK, AAB et IPA, avec analyse de propagation (taint) sur l'application et ses SDK intégrés.En savoir plus
- Mobile Shielding ScanTestez à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et voyez quelles protections ont tenu et lesquelles ont été contournées.En savoir plus
- Mobile Agentic Deep ScanDes agents IA pentestent la version publiée à chaque release, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.En savoir plus
- Tests authentifiésTestez la connexion, les codes à usage unique et les parcours d'authentification renforcée avec vos comptes de test.En savoir plus
- Tests des API et du backendInterceptez le trafic de l'application même avec TLS pinning, puis testez les API et backends derrière les comptes et les paiements.En savoir plus
- SCA et SBOMDétectez les dépendances vulnérables, y compris les bibliothèques natives compilées statiquement, et suivez leur résolution version après version.En savoir plus
- Votre propre clé IALancez les scans par agents IA avec la clé de votre fournisseur d'IA et un plafond de dépense par scan, pour respecter vos politiques internes.En savoir plus
- Scan on-premisesScannez les applications de préproduction, API et dépôts derrière votre pare-feu ou VPN, sur une infrastructure que vous contrôlez.En savoir plus
Des banques et fintechs nous font confiance, dont
Sources
Les textes officiels sur lesquels s'appuie cette page, vérifiés le 27 septembre 2026.
- Guideline on ICT Security, Version 4.0, 2023Bangladesh Bank. S'applique aux banques, NBFI, fournisseurs de MFS, PSP, PSO et autres prestataires de services financiers régulés. Chapitres 6 (VAPT), 10 (développement, tests et API) et 11 (banque en ligne et sur application, services financiers mobiles)
- BRPD Circular No. 10: Guideline on ICT SecurityBangladesh Bank, 19 juin 2023. Enjoint à toutes les banques agréées (scheduled banks) de suivre la version 4.0, avec effet immédiat. Publiée en bangla uniquement
- DFIM Circular No. 08: Guideline on ICT Security, Version 4.0Bangladesh Bank, 13 juillet 2023. Donne la même instruction aux institutions financières, avec effet immédiat. Publiée en bangla uniquement
- Cybersecurity Framework, Version 1.0 (2026)Bangladesh Bank. Fondé sur les fonctions du NIST Cybersecurity Framework. S'applique aux banques, institutions financières, fournisseurs de MFS, PSP, PSO et autres prestataires de services financiers ou de paiement
- BRPD-2 Circular No. 02: Cybersecurity Framework, Version 1.0 (2026)Bangladesh Bank, 29 mars 2026. Publie le cadre et impose la mise en conformité au plus tard le 31 décembre 2026. Publiée en bangla uniquement
- Guidelines on Cloud ComputingBangladesh Bank, publiées par la circulaire BRPD n° 05 du 16 mars 2023. Tests de sécurité avant le déploiement des applications (4.5.4.3) et VAPT des services cloud (6.4)
- Bangladesh Mobile Financial Services (MFS) Regulations, 2022Bangladesh Bank. La section 12 impose que toutes les transactions MFS soient authentifiées par un code PIN ou un mécanisme sécurisé similaire, et encourage un second facteur d'authentification
Questions fréquentes
Des réponses claires sur la couverture, la mise en place et la façon dont les résultats parviennent à vos équipes.
Vous ne trouvez pas votre réponse ? Réservez une démo ou contactez-nous.
Testez votre application bancaire mobile au regard des contrôles de Bangladesh Bank
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests de blindage et des tests authentifiés avec notre équipe.