Les règles de la SAMA pour l'application bancaire mobile de vos clients.
La Banque centrale saoudienne demande aux banques une revue et un test d'intrusion annuels des services destinés aux clients et exposés à Internet, des tests de sécurité pour chaque changement, l'authentification multifacteur sur chaque service de banque électronique et des applications mobiles qui détectent les appareils rootés et jailbreakés. Ostorlab vous aide à tester ces contrôles dans votre application et ses API, à chaque version.
- Tests d'intrusion par agents IA derrière la connexion, avec un exploit à rejouer pour chaque résultat d'un agent IA
- Tests statiques et dynamiques de la version que vous livrez, sans besoin du code source
- Parcours MFA, de verrouillage et d'authentification renforcée testés avec vos comptes de test
- Détection du root et du jailbreak testée dans des environnements rootés et jailbreakés
- Qui est concerné
- Les banques opérant en Arabie saoudite et les autres institutions financières régulées par la SAMA
- Dates clés
- Cadre de cybersécurité publié le 24 mai 2017, conformité totale exigée d'ici fin octobre 2018
- Objet
- Tests d'intrusion annuels des services exposés à Internet, MFA et contrôles antifraude dans les canaux numériques
- Référence
- SAMA Cyber Security Framework, Counter-Fraud Framework, IT Governance Framework, FEER
Les règles cyber et antifraude de la SAMA, date par date
Les cadres de la SAMA sont en vigueur aujourd'hui. Voici les dates et les fréquences au regard desquelles les tests de votre application sont évalués.
- 24 mai 2017
Cadre de cybersécurité
La SAMA publie le cadre. Tous les domaines s'appliquent aux banques, y compris la sécurité des applications et les services de banque électronique.
- Fin octobre 2018
Conformité totale des banques
L'échéance fixée par la SAMA pour que les banques se conforment pleinement au cadre de cybersécurité.
- 13 mai 2019
Cadre de red teaming FEER
Un red teaming fondé sur le renseignement sur les menaces, mené sur les environnements de production en direct, au moins une fois tous les trois ans.
- 4 novembre 2021
Cadre de gouvernance IT
Des règles sur le développement des systèmes, la revue de code sécurisée et le test de chaque changement avant la mise en production.
- 11 octobre 2022
Cadre de lutte antifraude
Une authentification fondée sur les risques, des normes de prévention de la fraude et des contrôles des applications mobiles comme la détection du root et du jailbreak.
- Chaque année
Revue et test d'intrusion
Les services destinés aux clients et exposés à Internet font l'objet d'une revue et d'un test d'intrusion annuels, avec un suivi jusqu'à ce que les problèmes soient traités.
Les règles cyber et antifraude de la SAMA, appliquées à votre application mobile
Les cadres de la SAMA fixent des principes et des considérations de contrôle pour les banques. 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.
- SAMA Cyber Security Framework, 3.2.4
Tester chaque année les services destinés aux clients et exposés à Internet
Ce que dit le texte
L'état de cybersécurité des actifs informationnels doit être revu périodiquement. Les services destinés aux clients et exposés à Internet devraient faire l'objet d'une revue et de tests d'intrusion annuels. Les résultats, problèmes et actions recommandées sont consignés, communiqués au responsable métier et suivis jusqu'à ce que tous les problèmes identifiés soient traités.
Ce que cela implique pour votre application mobile
Une application bancaire mobile et les API qu'elle appelle sont des services destinés aux clients et exposés à Internet. Elles nécessitent au moins une revue et un test d'intrusion annuels, ainsi qu'une trace montrant que chaque problème trouvé a été clos.
Comment Ostorlab vous aide
Un pentest par agents IA teste l'application et ses API derrière la connexion, généralement en quelques heures, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA. Les résultats sont suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif livré.
Ce qui reste de votre ressort
La revue annuelle elle-même, le choix des testeurs et le rapport au responsable métier.
- SAMA Cyber Security Framework, 3.3.7 ; IT Governance Framework, 3.4.4 et 3.4.5
Tester la sécurité de chaque changement avant sa mise en production
Ce que dit le texte
La gestion des changements doit inclure des tests de sécurité qui, le cas échéant, couvrent les tests d'intrusion et la revue de code, ou un rapport de revue de code ou un équivalent, comme une déclaration d'assurance indépendante, lorsque le code source ne peut pas être fourni. Le cadre de gouvernance IT ajoute que tous les changements sont testés dans un environnement de test distinct, les tests de sécurité figurant parmi les types de tests minimaux.
Source :SAMA Cyber Security Framework, 3.3.7 ; IT Governance Framework, 3.4.4 et 3.4.5
Ce que cela implique pour votre application mobile
Chaque nouvelle version de l'application est un changement. Elle devrait passer des tests de sécurité avant d'arriver sur le store, y compris pour le code tiers dont vous n'avez pas les sources.
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
L'approbation du Change Advisory Board, les tests de recette utilisateur et la décision de ce qui vaut déclaration d'assurance équivalente.
- SAMA Cyber Security Framework, 3.3.6
Définir et tester une norme de sécurité des applications
Ce que dit le texte
Définir, approuver et mettre en œuvre des normes de cybersécurité pour les applications, surveiller leur respect et évaluer périodiquement leur efficacité. Le développement suit un SDLC sécurisé approuvé, et la norme couvre le codage sécurisé, la gestion des identités et des accès, la protection des données clients contre l'accès non autorisé et les fuites, ainsi que la gestion des vulnérabilités et des correctifs.
Ce que cela implique pour votre application mobile
Vos règles de codage sécurisé et de protection des données pour l'application doivent être étayées par des preuves qu'elles tiennent dans la version que vous livrez, et pas seulement dans une politique.
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 clés d'API, jetons et identifiants dans le package de l'application, et recense les SDK et bibliothèques natives de chaque version avec leurs versions.
Ce qui reste de votre ressort
La rédaction de la norme, la méthodologie SDLC et la séparation des tâches.
- SAMA Cyber Security Framework, 3.3.17 ; circulaire n° 381000091275
Gérer les vulnérabilités selon une fréquence définie
Ce que dit le texte
Définir et mettre en œuvre un processus de gestion des vulnérabilités applicatives et d'infrastructure. Il couvre tous les actifs informationnels, une fréquence de scan fondée sur les risques, la classification des vulnérabilités, des délais de remédiation définis par classification et la gestion des correctifs. Une circulaire ultérieure de la SAMA a demandé aux banques une feuille de route pour atteindre le niveau de maturité 4 en gestion des vulnérabilités d'ici la fin du troisième trimestre 2022.
Source :SAMA Cyber Security Framework, 3.3.17 ; circulaire n° 381000091275
Ce que cela implique pour votre application mobile
Les résultats dans l'application et ses bibliothèques nécessitent une classification, une échéance et une preuve de clôture, selon une fréquence que vous pouvez justifier.
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 sont classés critiques, élevés, moyens ou faibles, et retestés une fois le correctif livré. La SCA identifie par empreinte les bibliothèques compilées statiquement que les scanners fondés sur les manifestes peuvent manquer.
Ce qui reste de votre ressort
La fixation des délais de remédiation et le scan du reste de votre parc.
- SAMA Cyber Security Framework, 3.3.13
Durcir les canaux de banque en ligne et mobile
Ce que dit le texte
La norme de sécurité des services de banque électronique couvre, pour la banque en ligne et mobile, l'utilisation des stores d'applications et sites web officiels, la détection et le retrait des applications et sites web malveillants, le sandboxing, les techniques de non-mise en cache et les techniques de communication visant à éviter les attaques de l'homme du milieu. L'approbation de la SAMA est nécessaire avant le lancement d'un nouveau service de banque électronique.
Ce que cela implique pour votre application mobile
L'application ne devrait pas laisser de données sensibles dans les caches, et son trafic devrait résister à l'interception, même sur un appareil contrôlé par l'attaquant.
Comment Ostorlab vous aide
Ostorlab vérifie ce que l'application écrit dans le stockage, les caches, les journaux et les captures d'écran, et détecte les erreurs de configuration qui affaiblissent la protection du transport et des sessions. Mobile Shielding Scan tente de contourner le TLS pinning et montre quelles protections ont tenu.
Ce qui reste de votre ressort
La protection de la marque, le retrait des applications et sites web malveillants, et l'approbation de la SAMA pour les nouveaux services.
- SAMA Cyber Security Framework, 3.3.13
Authentification multifacteur sur chaque service de banque électronique
Ce que dit le texte
Utiliser l'authentification multifacteur lors de l'enregistrement du client et pour tous les services de banque électronique, y compris la connexion, l'ajout ou la modification de bénéficiaires, l'ajout de services de paiement de factures et de paiements aux administrations, les transactions à haut risque au-delà de plafonds prédéfinis et la réinitialisation du mot de passe. Révoquer l'accès du client après 3 mots de passe incorrects ou codes PIN invalides successifs.
Ce que cela implique pour votre application mobile
Chacun de ces parcours doit exiger le second facteur côté serveur, et le verrouillage après 3 tentatives échouées doit tenir quoi que l'application envoie.
Comment Ostorlab vous aide
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 et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et l'application effective de la MFA, y compris les parcours d'authentification renforcée.
Ce qui reste de votre ressort
Les règles propres aux canaux, comme la modification du numéro de mobile uniquement en agence ou au distributeur, et les notifications par SMS.
- SAMA Counter-Fraud Framework, 4.4
Authentifier selon le risque, pas uniquement par SMS
Ce que dit le texte
La norme d'authentification couvre les canaux numériques comme les services en ligne et les applications mobiles. L'authentification multifacteur ne devrait pas reposer uniquement sur des OTP envoyés par SMS. Les activités à haut risque, comme l'enregistrement, l'activation d'un jeton sur un nouvel appareil, la connexion depuis un appareil inconnu et l'ajout de bénéficiaires, nécessitent une authentification multifacteur, et les sessions anormales nécessitent un troisième facteur.
Ce que cela implique pour votre application mobile
L'association de l'appareil, la validation par notification push dans l'application et l'authentification renforcée sur les sessions anormales sont des contrôles que les fraudeurs tentent de contourner en rejouant ou en modifiant les appels d'API.
Comment Ostorlab vous aide
Les tests authentifiés couvrent l'application effective de la MFA et les parcours d'authentification renforcée, y compris la manière dont les attaquants tentent de les manipuler, ainsi que les appels d'API derrière les modifications de compte.
Ce qui reste de votre ressort
La norme d'authentification, le moteur de risque qui signale les sessions anormales et la définition des transactions de faible montant.
- SAMA Counter-Fraud Framework, 4.6.2
Détecter les appareils rootés et limiter les abus
Ce que dit le texte
Les normes de prévention de la fraude incluent la capacité des applications mobiles à détecter leur utilisation sur des appareils jailbreakés ou rootés, puis à bloquer l'application ou à restreindre l'accès aux données ou fonctionnalités sensibles, l'enregistrement des appareils, une restriction des connexions simultanées ou du nombre d'appareils et, selon une approche fondée sur les risques, des mécanismes de prévention des robots avant l'ordre de paiement.
Ce que cela implique pour votre application mobile
La détection du root et du jailbreak doit réagir, pas seulement détecter, et le backend doit bloquer les usages automatisés et simultanés que l'application seule ne peut pas empêcher.
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. Les tests d'API couvrent les abus comme l'énumération, le rejeu et l'automatisation.
Ce qui reste de votre ressort
Le choix de votre produit de blindage, les plafonds de transaction, les listes noires et la surveillance de la fraude.
- SAMA Financial Entities Ethical Red-Teaming Framework, 1.3 et 1.6
Un red teaming au moins une fois tous les 3 ans
Ce que dit le texte
Chaque organisation membre régulée par la SAMA devrait être testée, au minimum une fois tous les trois ans, par un test de red teaming fondé sur le renseignement sur les menaces, mené sur son environnement de production en direct dans le cadre FEER. La SAMA peut aussi désigner une organisation pour un test. Le red teaming n'est pas un test d'intrusion : il reproduit une attaque ciblée contre l'ensemble de l'organisation.
Source :SAMA Financial Entities Ethical Red-Teaming Framework, 1.3 et 1.6
Ce que cela implique pour votre application mobile
L'application mobile et ses API sont des points d'entrée probables pour une red team. Les faiblesses que des tests courants auraient pu trouver consomment du temps de red team.
Comment Ostorlab vous aide
Ostorlab ne réalise pas de tests de red teaming et ne les remplace pas. Il vous aide à aborder un test avec les problèmes connus de l'application et des API déjà corrigés, et à retester ensuite les résultats portant sur l'application et les API.
Ce qui reste de votre ressort
L'exercice de red teaming, les prestataires et le dialogue avec la SAMA.
Synthèse des textes de la SAMA publiés dans le SAMA Rulebook, vérifiés le 27 septembre 2026. Certains cadres s'appliquent à des secteurs spécifiques, comme indiqué. Cette page ne constitue pas un avis juridique.
Les règles de la SAMA, contrôle par contrôle
Les contrôles visés par les textes de la SAMA, 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 |
|---|---|---|
| Revue et test d'intrusion annuels des services exposés à InternetCSF 3.2.4 | 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 |
| Tests de sécurité de chaque changement avant la mise en productionCSF 3.3.7; ITGF 3.4.5 | 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 |
| Tests du code tiers sans les sourcesCSF 3.3.7; ITGF 3.4.4 | Analyse de propagation (taint) à travers les SDK intégrés, et analyse des dépendances de l'application compilée. Détails | Résultats attribués au SDK ou à la bibliothèque dont ils proviennent |
| Classification des vulnérabilités, délais et suiviCSF 3.2.4, 3.3.17 | Regroupe les résultats en tickets dans la plateforme ou dans Jira et ServiceNow, et reteste après correction. Détails | Historique des tickets et issue du retest pour chaque résultat |
| Non-mise en cache et protection des données clients sur l'appareilCSF 3.3.6, 3.3.13 | 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 |
| Protection contre les attaques de l'homme du milieuCSF 3.3.13 | Tente de contourner le TLS pinning à l'exécution et vérifie la protection du transport. Détails | Preuves des protections qui ont tenu et de celles qui ont été contournées |
| MFA à la connexion, pour les bénéficiaires, la réinitialisation du mot de passe et les transactions à haut risqueCSF 3.3.13; CFF 4.4 | 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 |
| Verrouillage après 3 tentatives échouées, et gestion des sessionsCSF 3.3.13 | 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 |
| Détection du root et du jailbreak qui bloque ou restreint l'applicationCFF 4.6.2 | 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é |
| Abus des API de paiement par robots, rejeu et usage simultanéCFF 4.6.2 | 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 |
Ostorlab teste les contrôles dans l'application et ses API. La gouvernance, la sensibilisation, la surveillance des événements et le SOC, la gestion des incidents, la continuité d'activité, la surveillance de la fraude, la protection de la marque et le reporting à la SAMA restent du ressort de vos équipes.
Les contrôles SAMA à tester dans votre application avant votre prochaine revue
Une liste pratique pour les équipes sécurité, antifraude et conformité qui travaillent avec les cadres de la SAMA.
Pentest annuel planifié
Planifiez la revue et le test d'intrusion annuels de l'application et de ses API, et ajoutez des scans à chaque version dans l'intervalle.
Contrôle de sécurité dans le pipeline de livraison
Lancez des tests statiques et dynamiques sur chaque build avant son passage devant le Change Advisory Board et sa publication sur le store.
Code tiers couvert
Recensez les SDK et bibliothèques de chaque version et décidez comment obtenir une assurance sur le code dont vous n'avez pas les sources.
MFA sur chaque parcours listé
Vérifiez que la connexion, les bénéficiaires, les services de paiement, les transactions à haut risque et la réinitialisation du mot de passe exigent tous un second facteur, imposé par le serveur.
Verrouillage et sessions
Vérifiez que l'accès est révoqué après 3 tentatives échouées, et testez l'expiration des sessions, le renouvellement des jetons et la déconnexion.
Appareils rootés et jailbreakés
Exécutez l'application sur des appareils compromis et confirmez qu'elle bloque ou restreint les fonctionnalités sensibles, comme l'attend le cadre de lutte antifraude.
Données laissées sur l'appareil
Recherchez les jetons et les données personnelles dans les caches, les journaux et les captures d'écran, ainsi que les identifiants codés en dur dans l'application.
Résultats suivis jusqu'à leur clôture
Classez chaque résultat, fixez une échéance, retestez après correction et conservez la trace pour les inspections de la SAMA et l'audit interne.
Une liste indicative, et non un modèle de la SAMA. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- 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
- 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
- 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
- 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
- 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
- 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
- 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
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.
- SAMA Rulebook: Cyber Security FrameworkBanque centrale saoudienne, circulaire n° 381000091275, 24 mai 2017. S'applique aux banques, assureurs, sociétés de financement et bureaux de crédit. Couvre la sécurité des applications, la gestion des changements, les services de banque électronique et la gestion des vulnérabilités
- SAMA Rulebook: Circular Re. Cyber Security FrameworkBanque centrale saoudienne, circulaire n° 381000091275. Fixe la conformité totale à fin octobre 2018 et des feuilles de route vers le niveau de maturité 4 pour la gestion des événements, des incidents, des menaces et des vulnérabilités. Traduction anglaise, le texte arabe fait foi
- SAMA Rulebook: Counter-Fraud FrameworkBanque centrale saoudienne, circulaire n° 44021528, 11 octobre 2022, secteur bancaire. Couvre l'authentification, les normes de prévention de la fraude et les contrôles des applications mobiles. La SAMA notifie les organisations tenues de le mettre en œuvre
- SAMA Rulebook: Information Technology Governance FrameworkBanque centrale saoudienne, circulaire n° 43028139, 4 novembre 2021, secteur bancaire et bureaux de crédit. Couvre le développement des systèmes, la revue de code sécurisée et le test des changements
- SAMA Rulebook: Financial Entities Ethical Red-TeamingBanque centrale saoudienne, circulaire n° 562240000067, 13 mai 2019. Red teaming fondé sur le renseignement sur les menaces, au moins une fois tous les trois ans
- SAMA Rulebook: Cyber Resilience Fundamental Requirements (CRFR)Banque centrale saoudienne, 1er janvier 2022. S'applique aux sociétés de financement, prestataires de services de paiement, bureaux de change et entités de la sandbox, pas aux banques. Tests d'intrusion deux fois par an et blindage des applications
- SAMA Rulebook: Rules on Outsourcing, Section VBanque centrale saoudienne, circulaire n° 41027017, 15 décembre 2019, secteur bancaire. Une non-objection écrite de la SAMA est nécessaire pour externaliser auprès de prestataires situés à l'étranger
- SAMA Open Banking FrameworkBanque centrale saoudienne. Règles métier et normes techniques, y compris les spécifications d'API, disponibles sur demande auprès de l'équipe Open Banking de la SAMA, et donc non citées sur cette page
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 la SAMA
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer avec notre équipe des tests authentifiés et de blindage.