Taiwan, FSC et association des banques : testez votre application bancaire mobile comme le décrivent les normes professionnelles.

1. 01

   金融機構辦理電腦系統資訊安全評估辦法 第3條至第5條、第8條；金融控股公司及銀行業內部控制及稽核制度實施辦法 第12條、第14條、第24條、第25條 (texte chinois)

   Réaliser les évaluations annuelles et conserver la piste de preuves

   Ce que dit le texte

   Classez les systèmes informatiques par importance et établissez un plan d'évaluation pour l'ensemble du parc, interne et externalisé. Les systèmes de catégorie 1, qui fournissent directement des services automatisés aux clients ou affectent sensiblement l'exploitation, comme la banque électronique, les guichets, les distributeurs et SWIFT, doivent faire l'objet d'une évaluation de sécurité au moins une fois par an ; un incident de sécurité majeur déclenche une nouvelle évaluation dans les trois mois. Les contrôles sur l'application cliente comprennent l'analyse de vulnérabilités, l'analyse du code source ou les tests d'intrusion, la protection des données sensibles en mémoire et sur les supports de stockage, et la protection des clés. Le règlement sur le contrôle interne place le programme sous la responsabilité du responsable de la sécurité de l'information : une unité dédiée rattachée au directeur général, un responsable de niveau vice-président rendant compte au conseil chaque année, et des auto-contrôles généraux semestriels pour les unités informatiques.

   Source :金融機構辦理電腦系統資訊安全評估辦法 第3條至第5條、第8條；金融控股公司及銀行業內部控制及稽核制度實施辦法 第12條、第14條、第24條、第25條 (texte chinois)

   Ce que cela implique pour votre application mobile

   Votre application bancaire mobile se situe dans un système de catégorie 1 : l'évaluation annuelle doit couvrir l'application et le serveur auquel elle parle, y compris les données laissées en mémoire et dans le stockage et les clés présentes sur l'appareil. Le rapport va à l'unité d'audit et au conseil, et il est conservé cinq ans.

   Comment Ostorlab vous aide

   Le pentest par agents IA teste l'application et ses API derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat. Mobile SAST analyse le binaire, l'analyse des secrets valide les clés trouvées dans le package, et les résultats sont notés et suivis sous forme de tickets, de sorte que chaque évaluation dispose de preuves fraîches, version par version.

   Ce qui reste de votre ressort

   Le plan d'évaluation, la classification des systèmes, les qualifications des évaluateurs, l'approbation du rapport et la piste de contrôle interne et d'audit.

2. 02

   金融機構提供行動裝置應用程式作業規範 第9條 (texte chinois)

   Réussir le test annuel de référence et la revue OWASP L2

   Ce que dit le texte

   Chaque année, faites tester l'application par un laboratoire qualifié selon le référentiel de tests de sécurité de base des applications mobiles, et réussissez ce test. Réalisez aussi une analyse de code ou un test en boîte noire sur l'ensemble des fonctionnalités de l'application et de son serveur applicatif, et corrigez les vulnérabilités de niveau moyen et élevé ; faites tester l'application et le serveur par une unité d'évaluation selon les normes sur les applications mobiles et la OWASP Mobile Application Security Checklist L2. Les rapports du laboratoire et de l'unité d'évaluation doivent être examinés et transmis à l'unité chargée de la sécurité de l'information. Lorsqu'un résultat ne peut pas être corrigé, l'unité peut l'enregistrer comme risque accepté, avec l'évaluation au dossier.

   Source :金融機構提供行動裝置應用程式作業規範 第9條 (texte chinois)

   Ce que cela implique pour votre application mobile

   C'est un cycle annuel fixe avec des méthodes nommées : le test de référence, l'analyse de code ou le test en boîte noire, et la liste OWASP L2. Les résultats de niveau moyen et élevé exigent une correction ou une acceptation de risque documentée.

   Comment Ostorlab vous aide

   Ostorlab teste l'application et ses API sur les points de la OWASP Mobile Application Security Checklist L2, de l'analyse du binaire aux parcours authentifiés, et reteste après correction. Les résultats fournissent les preuves nécessaires à la revue que l'unité de sécurité de l'information doit effectuer.

   Ce qui reste de votre ressort

   La réservation du laboratoire qualifié et de l'unité d'évaluation, les décisions d'acceptation des risques et l'examen du rapport annuel.

