Risque informatique BSP et règles AFASA : évaluez votre application bancaire mobile à chaque version.
La circulaire BSP 982 demande aux institutions financières supervisées de tester les applications par des tests d'intrusion, des évaluations de vulnérabilité et des tests de sécurité applicative avant leur mise en production, et de confier à une partie externe des évaluations de vulnérabilité et des tests d'intrusion au moins une fois par an pour les services financiers numériques et électroniques. La circulaire 1213, qui met en œuvre l'Anti-Financial Account Scamming Act, restreint les applications sur les appareils rootés, jailbreakés ou émulés, limite les codes PIN à usage unique envoyés par SMS et e-mail et impose une pause de 24 heures après les modifications clés d'un compte. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Teste l'application et les API qu'elle appelle sur le build que téléchargent vos clients
- Se connecte avec vos comptes de test, y compris les codes à usage unique et les parcours d'authentification renforcée
- Tente de contourner la détection du root, du jailbreak, des émulateurs et de l'altération, et montre ce qui a tenu
- Prouve chaque résultat par un exploit rejouable ou par les requêtes et réponses à l'appui
- Qui est concerné
- Les banques et les autres institutions financières supervisées par la BSP, y compris les institutions financières non bancaires et les opérateurs de systèmes de paiement
- Date clé
- Circulaire 1213 en vigueur depuis le 25 juin 2025, ses normes devant être en place sous un an ; la circulaire 982 est en vigueur depuis décembre 2017
- Objet
- Tests de sécurité applicative, évaluation de vulnérabilité et tests d'intrusion externes annuels, authentification et contrôles anti-fraude dans les canaux mobiles
- Texte de référence
- Circulaire BSP 982, Enhanced Guidelines on Information Security Management, appendice 75b du MORB
Les textes de la BSP qui encadrent votre canal mobile
Les lignes directrices sur la sécurité de l'information complètent le cadre de gestion du risque informatique et les règles AFASA. Les dates ci-dessous concernent les textes cités sur cette page.
- 22 août 2013
Circulaire 808, risque informatique
La circulaire BSP 808 fixe les lignes directrices sur la gestion du risque lié aux technologies de l'information pour toutes les banques et autres institutions supervisées par la BSP, le cadre que les circulaires suivantes ont modifié.
- 5 décembre 2017
Circulaire 982, sécurité de l'information
Les Enhanced Guidelines on Information Security Management entrent en vigueur. Elles demandent notamment des pratiques de développement sécurisé, des tests de sécurité applicative avant la mise en production, et des évaluations de vulnérabilité et tests d'intrusion par une partie externe au moins une fois par an pour les services financiers numériques et électroniques.
- 24 mars 2022
Circulaire 1140, gestion de la fraude
Des amendements ajoutent des systèmes automatisés de surveillance et de détection de la fraude en temps réel et un programme renforcé de sensibilisation des consommateurs, face à la hausse de la fraude électronique.
- 20 juillet 2024
Signature de l'AFASA
La Republic Act No. 12010, l'Anti-Financial Account Scamming Act, est signée. Son article 6 exige que les institutions protègent l'accès aux comptes financiers de leurs clients par des systèmes et contrôles de gestion des risques adéquats, comme l'authentification multifacteur, les systèmes de gestion de la fraude et les processus de vérification des comptes.
- 25 juin 2025
Circulaire 1213, règles AFASA
Les amendements aux règles de gestion du risque informatique entrent en vigueur : pause de 24 heures après les modifications clés d'un compte, restrictions sur les appareils rootés, jailbreakés et émulés, limites sur les codes PIN à usage unique par SMS et e-mail, empreinte d'appareil et interdiction des liens cliquables et des codes QR dans les messages des banques.
- 27 avril 2026
Cybersecurity Maturity Framework
La circulaire 1232 remplace l'IT Rating System par le Supervisory Assessment Framework et introduit le Cybersecurity Maturity Framework et l'auto-évaluation CCSA, avec des rapports annuels et des niveaux de maturité liés au profil informatique de chaque institution.
- Juin 2026
Échéance des normes AFASA
Les normes de la circulaire 1213 devaient être en place dans l'année suivant son entrée en vigueur, une échéance rapportée au 30 juin 2026. Les règles incluent la limitation des codes PIN à usage unique interceptables et le passage des transactions à haut risque à une authentification forte.
Les règles de la BSP, 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. Les citations proviennent des circulaires publiées par la Bangko Sentral ng Pilipinas.
- Circulaire BSP 982, appendice 75b, 3.3.3.4 Application Security
Tester les applications avant leur mise en production
Ce que dit le texte
La direction devrait s'assurer que toutes les applications, développées en interne ou acquises sur étagère, disposent de contrôles adaptés à leur sensibilité et à leur criticité. Les pratiques de développement sécurisé, qui intègrent les exigences de sécurité dès la phase de développement, devraient figurer dans les politiques et procédures de développement et d'acquisition de systèmes applicatifs de l'institution. Les nouvelles applications, y compris les améliorations ultérieures, devraient être suffisamment testées au moyen de diverses méthodologies (par exemple tests d'intrusion, évaluations de vulnérabilité et tests de sécurité applicative) avant leur chargement en production. Les revues de systèmes applicatifs, les tests d'intrusion et les évaluations de vulnérabilité devraient être menés périodiquement.
Source :Circulaire BSP 982, appendice 75b, 3.3.3.4 Application Security
Ce que cela implique pour votre application mobile
Chaque version d'une application bancaire mobile est une nouvelle version logicielle qui part en production. L'application, et le backend auquel elle parle, font partie du processus de version, pas seulement d'un exercice annuel.
Comment Ostorlab vous aide
Un pentest par agents IA teste la version publiée sur le store et les API qui la sous-tendent, derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA. Mobile SAST et Mobile DAST s'exécutent depuis votre pipeline CI/CD à chaque build, sur l'APK, l'AAB ou l'IPA, sans besoin du code source.
Ce qui reste de votre ressort
Les normes de développement sécurisé, l'approbation des changements, la décision de mise en production et la supervision des applications développées par des prestataires.
- Circulaire BSP 982, appendice 75b, 3.7.1 et 3.7.2 (c) à (g)
Réaliser au moins une fois par an une évaluation de vulnérabilité et des tests d'intrusion, par une partie externe
Ce que dit le texte
L'évaluation de vulnérabilité identifie les vulnérabilités de sécurité des systèmes et des réseaux, généralement au moyen de scanners automatisés, à une fréquence déterminée par le risque et la criticité du système, et les vulnérabilités à haut risque découvertes devraient être corrigées dans un délai raisonnable. Les tests d'intrusion soumettent un système ou un réseau à des attaques simulées ou réelles exploitant des vulnérabilités dans des conditions contrôlées. Pour les BSFI fournissant des services financiers numériques ou électroniques, l'évaluation de vulnérabilité et les tests d'intrusion devraient être réalisés par une partie externe au moins une fois par an. Les tests devraient aussi couvrir des scénarios extrêmes mais plausibles, et les lignes directrices classent les évaluations de compromission et les exercices de red teaming parmi les types de tests.
Source :Circulaire BSP 982, appendice 75b, 3.7.1 et 3.7.2 (c) à (g)
Ce que cela implique pour votre application mobile
Votre application mobile fait partie d'un service financier numérique. Prévoyez au moins une évaluation de vulnérabilité et des tests d'intrusion externes par an, et continuez à tester entre ces cycles, car l'application change à chaque version.
Comment Ostorlab vous aide
Ostorlab est une partie externe qui peut tester l'application et ses API à chaque version, entre vos tests annuels. Les résultats sont classés critiques, élevés, moyens ou faibles, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif publié.
Ce qui reste de votre ressort
Le choix et la contractualisation de la partie externe, les modalités de test en production et la décision sur le périmètre et la fréquence.
- Circulaire BSP 982, appendice 75b, 3.3.3.8.3 Patch Management et 3.7.2(c)
Tenir à jour la gestion des correctifs et les délais de remédiation
Ce que dit le texte
La direction devrait adopter un processus de gestion des correctifs pour identifier rapidement les correctifs de sécurité disponibles pour les actifs technologiques et logiciels, évaluer leur criticité et leur risque, et les tester et les déployer dans un délai approprié. Les vulnérabilités à haut risque découvertes lors des évaluations de vulnérabilité devraient être corrigées dans un délai raisonnable.
Source :Circulaire BSP 982, appendice 75b, 3.3.3.8.3 Patch Management et 3.7.2(c)
Ce que cela implique pour votre application mobile
Les bibliothèques et SDK intégrés à votre application sont des actifs logiciels. Chacun doit avoir une version connue, une évaluation lorsqu'une vulnérabilité apparaît, et un correctif dans un délai raisonnable et documenté.
Comment Ostorlab vous aide
SCA identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, version après version. Chaque résultat porte une gravité et peut être suivi comme un ticket, ce qui rend la résolution visible d'une version à l'autre.
Ce qui reste de votre ressort
Le déploiement des correctifs sur vos systèmes et votre infrastructure, les fenêtres de maintenance et les décisions d'acceptation des risques.
- Circulaire BSP 982, appendice 75b, 3.3.3.8.4 Vendor Management and Outsourcing ; circulaire BSP 1213, article 1 (section 148 du MORB), cadre de responsabilité partagée (c)
Gérer les fournisseurs et les tiers
Ce que dit le texte
La direction devrait mener une diligence raisonnable appropriée et prendre en compte la sécurité de l'information dans la sélection des prestataires tiers, mettre en place des processus de supervision efficaces pour suivre leurs activités, et détailler suffisamment les exigences de sécurité de l'information dans les contrats, en particulier pour les prestataires qui stockent, transmettent, traitent ou éliminent des informations clients. Les expositions au cyber-risque liées aux tiers devraient être évaluées et utilisées pour ajuster le programme de gestion du cyber-risque de l'institution. La circulaire 1213 demande également aux BSFI de faire respecter et d'évaluer régulièrement le respect par les entités et prestataires tiers impliqués dans les transactions financières de leurs obligations contractuelles de disponibilité, de sécurité de l'information et de cybersécurité.
Ce que cela implique pour votre application mobile
Une application bancaire mobile embarque des SDK tiers qui communiquent avec leurs propres backends, et les API qui la sous-tendent peuvent être exploitées par des prestataires. Ils ont leur place dans votre vision du risque lié aux tiers.
Comment Ostorlab vous aide
Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle de l'application, et montre avec quels backends l'application et ses SDK échangent des données, pour que vous voyiez ce que chaque tiers apporte au build.
Ce qui reste de votre ressort
La diligence raisonnable, les contrats, le suivi des fournisseurs et les plans de sortie.
- Circulaire BSP 982, appendice 75b, 3.3.3.5 Data Security, y compris 3.3.3.5.1 et 3.3.3.5.2
Protéger les données sur l'appareil et en transit
Ce que dit le texte
La BSFI devrait disposer d'une stratégie de classification de l'information et mettre en place des contrôles de protection conformément à cette classification, en protégeant l'information tout au long de son cycle de vie, de la manipulation au stockage ou données au repos, à la transmission ou données en transit, jusqu'à l'élimination. Les contrôles sur les informations stockées sur des appareils portables comme les ordinateurs portables, les smartphones et les tablettes devraient tenir compte de leur vulnérabilité à la perte ou au vol, et inclure des mesures telles que le chiffrement des données, les contrôles d'accès fournis par l'hôte et l'effacement à distance. Les politiques, normes et procédures devraient sécuriser les données en transit et lors de leur partage avec des tiers.
Source :Circulaire BSP 982, appendice 75b, 3.3.3.5 Data Security, y compris 3.3.3.5.1 et 3.3.3.5.2
Ce que cela implique pour votre application mobile
Le téléphone est l'appareil portable. Les mots de passe, jetons et données personnelles ne devraient pas y rester en clair, dans les caches, les journaux ou les captures d'écran, ni transiter sans protection vers le backend.
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, vérifie ce que l'application écrit sur le disque et teste si les protections du transport, comme le TLS pinning, peuvent être contournées.
Ce qui reste de votre ressort
La classification des données, la gestion des clés, l'effacement à distance et la gestion des appareils.
- Circulaire BSP 1213, article 1 (section 148 du MORB), paragraphe (e)(ii)
Restreindre l'application sur les appareils rootés, jailbreakés et émulés
Ce que dit le texte
Les comptes financiers doivent être protégés par des mesures de sécurité pour atténuer des risques tels que les cyberattaques, les accès non autorisés et les transactions frauduleuses. Ces mesures incluent une restriction sur l'installation d'applications mobiles sur des appareils non sécurisés, comme ceux dont le système est obsolète, les appareils rootés ou jailbreakés, ou les émulateurs.
Source :Circulaire BSP 1213, article 1 (section 148 du MORB), paragraphe (e)(ii)
Ce que cela implique pour votre application mobile
La détection seule ne suffit pas. L'application doit arrêter la session, l'enrôlement ou la transaction lorsque l'appareil est compromis, et le contrôle ne doit pas être facile à désactiver.
Comment Ostorlab vous aide
Mobile Shielding Scan exécute l'application dans des environnements rootés, jailbreakés et émulés, tente de contourner la détection 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
La politique pour les appareils compromis ou obsolètes, le choix de la technologie de détection ou de protection, et l'assistance aux clients bloqués.
- Circulaire BSP 1213, article 1 (section 148 du MORB), paragraphes (e)(vi) et (k)
Limiter les codes PIN à usage unique interceptables et supprimer les liens dans les messages
Ce que dit le texte
Les BSFI devraient limiter l'usage des mécanismes d'authentification qui peuvent être partagés avec, ou interceptés par, des tiers non liés à la transaction, comme les codes PIN à usage unique envoyés par SMS et e-mail. Les institutions engagées dans des produits et services électroniques complexes et traitant des volumes élevés de transactions en ligne doivent adopter des mécanismes d'authentification forte, comme l'authentification biométrique, la biométrie comportementale, l'authentification sans mot de passe, notamment FIDO, ou l'authentification adaptative. Les lignes directrices sur l'adoption de l'authentification multifacteur figurent à l'appendice 79. En outre, les BSFI ne doivent pas envoyer de liens cliquables ou de codes QR par e-mail, messagerie instantanée ou SMS, sauf si le message fait suite à une action préalable du client, ne fournit que des informations et ne redirige pas vers un site ou une application web demandant des informations sensibles ou des identifiants de connexion.
Source :Circulaire BSP 1213, article 1 (section 148 du MORB), paragraphes (e)(vi) et (k)
Ce que cela implique pour votre application mobile
Les codes par SMS et e-mail sont le maillon faible de la prise de contrôle de compte, et un lien dans un message bancaire ressemble à un message de phishing. La connexion et les transactions à haut risque devraient passer à des méthodes liées à l'application ou résistantes au phishing, et les messages ne devraient pas contenir de liens.
Comment Ostorlab vous aide
Les tests authentifiés se connectent avec vos comptes de test, saisissent les codes à usage unique reçus par SMS, e-mail ou TOTP, et testent l'application effective de la MFA et les parcours d'authentification renforcée sur les opérations clés, y compris la possibilité de rejouer, réutiliser ou contourner les codes, ainsi que les appels d'API qui les sous-tendent.
Ce qui reste de votre ressort
Le choix des méthodes d'authentification de remplacement, le plan de migration et la communication aux clients.
- Circulaire BSP 1213, article 1 (section 148 du MORB), paragraphe (e)(i)
Appliquer la pause de 24 heures après les modifications clés d'un compte
Ce que dit le texte
Les BSFI doivent mettre en place une période de pause des transactions de 24 heures après l'application de modifications clés d'un compte, pendant laquelle les clients sont limités dans l'exécution de transactions financières. Les modifications clés concernent les informations jugées essentielles pour sécuriser l'accès aux comptes d'un client, y compris la mise à jour du numéro de mobile, de l'adresse e-mail et de l'appareil enregistré ou authentifié utilisé pour accéder au compte. Une BSFI peut raccourcir la pause ou appliquer des restrictions ou limites de transaction à la place, à condition que des mécanismes d'authentification forte soient en place et que l'institution soit pleinement responsable des risques associés.
Source :Circulaire BSP 1213, article 1 (section 148 du MORB), paragraphe (e)(i)
Ce que cela implique pour votre application mobile
La pause est de la logique métier. Si l'application ou ses API permettent à un client, ou à un attaquant disposant d'une session, de la contourner, le contrôle a échoué. L'enregistrement d'un appareil devrait aussi être testé contre l'usurpation.
Comment Ostorlab vous aide
Le pentest par agents IA teste les parcours de modification de compte et d'enregistrement d'appareil, et les tests d'API vérifient que la pause, les limites et les contrôles d'authentification renforcée tiennent côté serveur, avec les requêtes et réponses à l'appui.
Ce qui reste de votre ressort
La politique sur les pauses raccourcies et les limites, les notifications aux clients et le processus d'assistance pendant la pause.
- Circulaire BSP 1213, article 1 (section 148 du MORB), paragraphes (e)(iii), (iv) et (v)
Bloquer l'automatisation non autorisée et contrôler l'identité de l'appareil
Ce que dit le texte
Les BSFI doivent interdire l'usage de scripts ou d'outils d'automatisation non autorisés, comme le screen scraping et l'automatisation de navigateur, pour accéder aux comptes financiers et exécuter des transactions, au moyen de mesures telles que l'analyse comportementale, la limitation du débit, la gestion des sessions et la détection des bots. Elles devraient aussi adopter une empreinte d'appareil robuste et des mécanismes efficaces pour empêcher l'usurpation de l'identité de l'appareil. Des contrôles d'authentification et d'intégrité appropriés devraient garantir que les transactions initiées depuis les applications accessibles aux clients ne sont pas altérées avant ou pendant la transmission ou l'exécution dans les systèmes backend.
Source :Circulaire BSP 1213, article 1 (section 148 du MORB), paragraphes (e)(iii), (iv) et (v)
Ce que cela implique pour votre application mobile
Ces contrôles se trouvent dans l'API et le backend. La limitation du débit, la gestion des sessions, les contrôles d'intégrité et le lien avec l'appareil sont testables, et chacun peut manquer sur au moins un endpoint.
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 pour chaque résultat.
Ce qui reste de votre ressort
La gestion des bots et du WAF, la surveillance de la fraude et la gouvernance des données d'identité des appareils.
- Republic Act No. 10173, Data Privacy Act of 2012, article 20
Protéger les données personnelles et notifier les violations
Ce que dit le texte
En vertu du Data Privacy Act of 2012, les contrôleurs de données personnelles doivent mettre en œuvre des mesures organisationnelles, physiques et techniques raisonnables et appropriées pour protéger les données personnelles contre la destruction, l'altération et la divulgation accidentelles ou illicites, ainsi que contre tout autre traitement illicite. Ces mesures doivent inclure des protections des réseaux informatiques, une politique de sécurité, un processus d'identification et de traitement des vulnérabilités raisonnablement prévisibles de ces réseaux, et une surveillance régulière des violations de sécurité. Les contrôleurs doivent notifier rapidement la National Privacy Commission et les personnes concernées lorsque des données personnelles sensibles, ou des informations pouvant permettre une usurpation d'identité, sont raisonnablement soupçonnées d'avoir été acquises par une personne non autorisée et sont susceptibles d'entraîner un risque réel de préjudice grave.
Source :Republic Act No. 10173, Data Privacy Act of 2012, article 20
Ce que cela implique pour votre application mobile
Les données clients dans l'application et dans le trafic d'API sont des données personnelles, et les logiciels malveillants mobiles, les appareils rootés et le stockage non sécurisé sont les voies de fuite.
Comment Ostorlab vous aide
Ostorlab teste les mesures techniques de l'application et de ses API : stockage et journaux, transport, authentification et autorisation, et accès aux données d'autres clients par des contrôles d'accès défaillants, avec des preuves pour chaque résultat.
Ce qui reste de votre ressort
La gouvernance de la vie privée, les registres de traitement, l'évaluation des violations et la notification à la NPC et aux personnes concernées.
Synthèse des textes publics de la BSP et du Data Privacy Act, vérifiés le 27 septembre 2026. Les citations proviennent des circulaires telles que publiées par la Bangko Sentral ng Pilipinas. Cette page ne constitue pas un avis juridique.
Les règles de la BSP, contrôle par contrôle
Les contrôles visés par les textes de la BSP, 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 |
|---|---|---|
| Tests de sécurité applicative avant mise en productionCirculaire 982, 3.3.3.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 |
| Évaluation de vulnérabilité et tests d'intrusion externes annuelsCirculaire 982, 3.7.2 (c) et (d) | Tests externes à chaque version, avec gravités, tickets et retests entre vos tests annuels. Détails | Résultats de scan datés par version, et résultats de retest pour chaque correction |
| Développement sécurisé et tests statiques avant mise en productionCirculaire 982, 3.3.3.4 et 3.3.3.8.1 | Mobile SAST sur l'APK, l'AAB ou l'IPA, avec analyse de propagation (taint) sur l'application et ses SDK intégrés, depuis la CI/CD. Détails | Résultats avec le contexte du code décompilé, pour chaque build |
| Gestion des correctifs et composants vulnérablesCirculaire 982, 3.3.3.8.3 | 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 |
| Supervision des tiers et des SDKCirculaire 982, 3.3.3.8.4 ; circulaire 1213, (c) | Recense les SDK et bibliothèques natives de chaque version, et montre avec quels backends l'application et ses SDK communiquent. Détails | Identité, version et emplacement de chaque composant dans le bundle de l'application, par version |
| Identifiants et clés dans le package de l'applicationCirculaire 982, 3.3.3.4 | 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 |
| Appareils rootés, jailbreakés et émulésCirculaire 1213, (e)(ii) | Exécute l'application dans des environnements compromis et tente de contourner la détection du root, du jailbreak et des émulateurs. Détails | Score de durcissement, et preuves de contournement pour chaque protection qui a échoué |
| Codes PIN à usage unique interceptables et authentification forteCirculaire 1213, (e)(vi) | Se connecte avec des codes à usage unique et teste l'application effective de la MFA et les parcours d'authentification renforcée, y compris le rejeu et la réutilisation des codes. Détails | Résultats sur les parcours de connexion et d'authentification renforcée, avec étapes de reproduction |
| Modifications clés de compte, pause de 24 heures et anti-automatisationCirculaire 1213, (e)(i), (iii) et (v) | Teste les parcours de modification de compte et d'enregistrement d'appareil, les autorisations d'API, la gestion des sessions et les abus comme le rejeu et l'automatisation. Détails | Requêtes et réponses à l'appui de chaque résultat, et résultats de retest après correction |
| Protection des données sur l'appareil et en transitCirculaire 982, 3.3.3.5 ; RA 10173, article 20 | 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 |
Ostorlab teste les contrôles de l'application et de ses API. Les systèmes de surveillance de la fraude et la pause de transaction en tant que politique antifraude, l'envoi des alertes, la surveillance SOC, la réponse aux incidents et leur signalement, la conservation des journaux de transaction, la gouvernance et la soumission annuelle du CCSA restent du ressort de vos équipes.
Les contrôles de la BSP à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque informatique, fondée sur la circulaire 982, la circulaire 1213 et le Data Privacy Act.
Tests avant chaque version
Intégrez les tests de sécurité applicative, y compris les tests d'intrusion et l'analyse statique, au processus de version avant que le build n'atteigne la production.
VA et PT externes annuels
Planifiez une évaluation de vulnérabilité et des tests d'intrusion par une partie externe au moins une fois par an, en plus des tests à chaque version.
Composants et correctifs
Tenez une liste versionnée des SDK et bibliothèques de chaque version, et corrigez les problèmes à haut risque dans un délai raisonnable et documenté.
Secrets dans l'application
Recherchez dans le package de l'application les clés d'API, jetons et identifiants, et renouvelez ceux qui sont fonctionnels.
Appareils compromis
Exécutez l'application sur des appareils rootés, jailbreakés et émulés, et vérifiez que l'accès et les transactions sont restreints.
Codes à usage unique et authentification forte
Vérifiez que les codes à usage unique ne peuvent pas être rejoués ou détournés, et que les transactions à haut risque exigent une authentification forte.
Modifications de compte et pause
Testez que la modification du numéro de mobile, de l'e-mail et de l'appareil déclenche la période de pause, et qu'elle ne peut pas être contournée via l'application ou ses API.
Données sur l'appareil
Recherchez les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et testez la protection du transport.
Une liste indicative, et non un modèle de la BSP. 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
- 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
- Mobile Shielding ScanTestez à l'exécution la détection du root, du jailbreak et des émulateurs, l'anti-altération et le pinning, et voyez quelles protections ont tenu et lesquelles ont été contournées.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.
- BSP Circular No. 982, Series of 2017: Enhanced Guidelines on Information Security ManagementBSP, résolution du Monetary Board no 1854 du 2 novembre 2017, en vigueur le 5 décembre 2017. Modifie l'appendice 75b du MORB et l'appendice Q-59b du MORNBFI : gestion du risque de sécurité de l'information, sécurité applicative (3.3.3.4), sécurité des données (3.3.3.5), gestion des correctifs (3.3.3.8.3) et tests (3.7)
- BSP Circular No. 808, Series of 2013: Guidelines on Information Technology Risk Management for All Banks and Other BSP Supervised InstitutionsBSP, résolution du Monetary Board no 1286 du 1er août 2013, publiée le 22 août 2013. Le cadre de gestion du risque informatique pour les institutions supervisées, modifié par les circulaires suivantes
- BSP Circular No. 1140, Series of 2022: Amendments to Regulations on Information Technology Risk ManagementBSP, résolution du Monetary Board no 375 du 17 mars 2022, datée du 24 mars 2022. Ajoute des systèmes automatisés de surveillance et de détection de la fraude en temps réel et un programme renforcé de sensibilisation des consommateurs
- BSP Circular No. 1213, Series of 2025: Amendments to Regulations on Information Technology Risk Management to Implement Section 6 of the Anti-Financial Account Scamming Act (AFASA)BSP, résolution du Monetary Board no 521 du 22 mai 2025, datée du 30 mai 2025 et en vigueur le 25 juin 2025. Ajoute la pause de 24 heures, les restrictions sur les appareils non sécurisés, l'empreinte d'appareil, le contenu des notifications, l'interdiction des liens cliquables et des codes QR, et les limites sur les codes PIN à usage unique interceptables
- AFASA Booklet with Implementing Rules and RegulationsBSP, juin 2025. Republic Act No. 12010, signée le 20 juillet 2024, avec les circulaires BSP nos 1213, 1214 et 1215, série de 2025. L'article 6 exige des systèmes et contrôles de gestion des risques adéquats, dont la MFA, pour protéger l'accès aux comptes financiers des clients
- Republic Act No. 10173: Data Privacy Act of 2012National Privacy Commission, version web de la loi signée le 15 août 2012. L'article 20 exige des mesures de sécurité organisationnelles, physiques et techniques raisonnables et appropriées, ainsi que la notification des violations à la NPC et aux personnes concernées
- BSP Circular No. 1232, Series of 2026: Cybersecurity Maturity Framework (CMF) and Cybersecurity Control Self-Assessment (CCSA) RequirementBSP, datée du 27 avril 2026. Remplace l'IT Rating System par le Supervisory Assessment Framework et ajoute le CMF et le CCSA annuel, avec des niveaux de maturité liés au profil informatique de chaque institution
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.
Évaluez votre application bancaire mobile comme le décrit la BSP
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests authentifiés de votre application et de vos API avec notre équipe.