Règles e-finance coréennes : évaluez votre application bancaire mobile selon le cycle annuel et avant chaque version.
La loi sur les transactions financières électroniques impose aux sociétés financières et aux entreprises de financement électronique d'analyser et d'évaluer leurs infrastructures financières électroniques et d'en transmettre les résultats à la FSC. Le règlement de supervision des activités financières électroniques fixe le cycle, l'équipe et les délais de correction, et les critères du Financial Security Institute couvrent désormais le cloud et les applications mobiles, avec 288 applications mobiles de 32 entreprises prévues pour évaluation en 2026. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Évalue l'application mobile et les API qu'elle appelle, sur le build que téléchargent vos clients
- Teste la connexion, les codes à usage unique, les vérifications d'authentification renforcée et la gestion des sessions avec vos comptes de test
- Recense les SDK et bibliothèques natives de chaque version et les rapproche des vulnérabilités connues
- Prouve chaque résultat par un exploit rejouable ou par les requêtes et réponses à l'appui
- Qui est concerné
- Les banques, les entreprises de financement électronique et les autres institutions supervisées au titre de la loi sur les transactions financières électroniques, ainsi que les opérateurs MyData au titre de la loi sur l'information de crédit
- Date clé
- Règlement en vigueur le 15 juillet 2026 ; exception de séparation des réseaux pour le SaaS depuis le 20 avril 2026 ; réforme axée sur les principes depuis le 5 février 2025
- Objet
- Analyse et évaluation annuelles des vulnérabilités, sécurité des applications mobiles et des API, authentification, intégrité des programmes et protection des données
- Texte de référence
- Règlement de supervision des activités financières électroniques et critères d'évaluation du Financial Security Institute
Les textes coréens qui encadrent votre canal mobile
Le règlement s'appuie sur la loi sur les transactions financières électroniques, et les critères du Financial Security Institute le traduisent en contrôles. Les dates ci-dessous concernent les textes cités sur cette page.
- 13 août 2024
Feuille de route sur la séparation des réseaux
La FSC annonce une réforme par étapes des règles de séparation des réseaux : IA générative, usage élargi du SaaS, meilleurs environnements de recherche et développement, et transition vers l'autosécurité avec responsabilité sur les résultats.
- 5 février 2025
Réforme du règlement
Le règlement est modifié pour passer de règles détaillées à des principes, réduisant environ 293 prescriptions à 166, et ajoute les articles sur l'authentification et la gestion des mots de passe.
- 30 décembre 2025
Critères du FSI pour 2026
Le Financial Security Institute révise ses critères d'évaluation : nouvelle zone de gestion du cloud, contrôles des systèmes dont le support des correctifs a pris fin, séparation des serveurs entre système d'exploitation et intergiciel, et nouveaux critères pour les plateformes d'actifs virtuels.
- 13 février 2026
Programme d'évaluation du FSI
Le Financial Security Institute prévoit d'évaluer 178 institutions financières, élargit les critères de 14 domaines et 789 éléments à 15 domaines et 869 éléments, et programme 288 applications mobiles de 32 entreprises.
- 20 avril 2026
Exception SaaS à la séparation des réseaux
Les règles d'application du règlement sont modifiées pour permettre l'usage du SaaS sur les réseaux de travail internes sous contrôles stricts, sans exception lorsque des identifiants uniques ou des informations de crédit personnelles sont traitées.
- 29 juin 2026
Réunion de la FSS sur les risques IT
La FSS demande à 491 institutions de corriger les contrôles IT de base et de rendre l'analyse et l'évaluation des vulnérabilités efficaces, et annonce des inspections au second semestre incluant les conditions SaaS.
- 29 juillet 2026
Guide sur le risque IT des tiers
La FSS et sept associations professionnelles publient un guide qui place la responsabilité finale au conseil d'administration et exige une structure de contrôle à trois niveaux, l'identification des tiers clés et la gestion du cycle de vie des contrats.
Les règles e-finance coréennes, 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 lois et le règlement sont résumés d'après le texte coréen.
- Loi sur les transactions financières électroniques, article 21-3 ; règlement de supervision des activités financières électroniques, articles 37-2 et 37-3 (texte coréen)
Mener l'analyse et l'évaluation annuelles des vulnérabilités
Ce que dit le texte
Au titre de l'article 21-3 de la loi sur les transactions financières électroniques, les sociétés financières et les entreprises de financement électronique doivent analyser et évaluer leurs infrastructures financières électroniques, en couvrant l'organisation, les installations et le contrôle interne de la division informatique, les dispositifs électroniques et les supports d'accès, ainsi que les mesures de réponse aux incidents qui maintiennent les transactions financières électroniques, et transmettre les résultats à la FSC. L'article 37-2 du règlement fixe le cycle : au moins une fois par an pour les institutions dont le total d'actifs atteint 2 000 milliards de wons ou plus et qui comptent 300 salariés permanents ou plus, les pages d'accueil publiques étant contrôlées au moins tous les six mois, et au moins une fois par an pour les autres institutions. Les travaux sont menés par une équipe dédiée de cinq personnes ou plus incluant le CISO, dont au moins 30 % disposent de qualifications, ou confiés à un organisme d'évaluation désigné au titre de l'article 37-3. Un plan de mise en œuvre doit éliminer chaque vulnérabilité ou prendre une mesure équivalente ; si cela est impossible, le PDG approuve l'exception, et les résultats lui sont rapportés.
Ce que cela implique pour votre application mobile
L'évaluation annuelle est la base pour les institutions financières coréennes. Si l'application mobile et les API qu'elle appelle n'y figurent pas, votre canal client échappe à l'évaluation.
Comment Ostorlab vous aide
Ostorlab exécute des pentests par agents IA sur la version publiée et les API qui la sous-tendent, derrière la connexion, ainsi que Mobile SAST et SCA, selon un calendrier qui couvre le cycle annuel et chaque version. Chaque résultat d'un agent IA est accompagné d'un exploit fonctionnel à rejouer.
Ce qui reste de votre ressort
L'évaluation institutionnelle et son rapport à la FSC, l'équipe dédiée ou le contrat avec un organisme d'évaluation désigné, et le plan de remédiation.
- Financial Security Institute, analyse et évaluation des vulnérabilités 2026, 13 février 2026 ; révision des critères 2026, 30 décembre 2025 (texte coréen)
Inscrire les applications mobiles dans le périmètre du FSI
Ce que dit le texte
Le Financial Security Institute (FSI) réalise la majeure partie des travaux d'analyse et d'évaluation des vulnérabilités et révise ses critères chaque année. Pour 2026, il a élargi les critères relatifs aux infrastructures financières électroniques de 14 domaines et 789 éléments en 2025 à 15 domaines et 869 éléments, ajouté 73 critères propres aux environnements cloud, renforcé les contrôles des systèmes et équipements dont le support des correctifs de sécurité a pris fin et créé une équipe de tests d'intrusion. Il prévoyait d'évaluer 288 applications mobiles de 32 entreprises en 2026. Ses contrôles de sécurité fintech comprennent aussi un contrôle des vulnérabilités de service pour le mobile et le web, utilisé par les institutions d'open banking et les opérateurs MyData pour leurs contrôles périodiques.
Ce que cela implique pour votre application mobile
La sécurité des applications mobiles fait partie intégrante du système d'évaluation coréen, ce n'est pas un supplément. Les critères portent sur l'application, ses protections côté client et son authentification, ainsi que sur le côté serveur.
Comment Ostorlab vous aide
Ostorlab teste les contrôles décrits par ces critères : analyse binaire avec analyse de propagation (taint) sur l'application et ses SDK intégrés, contrôles à l'exécution des protections contre le root, le jailbreak, l'altération et le pinning, et tests authentifiés des API derrière la connexion. Les résultats correspondent aux contrôles demandés par votre évaluateur.
Ce qui reste de votre ressort
La contractualisation de l'évaluation, la relation avec le FSI ou un organisme désigné, et le reporting institutionnel.
- Règlement de supervision des activités financières électroniques, article 34(1)4 (texte coréen)
Vérifier l'intégrité du programme de transaction
Ce que dit le texte
L'article 34(1)4 du règlement impose aux sociétés financières et aux entreprises de financement électronique de fournir un moyen de vérifier que le programme de transaction financière électronique, y compris les messages de transaction, n'a pas été falsifié ou altéré.
Source :Règlement de supervision des activités financières électroniques, article 34(1)4 (texte coréen)
Ce que cela implique pour votre application mobile
Une application modifiée ou un message de transaction modifié doit être détectable. La détection d'altération et les contrôles d'intégrité sont la partie côté application ; le backend doit contrôler le côté transaction.
Comment Ostorlab vous aide
Mobile Shielding Scan teste à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et indique quelles protections ont tenu et lesquelles ont été contournées ; Mobile SAST examine la logique d'intégrité dans le binaire.
Ce qui reste de votre ressort
Le choix de la technologie de protection, la décision de ce que fait l'application lorsqu'un contrôle d'intégrité échoue, et les contrôles de transaction côté backend.
- Règlement de supervision des activités financières électroniques, articles 34-2, 34-3 et 19-2, ajoutés le 5 février 2025 (texte coréen)
Gérer les méthodes d'authentification et les mots de passe
Ce que dit le texte
Le règlement a été modifié le 5 février 2025 et a ajouté l'article 34-2, qui exige des méthodes d'authentification sûres tenant compte du type, de la nature et du niveau de risque de la transaction, l'article 34-3, qui impose que les mots de passe des utilisateurs soient stockés chiffrés et non lisibles, fixe des règles de création et de changement de mot de passe, exige la suspension des transactions après plusieurs saisies de mot de passe erronées et la vérification de l'identité avant leur reprise, et impose une saisie par pavé PIN ou équivalent, et l'article 19-2, qui exige un plan de gestion des moyens d'authentification tels que les mots de passe et les données biométriques, couvrant la délivrance, la conservation, le changement périodique et le traitement des erreurs d'authentification.
Ce que cela implique pour votre application mobile
Le verrouillage, la politique de mots de passe et le traitement des données biométriques sont des comportements que le backend impose. L'application ne doit pas pouvoir les contourner ou les affaiblir, et les parcours clients qui les utilisent doivent tenir.
Comment Ostorlab vous aide
Les tests authentifiés couvrent la connexion et la déconnexion, les codes à usage unique, les parcours d'authentification renforcée, le verrouillage après des échecs répétés, le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions, avec les appels d'API qui les sous-tendent.
Ce qui reste de votre ressort
La politique d'authentification, le choix des facteurs et l'assistance aux clients dont le compte est verrouillé.
- Règlement de supervision des activités financières électroniques, article 36 (texte coréen)
Passer l'examen interne de sécurité avant un nouveau service
Ce que dit le texte
L'article 36 du règlement exige un examen interne de sécurité, selon les normes et procédures fixées par la FSS, avant qu'un nouveau service de financement électronique ne soit proposé sur des réseaux informatiques. Le rapport d'examen est transmis à la FSS dans les 30 jours suivant le démarrage du service, et la FSS peut exiger des améliorations lorsqu'elle estime le niveau de sécurité insuffisant.
Source :Règlement de supervision des activités financières électroniques, article 36 (texte coréen)
Ce que cela implique pour votre application mobile
Les nouveaux services et les changements majeurs nécessitent un examen de sécurité avant le lancement, et l'application est le point de contact des clients avec le service. Attendre l'après-lancement prive l'examen de preuves techniques.
Comment Ostorlab vous aide
Les pentests avant lancement de l'application et des API qui la sous-tendent fournissent les preuves techniques nécessaires à l'examen interne de sécurité ; la surveillance des versions publiées montre ce qui a changé après le lancement.
Ce qui reste de votre ressort
L'examen lui-même, le rapport à la FSS et les décisions sur son périmètre.
- Règlement de supervision des activités financières électroniques, article 15 ; feuille de route de la FSC sur la séparation des réseaux, 13 août 2024 ; FSC et FSS, exception SaaS à la séparation des réseaux, 20 avril 2026 (texte coréen)
Composer avec la réforme de la séparation des réseaux
Ce que dit le texte
Le règlement impose la séparation des systèmes de travail internes des réseaux externes, avec des exceptions limitées. La feuille de route de la FSC du 13 août 2024 sur l'amélioration de la séparation des réseaux a fixé une réforme par étapes : autoriser l'IA générative, élargir l'usage des logiciels en cloud, améliorer les environnements de recherche et développement et évoluer vers un cadre d'autosécurité avec responsabilité sur les résultats. Le 20 avril 2026, les règles d'application du règlement ont été modifiées pour ajouter le SaaS aux exceptions. Le SaaS peut être utilisé sur les réseaux de travail internes lorsqu'il a été évalué par un organisme de réponse aux incidents tel que le FSI, que les terminaux comme les ordinateurs et les appareils mobiles sont protégés, que l'authentification sûre et le moindre privilège s'appliquent, que les flux d'informations importantes sont surveillés et contrôlés, que le partage inutile et l'accès Internet non autorisé sont bloqués, que les sections réseau sont chiffrées, et que la conformité est évaluée deux fois par an et rapportée au comité de protection de l'information présidé par le CISO. Il n'y a pas d'exception lorsque des identifiants uniques ou des informations de crédit personnelles sont traitées, et les informations pseudonymisées passent toujours par la procédure de service financier innovant.
Ce que cela implique pour votre application mobile
La réforme change le lieu de travail, pas les attentes des clients. Le développement et les outils peuvent migrer vers des services cloud, mais l'application et ses API doivent toujours être testées, et certaines données ne peuvent pas quitter le pays.
Comment Ostorlab vous aide
Les scans Ostorlab s'exécutent depuis votre pipeline CI/CD ou on-premises derrière votre pare-feu, sur une infrastructure que vous contrôlez, de sorte que l'artefact de l'application et les données de test restent dans votre environnement. Les données clients de production ne sont pas nécessaires.
Ce qui reste de votre ressort
L'architecture réseau, les évaluations SaaS et les évaluations semestrielles avec le reporting au comité.
- FSS, guide de gestion du risque IT des tiers, 29 juillet 2026 ; Financial Security Institute, plateforme de sécurité de la chaîne d'approvisionnement logicielle, 28 juillet 2025 (texte coréen)
Gérer le risque IT des tiers et la chaîne d'approvisionnement logicielle
Ce que dit le texte
Le 29 juillet 2026, la FSS et sept associations professionnelles ont publié le guide de gestion du risque IT des tiers. Le conseil d'administration porte la responsabilité finale, une structure de contrôle à trois niveaux (département de gestion générale, département de gestion des risques et département d'audit interne) gère le risque, les tiers importants pour l'institution ou ses clients sont désignés séparément et examinés au moins tous les six mois, et les contrats couvrent la diligence raisonnable, les rôles et responsabilités, la continuité, la sortie et la destruction des données. Le FSI a annoncé le 28 juillet 2025 une plateforme de sécurité de la chaîne d'approvisionnement logicielle qui fournit la gestion intégrée des vulnérabilités, la gestion des SBOM et l'exploitation de bug bounties, pleinement opérationnelle à partir de 2026.
Ce que cela implique pour votre application mobile
Les SDK intégrés à votre application et les backends qu'ils appellent sont des tiers. Leurs composants ont besoin de versions, de vulnérabilités connues et d'un responsable, et le contrat et le compte rendu d'examen doivent correspondre.
Comment Ostorlab vous aide
SCA et SBOM recensent les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle de l'application, les rapprochent des vulnérabilités connues et suivent leur résolution version après version. L'analyse réseau montre avec quels backends l'application et ses SDK communiquent.
Ce qui reste de votre ressort
La diligence raisonnable, les contrats, le registre des tiers et le reporting au conseil.
- Loi sur la protection des données personnelles, articles 29 et 34 ; normes de la PIPC sur la sécurité des données personnelles, avis n° 2026-9 (texte coréen)
Protéger les données personnelles au titre de la PIPA
Ce que dit le texte
La loi sur la protection des données personnelles impose aux responsables du traitement de prendre les mesures techniques, managériales et physiques nécessaires pour protéger les données personnelles (article 29), et de notifier les personnes concernées et de déclarer à la Personal Information Protection Commission ou à la Korea Internet and Security Agency dans les cas prévus lorsque des données personnelles sont perdues, volées ou divulguées (article 34). Les normes de la PIPC, avis n° 2026-9 en vigueur depuis le 1er juillet 2026, fixent les mesures minimales : gestion des autorisations d'accès, contrôle des accès incluant une authentification sûre pour l'accès à distance et la protection des appareils mobiles, chiffrement y compris lors de la transmission de données personnelles sur des sections Internet, conservation et contrôle mensuel des journaux d'accès, prévention des logiciels malveillants, préparation aux sinistres et contrôles des sorties et des copies.
Ce que cela implique pour votre application mobile
Le téléphone fait partie de l'environnement de traitement. Les mots de passe, jetons et données personnelles doivent être chiffrés, les accès journalisés, et l'exposition dans le stockage, les journaux, les captures d'écran et les caches doit être empêchée.
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 les protections du transport et les erreurs de configuration qui les affaiblissent, et détecte les clés d'API et identifiants dans le package de l'application.
Ce qui reste de votre ressort
Le plan de gestion interne, le rôle de délégué à la protection des données, la notification et la déclaration des violations, et les revues d'accès.
- Loi sur l'utilisation et la protection des informations de crédit, articles 19 et 32 ; règlement de supervision de l'activité d'information de crédit, contrôle annuel des vulnérabilités MyData ; FSI, évaluation permanente de la protection de l'information, 28 avril 2026 (texte coréen)
Couvrir l'information de crédit et les contrôles MyData
Ce que dit le texte
La loi sur l'utilisation et la protection des informations de crédit impose aux sociétés et utilisateurs d'informations de crédit de mettre en place des mesures de sécurité techniques, physiques et managériales afin que le système informatique d'informations de crédit soit protégé contre les accès non autorisés, les altérations, les destructions et autres risques (article 19), et fixe les règles de fourniture et d'utilisation des informations de crédit personnelles avec le consentement de la personne concernée (article 32). Selon le règlement de supervision de l'activité d'information de crédit, les opérateurs MyData doivent faire examiner leur service par le FSI lors de son développement ou d'une modification importante, et faire réaliser un contrôle des vulnérabilités de sécurité au moins une fois par an par le FSI, un organisme d'évaluation désigné au titre du règlement ou une équipe dédiée. L'évaluation permanente de la protection de l'information du FSI couvre environ 3 000 institutions financières au titre de la loi et, pour 2026, elle a renforcé les critères relatifs aux droits d'accès et aux journaux, au chiffrement des données personnelles, à la surveillance des comportements anormaux, à la minimisation des sorties, aux contrôles de vulnérabilités, à la détection et au blocage des intrusions, à la protection contre les logiciels malveillants et au consentement.
Ce que cela implique pour votre application mobile
Si votre application fait partie d'un service MyData ou d'information de crédit, un contrôle annuel des vulnérabilités de sécurité est déjà attendu, et les contrôles de l'application et des API y figurent.
Comment Ostorlab vous aide
Ostorlab teste l'application et ses API sur ces domaines de contrôle et produit des preuves pour chaque résultat, afin que le contrôle annuel puisse se concentrer sur les éléments institutionnels.
Ce qui reste de votre ressort
La licence MyData et la procédure d'examen, le contrôle annuel et l'évaluation permanente.
- FSS, réunion de réponse aux risques IT, 29 juin 2026 (texte coréen)
Corriger, signaler et retester
Ce que dit le texte
Lors de la réunion de réponse aux risques IT du 29 juin 2026, la FSS a indiqué à 491 institutions que certaines avaient des contrôles IT de base insuffisants, et a énoncé cinq points pour prévenir les accidents de financement électronique : respecter les contrôles IT de base, rendre l'analyse et l'évaluation des vulnérabilités plus efficaces, renforcer la sécurité des installations électriques, empêcher les accès non autorisés via les réseaux sans fil, et suivre les procédures de réponse aux incidents et de déclaration. Elle a demandé aux institutions de définir clairement le périmètre et les critères des évaluations de vulnérabilités, d'établir des plans de remédiation, d'éviter l'acceptation excessive des risques et d'assurer le suivi des corrections. Au second semestre 2026, elle contrôlera le respect des contrôles IT de base et des conditions SaaS de séparation des réseaux.
Source :FSS, réunion de réponse aux risques IT, 29 juin 2026 (texte coréen)
Ce que cela implique pour votre application mobile
Une évaluation qui se termine par un rapport ne suffit pas. Les superviseurs examinent le périmètre, les délais, les corrections et les retests, ainsi que la réapparition des mêmes problèmes.
Comment Ostorlab vous aide
Les résultats deviennent des tickets dans la plateforme ou dans Jira et ServiceNow, avec leur gravité, et sont retestés après correction ; l'historique des tickets constitue la trace de la remédiation.
Ce qui reste de votre ressort
Le périmètre et les critères, les décisions d'acceptation des risques et le reporting aux superviseurs.
Synthèse de textes coréens publics, vérifiés le 27 septembre 2026. Les lois et le règlement sont résumés d'après le texte coréen. Cette page ne constitue pas un avis juridique.
Les règles coréennes, contrôle par contrôle
Les contrôles visés par les textes coréens, 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 |
|---|---|---|
| Analyse et évaluation annuelles des vulnérabilitésLoi e-finance, art. 21-3 ; règlement, art. 37-2 | Pentest par agents IA de la version publiée et de ses API, derrière la connexion, planifié sur le cycle annuel et à chaque version. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Évaluation des applications mobiles dans les critères du FSICritères FSI 2026 | Analyse binaire des APK, AAB et IPA avec analyse de propagation sur l'application et ses SDK intégrés. Détails | Résultats statiques avec le code et l'emplacement des composants, par version |
| Intégrité du programme de transactionRèglement, art. 34(1)4 | Teste à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et indique quelles protections ont tenu. Détails | Un rapport d'exécution montrant chaque protection et son résultat sur la version publiée |
| Authentification, verrouillage et gestion des sessionsRèglement, art. 34-2, 34-3, 19-2 | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée, le verrouillage après des échecs répétés et l'invalidation des sessions. Détails | Résultats sur les parcours de connexion et d'authentification renforcée, avec étapes de reproduction, et journaux de session et de jetons |
| Examen interne de sécurité avant un nouveau serviceRèglement, art. 36 | Mobile DAST et pentests avant lancement de l'application et de ses API fournissent les preuves techniques de l'examen. Détails | Résultats de scan avant lancement par build et par changement de service |
| Identifiants intégrés à l'application et aux APIRèglement, art. 19-2 | 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 |
| SDK, composants et délais de correctionGuide FSS sur les tiers ; plateforme FSI de la chaîne d'approvisionnement | Identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, d'une version à l'autre. Détails | Identité, version et emplacement de chaque composant, avec recommandations de mise à niveau ou de remplacement et résolution suivie d'une version à l'autre |
| Protection des données sur l'appareil et en transitPIPA art. 29 ; normes PIPC ; loi sur l'information de crédit, art. 19 | Intercepte le trafic de l'application même avec TLS pinning, et recherche les jetons et données personnelles dans le stockage, les caches, les journaux et les captures d'écran. Détails | Preuves sur le système de fichiers et les requêtes montrant ce qui a été écrit ou envoyé, où et quand |
| Conditions de séparation des réseaux et tests on-premisesRèglement, art. 15 ; règles d'application, 20 avril 2026 | Exécute les scans derrière votre pare-feu ou VPN, sur une infrastructure que vous contrôlez, pour que les artefacts et les données de test restent à l'intérieur. Détails | Résultats de scan et journaux conservés dans votre environnement |
| Remédiation, délais et retestsRéunion FSS, 29 juin 2026 | Regroupe les résultats en tickets dans la plateforme ou dans Jira et ServiceNow, et reteste après correction. | Historique des tickets et issue du retest pour chaque résultat |
Ostorlab teste les contrôles de l'application et de ses API. L'évaluation institutionnelle, l'équipe dédiée, la surveillance SOC, la réponse aux incidents et leur signalement, la notification des violations, la gouvernance, les contrats tiers et le reporting au conseil restent du ressort de vos équipes.
Les contrôles coréens à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque des systèmes, fondée sur la loi sur les transactions financières électroniques, le règlement et les critères d'évaluation du FSI.
Périmètre de l'évaluation annuelle
Intégrez l'application mobile et les API qu'elle appelle au périmètre de l'analyse et de l'évaluation des vulnérabilités, avec une fréquence qui couvre le cycle annuel et chaque version.
Examen interne de sécurité
Lancez un test avant publication de l'application et des API qui la sous-tendent pour chaque nouveau service ou changement majeur, et conservez les résultats dans le dossier d'examen.
Intégrité du programme
Vérifiez que l'application détecte les altérations et que le backend contrôle l'intégrité des transactions, pas seulement l'application.
Authentification et verrouillage
Testez la MFA, les codes à usage unique, les parcours d'authentification renforcée et le verrouillage après des échecs répétés avec vos comptes de test.
Composants et délais
Tenez une liste versionnée des SDK et bibliothèques de chaque version, rapprochez-la des vulnérabilités connues et fixez des délais de correction selon la gravité.
Secrets et données sur le téléphone
Recherchez les clés d'API, jetons et données personnelles dans le package, le stockage, les journaux et les captures d'écran, et renouvelez tout identifiant fonctionnel.
Tiers et SaaS
Pour chaque backend de SDK et chaque SaaS de la chaîne de livraison, conservez l'évaluation, le contrat et la trace d'examen, et rapportez l'évaluation semestrielle SaaS au comité de protection de l'information.
Corriger, signaler et retester
Suivez les résultats jusqu'à leur clôture, retestez après correction et conservez l'historique des tickets pour le rapport d'évaluation et le suivi de la FSS.
Une liste indicative, et non un modèle de la FSS ou du FSI. 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 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
- 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.
- Electronic Financial Transactions Act (전자금융거래법)Texte coréen, version en vigueur sur law.go.kr. Article 21 (obligations de sécurité), article 21-2 (CISO), article 21-3 (analyse et évaluation des vulnérabilités de l'infrastructure financière électronique) et article 21-5 (notification des incidents)
- Regulation on Supervision of Electronic Financial Activities (전자금융감독규정)Avis de la FSC n° 2026-29, en vigueur le 15 juillet 2026, texte coréen. Analyse et évaluation des vulnérabilités (37-2), organismes d'évaluation (37-3), déclaration des incidents (37-4), chiffrement des transactions et intégrité des programmes (34), authentification et mots de passe (34-2, 34-3, 19-2), examen interne de sécurité (36), cloud et séparation des réseaux (14-2, 15). Modifié le 5 février 2025 pour passer de règles détaillées à des principes
- 「금융분야 망분리 개선 로드맵」 발표 (Financial sector network separation improvement roadmap)FSC, 13 août 2024, texte coréen. Réforme par étapes pour l'IA générative, le SaaS et les environnements de recherche et développement, et orientation vers un cadre d'autosécurité avec responsabilité sur les résultats
- 4월 20일부터 금융회사는 내부 업무망에서 클라우드 기반 응용소프트웨어(SaaS)를 보다 원활하게 활용할 수 있습니다 (SaaS network separation exception)FSC et FSS, 20 avril 2026, texte coréen. Les règles d'application du règlement modifiées ; les conditions attachées à l'usage du SaaS sur les réseaux de travail internes, et les données qui ne bénéficient d'aucune exception
- 금융보안원, 2026년도 취약점 분석·평가 실시 (FSI, 2026 vulnerability analysis and assessment)Financial Security Institute, 13 février 2026, texte coréen. 178 institutions, critères élargis à 15 domaines et 869 éléments, 73 critères cloud, 288 applications mobiles de 32 entreprises, et la nouvelle équipe de tests d'intrusion
- 금융감독원, 전자금융사고 대응 역량 및 IT복원력 강화를 위한 「금융IT 리스크 대응회의」 개최 (FSS Financial IT Risk Response Meeting)FSS, 29 juin 2026, texte coréen. Cinq points pour prévenir les accidents de financement électronique, dont les contrôles IT de base et l'efficacité de l'analyse et de l'évaluation des vulnérabilités
- 금융회사의 제3자 IT리스크 관리 가이드라인 마련 (Third-party IT risk management guideline)FSS et sept associations professionnelles, 29 juillet 2026, texte coréen. Responsabilité du conseil, structure de contrôle à trois niveaux, tiers clés et cycle de vie des contrats ; normes types des associations à partir de novembre 2026
- 개인정보의 안전성 확보조치 기준 (Standards for ensuring the safety of personal information)Personal Information Protection Commission, avis n° 2026-9, en vigueur le 1er juillet 2026, texte coréen. Mesures techniques et managériales minimales au titre de l'article 29 de la loi sur la protection des données personnelles : autorisations d'accès, contrôle des accès, chiffrement, journaux d'accès, prévention des logiciels malveillants, préparation aux sinistres et contrôles des sorties
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écrivent les règles coréennes
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.