3. 03

   金融機構提供行動裝置應用程式作業規範 第10條 (texte chinois)

   Tester chaque changement avant la mise en production

   Ce que dit le texte

   Lorsqu'une nouvelle fonctionnalité est mise en service, lorsque l'architecture du système change ou lorsqu'une fonctionnalité existante est modifiée, réalisez une analyse de code ou un test en boîte noire et corrigez les vulnérabilités de niveau moyen et élevé. Pour les fonctionnalités liées au mouvement de fonds, ou aux virements électroniques et instructions de transaction qui affectent sensiblement les droits des clients, testez selon l'OWASP Mobile Top 10 et corrigez les résultats de niveau moyen et élevé avant la mise en production. Si une mise en production d'urgence est inévitable, corrigez dans un délai défini et maintenez des contrôles jusqu'à la correction.

   Source :金融機構提供行動裝置應用程式作業規範 第10條 (texte chinois)

   Ce que cela implique pour votre application mobile

   Chaque version est un changement. Les fonctionnalités de mouvement de fonds relèvent du traitement plus strict de l'OWASP Mobile Top 10 et ne peuvent pas être mises en production avec des résultats de niveau moyen ou élevé.

   Comment Ostorlab vous aide

   Ostorlab lance des scans automatisés depuis votre pipeline CI/CD à chaque build et surveille les versions publiées sur les stores sans déclenchement manuel. Mobile SAST fonctionne sur l'APK, l'AAB ou l'IPA, sans besoin du code source, et le pentest par agents IA couvre les parcours de virement derrière la connexion.

   Ce qui reste de votre ressort

   La classification des changements, l'approbation des mises en production et les contrôles des mises en production d'urgence.

4. 04

   金融機構提供行動裝置應用程式作業規範 第5條、第15條；行動應用App基本資安檢測基準 V4.0, 4.1.5.5 (texte chinois)

   Gérer les appareils compromis et protéger l'exécution

   Ce que dit le texte

   Au démarrage, si l'application détecte un appareil qui semble compromis, par exemple root, jailbreak ou débogage USB, elle doit avertir l'utilisateur et restreindre les virements non désignés et les instructions de transaction. Lorsque l'application sert de mécanisme de re-confirmation des transactions pour les transactions à haut risque des clients professionnels, les normes exigent des mesures anti-intrusion (éviter les appareils compromis, vérifier l'intégrité de l'application et des bibliothèques, empêcher la superposition d'écran, résister à l'ingénierie inverse), une protection à l'exécution (empêcher le reconditionnement et l'écoute, bloquer le code non autorisé, bloquer les captures d'écran et les écrans étendus, détecter les émulateurs, avertir en mode débogage) et la protection des données sensibles (mémoire et fichiers, clés protégées par l'appareil, anti-clonage). Le référentiel de tests fait de la détection du root et du jailbreak, de l'obfuscation, de la détection d'émulateur, de la détection du débogage USB et de la désactivation du mode débogage une partie de ses tests optionnels de classe F.

   Source :金融機構提供行動裝置應用程式作業規範 第5條、第15條；行動應用App基本資安檢測基準 V4.0, 4.1.5.5 (texte chinois)

   Ce que cela implique pour votre application mobile

   La détection seule ne suffit pas : l'application doit avertir et restreindre, et les protections doivent survivre à une véritable tentative de contournement, pas seulement exister dans le code.

   Comment Ostorlab vous aide

   Mobile Shielding Scan exécute l'application dans des environnements rootés, jailbreakés, émulés et avec débogage USB, tente de contourner la détection du root, l'anti-altération et le pinning TLS, et montre si l'application bloque le parcours, refuse de démarrer ou continue de fonctionner. Vous obtenez des preuves de contournement et un score de durcissement.

   Ce qui reste de votre ressort

   La politique relative aux appareils compromis et le choix et la configuration de votre produit de protection.

5. 05

   金融機構提供行動裝置應用程式作業規範 第11條至第14條；金融機構辦理電子銀行業務安全控管作業基準 第6條 (texte chinois)

   Stocker les clés et les codes à usage unique comme l'exigent les normes

   Ce que dit le texte

   Les clés stockées sur l'appareil mobile doivent se trouver soit dans un élément sécurisé conforme à CNS 15408 EAL5, aux Critères communs ISO/IEC 15408 v2.3 EAL5 ou à FIPS 140-2 niveau 3 ou supérieur, soit être protégées par logiciel avec de la cryptographie en boîte blanche et de l'obfuscation de code, confirmée par une unité d'évaluation. Lorsqu'une opération à clé, comme un OTP ou un TAC, sert aux virements vers des comptes non désignés, la clé doit être confirmée comme se trouvant sur l'appareil désigné par le client. Le téléchargement de données sensibles par voie hertzienne exige la confirmation de l'identité de l'utilisateur et un chiffrement de bout en bout entre la banque et l'application. Les clés détenues dans un élément sécurisé nécessitent un contrôle d'accès limité aux applications de confiance, et les données de paiement NFC une confirmation manuelle par l'utilisateur. La norme sur la banque électronique applique ses niveaux de confiance d'identité numérique aux mêmes parcours.

   Source :金融機構提供行動裝置應用程式作業規範 第11條至第14條；金融機構辦理電子銀行業務安全控管作業基準 第6條 (texte chinois)

   Ce que cela implique pour votre application mobile

   L'application doit prouver où réside la clé et que c'est bien l'appareil du client qui la détient. Une cryptographie en boîte blanche sans obfuscation, ou un OTP généré ailleurs, ne satisfait pas le texte.

   Comment Ostorlab vous aide

   Ostorlab détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels, examine la façon dont les clés et les valeurs sensibles sont stockées et protégées sur l'appareil, et intercepte le trafic, même avec TLS pinning, pour tester les parcours OTP et de virement avec vos comptes de test.

   Ce qui reste de votre ressort

   Le choix de l'élément sécurisé ou de la conception en boîte blanche, le cycle de vie des clés et le processus de liaison à l'appareil.

6. 06

   金融機構辦理電子銀行業務安全控管作業基準 第7條至第9條、第11條 (texte chinois)

   Appliquer la norme sur la banque électronique au canal mobile

   Ce que dit le texte

   Les systèmes applicatifs mobiles fournis aux clients doivent suivre les normes sur les applications mobiles. Les systèmes applicatifs exposés à Internet doivent contrôler les sessions et couper la connexion après dix minutes d'inactivité, éviter les failles d'injection et de cross-site scripting, et protéger les mots de passe fixes contre la capture via des navigateurs intégrés. Les transactions sont réparties par risque : les transactions à haut risque, y compris les virements non désignés au-delà de la limite de faible risque, exigent le niveau de confiance le plus élevé, et les transactions à haut risque des clients professionnels des mesures supplémentaires comme la re-confirmation de la transaction par deux personnes, des limites et une notification immédiate. Les transmissions de données à des tiers et les services externalisés doivent être couverts par des contrats imposant le respect de la norme.

   Source :金融機構辦理電子銀行業務安全控管作業基準 第7條至第9條、第11條 (texte chinois)

   Ce que cela implique pour votre application mobile

   Le délai de dix minutes, les niveaux de confiance de connexion et de transaction et la protection contre la capture par navigateur intégré sont des comportements concrets de l'application et du backend qui la sous-tend.

   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, y compris les parcours d'authentification renforcée, ainsi que les appels d'API qui les sous-tendent. Le pentest par agents IA teste la logique métier des parcours de virement.

   Ce qui reste de votre ressort

   Le choix du niveau de confiance pour chaque service, les limites de transaction, la conception de la re-confirmation pour les clients professionnels et les contrats avec les tiers.

7. 07

   金融資安韌性發展藍圖 (plan de résilience de la cybersécurité financière), mesures 7 à 9, décembre 2025 (texte chinois)

   Intégrer la sécurité, connaître vos composants et sécuriser les API

   Ce que dit le texte

   Le plan de la FSC de décembre 2025 encourage les institutions financières à adopter un développement, des tests et un déploiement logiciels sécurisés, en référence à NIST SSDF, OWASP SAMM et OWASP ASVS : évaluation des risques ou modélisation des menaces dès la conception, contrôles de sécurité intégrés au développement, et outils SAST et DAST intégrés au pipeline de publication. Il demande aussi une analyse de composition logicielle pour identifier les composants, y compris open source et tiers, produire une nomenclature logicielle, et la relier à des bases de vulnérabilités comme CVE ou le catalogue CISA KEV, avec un mécanisme de surveillance des vulnérabilités et de mise à jour des versions. Une autre mesure élabore une base de sécurité des API couvrant les API partenaires et internes, classées par sensibilité des données, en s'appuyant sur l'OWASP API Security Top 10.

   Source :金融資安韌性發展藍圖 (plan de résilience de la cybersécurité financière), mesures 7 à 9, décembre 2025 (texte chinois)

   Ce que cela implique pour votre application mobile

   Les SDK et bibliothèques natives de l'application sont les composants dont parle le plan, et les API appelées par l'application entrent dans le champ de la future base API. Les données de composants par version sont le moyen pratique d'y répondre.

   Comment Ostorlab vous aide

   Mobile SAST et DAST s'exécutent dans la CI/CD à chaque build. SCA identifie par empreinte les bibliothèques compilées statiquement, les associe aux vulnérabilités connues et recense les composants et versions de chaque version. Les tests d'API vérifient les autorisations, les usages abusifs des jetons et les abus comme l'énumération et le rejeu.

   Ce qui reste de votre ressort

   La politique de développement sécurisé, la modélisation des menaces, l'inventaire et la gouvernance des API, et les décisions de mise à niveau des versions.

8. 08

   金融機構提供行動裝置應用程式作業規範 第3條、第4條、第7條、第8條 (texte chinois)

   Contrôler la publication et surveiller les fausses applications

   Ce que dit le texte

   Le processus de publication de l'application doit être contrôlé par au moins deux personnes ou deux contrôles techniques. Avant chaque publication, vérifiez que les permissions demandées par l'application correspondent au service fourni, et faites approuver la première publication ou tout changement de permissions par les unités de sécurité de l'information, de conformité et de risque, y compris les informations requises par la loi sur la protection des données personnelles. Publiez le nom, la version et l'emplacement de téléchargement de l'application sur le site officiel, et maintenez un mécanisme pour détecter les fausses versions de l'application et les retirer ou alerter les clients.

   Source :金融機構提供行動裝置應用程式作業規範 第3條、第4條、第7條、第8條 (texte chinois)

   Ce que cela implique pour votre application mobile

   Les permissions, l'approbation des publications et la détection de clones sont des contrôles au niveau de l'application qui peuvent être vérifiés sur la version que vous publiez.

   Comment Ostorlab vous aide

   Ostorlab recense les permissions demandées par l'application ainsi que les SDK et bibliothèques natives qu'elle contient, et surveille les versions publiées sur les stores pour qu'aucune nouvelle version ne passe sans test.

   Ce qui reste de votre ressort

   L'approbation des publications, les informations légales, le retrait des fausses applications et la communication aux clients.

9. 09

   金融機構資通系統與服務供應鏈風險管理規範 第2條、第6條、第7條 (texte chinois)

   Gérer les SDK et les fournisseurs que vous livrez

   Ce que dit le texte

   La norme sur la chaîne d'approvisionnement s'applique aux systèmes critiques et de catégorie 1, ainsi qu'aux autres systèmes qui fournissent des services exposés à Internet, permettent aux fournisseurs d'accéder à des données sensibles ou coûtent au moins 10 millions de dollars taïwanais. Les contrats doivent exiger des fournisseurs qu'ils livrent des systèmes et programmes exempts de programmes malveillants et de portes dérobées, avec des résultats de tests de sécurité ou un engagement de sécurité pour les produits et composants qu'ils fournissent. Les banques conservent des droits d'audit, doivent réaliser des audits de sécurité des fournisseurs clés et examiner les résultats des tests de sécurité de ce que les fournisseurs livrent pendant le contrat.

   Source :金融機構資通系統與服務供應鏈風險管理規範 第2條、第6條、第7條 (texte chinois)

   Ce que cela implique pour votre application mobile

   Une application bancaire mobile embarque des SDK tiers qui communiquent avec leurs propres backends. Ce sont des fournisseurs au sens du texte, et leurs composants ont leur place dans les résultats de tests de sécurité que vous examinez.

   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, les rapproche des vulnérabilités connues, et montre ce que l'application et ses SDK échangent avec les backends sur le réseau.

   Ce qui reste de votre ressort

   Les contrats fournisseurs, les vérifications préalables, les droits d'audit et l'acceptation des risques.

10. 10

    個人資料保護法 第12條、第21條、第27條；金融監督管理委員會指定非公務機關個人資料檔案安全維護辦法 第6條、第9條、第10條、第13條、第14條 (texte chinois)

    Protéger les données personnelles et se préparer à notifier

    Ce que dit le texte

    Selon la loi sur la protection des données personnelles, une entité non publique qui détient des fichiers de données personnelles doit prendre des mesures de sécurité appropriées pour prévenir le vol, l'altération, la destruction, la perte ou la fuite, et doit notifier les personnes concernées après enquête sur une atteinte. Les mesures de maintenance de la FSC pour le secteur financier ajoutent les détails : règles sur les appareils et supports, chiffrement et sauvegardes protégées ; pour les systèmes de services de commerce électronique, vérification de l'identité de l'utilisateur, masquage des données, chiffrement sécurisé des transmissions Internet, vérification et validation logicielles au développement, à la mise en service et à la maintenance, contrôle d'accès et surveillance des fichiers et bases de données personnels, et surveillance des usages anormaux ; un mécanisme d'audit de sécurité au sein du contrôle interne ; et des enregistrements conservés au moins cinq ans. Un incident majeur de données personnelles doit être signalé à la FSC dans les 72 heures. La loi a été modifiée le 11 novembre 2025 pour ajouter une obligation générale de maintien de la sécurité et un régime plus large de notification des violations, mais la date d'entrée en vigueur n'avait pas été fixée par l'Exécutif en septembre 2026.

    Source :個人資料保護法 第12條、第21條、第27條；金融監督管理委員會指定非公務機關個人資料檔案安全維護辦法 第6條、第9條、第10條、第13條、第14條 (texte chinois)

    Ce que cela implique pour votre application mobile

    Les mots de passe, jetons et données personnelles ne devraient jamais être stockés en clair sur le téléphone ni transiter sans protection vers le backend, et l'application ne devrait pas les journaliser ni les exposer là où d'autres applications peuvent les lire.

    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 si l'application peut atteindre les données d'autres clients par ses API.

    Ce qui reste de votre ressort

    La classification des données, la réponse aux violations et leur notification, les enregistrements de conservation et l'audit de sécurité.

Synthèse des textes publics taïwanais, vérifiés le 27 septembre 2026. Les normes de l'association des banques et les mesures de la FSC sur les données personnelles sont résumées d'après les textes chinois. La modification de la loi sur la protection des données du 11 novembre 2025 n'est pas encore en vigueur. Cette page ne constitue pas un avis juridique.