按照 BDDK 与 CBRT 规则，在每次发布前后测试您的 移动银行应用。

1. 01

   BSEBY 第18条第7款；BDDK BSD.2012/1 号通函，范围与方法（土耳其语文本）

   进行年度渗透测试，并将移动应用纳入范围

   文本的内容

   银行必须至少每年让不参与、不负责被测系统所提供服务的设计、开发、实施和运营的团队进行一次渗透测试。BDDK 的渗透测试通函规定了框架：先做基础测试再做详细测试，至少从互联网、银行内网和分行网络实施，最低范围包含 Web 应用和移动应用。发现按通函的严重程度分级并按通函格式报告，资产优先级判断仍由银行负责。

   来源：BSEBY 第18条第7款；BDDK BSD.2012/1 号通函，范围与方法（土耳其语文本）

   对您的移动应用意味着什么

   移动应用是明确列出的测试领域。应用及其调用的 API 与 Web 应用、ATM 系统一起，属于年度测试中面向互联网的部分。

   Ostorlab 如何提供帮助

   AI 智能体渗透测试覆盖商店版本及其登录后的 API，AI 智能体的每个发现都附有可重放的有效漏洞利用和覆盖热图。它不替代通函中的网络、分行网络、ATM 和社交工程部分。

   仍由您负责的部分

   完整年度测试的实施、内网和分行网络部分、资产优先级判断，以及将结果纳入行内流程。

2. 02

   BSEBY 第22条第4款、第5款和第24条

   在发布前和每次更新后测试面向互联网的应用

   文本的内容

   无论是银行自行开发还是从供应商采购，面向互联网的应用都必须在安装前进行安全漏洞扫描和检查，并在每次更新后再次进行。授权与访问、身份核验、数据完整性、日志和异常处理等安全要求，应从开发或采购开始时就确定；变更需经过请求管理、风险评估、测试和批准后才能进入生产环境。

   来源：BSEBY 第22条第4款、第5款和第24条

   对您的移动应用意味着什么

   移动应用的每个新版本都是对面向互联网应用的一次更新。发布前检查和发布后检查是底线，其间进入商店的版本也应被监控。

   Ostorlab 如何提供帮助

   Mobile SAST 无需源代码即可分析 APK、AAB 或 IPA；Mobile DAST 运行应用；两者都可接入 CI/CD。商店版本无需人工触发即可监控，不会漏掉迭代之间发布的更新。

   仍由您负责的部分

   安全编码标准、源代码评审、发布审批，以及要求供应商执行同样测试的合同条款。

3. 03

   BSEBY 第34条第14款、第15款；BDDK 2023/1 号通函附件第1节（土耳其语文本）

   加固应用并检测被攻陷的设备

   文本的内容

   为电子银行提供给客户的软件和移动应用，必须可验证地来自银行，不得包含威胁客户安全的代码，并提供修复漏洞所需的补丁和更新。手机银行应用使用的关键数据必须不能被同一设备上的其他应用和进程访问，在设备丢失或被盗时得到保护，并应以符合当前技术的控制降低设备被夺取、可靠性被破坏、操作系统被破解或替换所带来的风险。2023/1 号通函详细说明了这些控制：应用和 SDK 完整性、防键盘记录、防注入、防调试、防模拟、设备绑定、防恶意软件和越狱检测，并通过独立的安全通道上报到专用安全服务器。

   来源：BSEBY 第34条第14款、第15款；BDDK 2023/1 号通函附件第1节（土耳其语文本）

   对您的移动应用意味着什么

   这是 root、越狱和篡改的领域。检测只是起点：应用必须对检测结果采取行动，而且检查不应能被轻易关闭。

   Ostorlab 如何提供帮助

   Mobile Shielding Scan 在 root、越狱和插桩环境中运行应用，逐一尝试绕过各项防护，并显示应用是阻断流程、拒绝启动还是继续运行，给出加固评分和绕过证据。

   仍由您负责的部分

   防护 SDK 的选型与配置、被攻陷设备的处理策略，以及安全服务器。

4. 04

   BSEBY 第34条第1款、第6款、第9款和第38条第1款

   强制使用两个独立要素并在线核验

   文本的内容

   电子银行服务，包括展示客户数据等不产生财务结果的交易，都要求至少两个来自不同类别的认证要素：客户知道的东西、客户拥有的东西，或生物特征。各要素必须相互独立，拥有的要素必须为客户专属且不可仿冒。客户知道的要素必须由客户输入并在银行侧在线核验，不能由应用或浏览器记忆后自动发送，也不能绑定到本地认证方法。失败次数超限后必须阻断该用户的访问，一次性密码必须足够长以抵抗猜测、随机生成且仅在有限时间内有效。

   来源：BSEBY 第34条第1款、第6款、第9款和第38条第1款

   对您的移动应用意味着什么

   MFA 由服务器强制，而不是由应用在屏幕上画出。锁定阈值、OTP 有效期，以及应用跳步时的行为，都是可以测试的行为。

   Ostorlab 如何提供帮助

   认证测试覆盖登录与退出、令牌刷新、会话超时和 MFA 强制，包括增强验证流程和绕过尝试，使用您的测试账户并覆盖背后的 API 调用。

   仍由您负责的部分

   认证方式的选型、锁定阈值和 OTP 有效期的设定。

5. 05

   BSEBY 第34条第7款、第8款

   让短信一次性验证码远离应用渠道

   文本的内容

   对于已安装并激活手机银行应用的客户，银行不得为登录或会话中的交易验证发送短信一次性密码或验证码，也不得将短信用作认证要素。短信验证码仅允许在应用首次安装、激活、重新激活，或应用无法使用时使用。如果客户更换了 SIM 卡或通过携号转网更换了运营商，银行必须通过与移动运营商的对接进行识别；在变更得到确认之前，90 天内不得使用基于 SIM 卡的要素。

   来源：BSEBY 第34条第7款、第8款

   对您的移动应用意味着什么

   应用需要一条非短信的第二通道。测试还应覆盖例外情况下使用短信时的行为，以及 SIM 变更和重新激活的处理方式。

   Ostorlab 如何提供帮助

   Ostorlab 使用您的测试账户完成短信、邮件或 TOTP 验证码，检测服务器是否仍向已激活应用的客户发送或接受短信验证码，并测试激活、号码变更和增强验证背后的 API 调用。

   仍由您负责的部分

   运营商对接、SIM 变更确认流程和客户告知。

6. 06

   BSEBY 第35条、第38条第3款；BDDK 2023/1 号通函附件第1节和第2节（土耳其语文本）

   对交易签名，让客户批准所看到的内容

   文本的内容

   电子银行交易必须具备不可否认性和责任归属能力。系统生成一次性验证码，并用分配给客户的私钥签名；验证码不得泄露任何认证要素，不得由已知验证码推导，也不得被仿造；对于产生财务结果的交易，验证码必须与客户批准的金额和收款人绑定，任一项变化即失效。2023/1 号通函说明了实现方式：专用 SDK 与银行安全服务器；客户密钥生成并保存在手机密码学硬件中（如 Secure Enclave、硬件支持的密钥库或 Strong Box）；在与应用常规后端流量分离的通道上使用双向 TLS；每次签名请求前执行安全检查。

   来源：BSEBY 第35条、第38条第3款；BDDK 2023/1 号通函附件第1节和第2节（土耳其语文本）

   对您的移动应用意味着什么

   所见即所签是后端属性，但可能在应用侧失效：覆盖层、注入代码或被操纵的界面，会改变客户以为自己在批准的内容。

   Ostorlab 如何提供帮助

   Ostorlab 测试应用展示和签署交易的方式，包括验证码显示后金额或收款人发生变化时的行为、验证码能否被重放或推导，以及签名流程周边的 API 调用。

   仍由您负责的部分

   安全服务器、密钥生命周期、交易模板和不可否认性记录。

7. 07

   UKTY（《银行远程身份核验方法条例》）第4条、第6条、第7条、第8条、第10条和第11条

   把远程开户当作受控流程来运行

   文本的内容

   远程身份核验由受过培训的客户代表与本人通过实时、不中断的视频通话完成。身份证件尽可能通过 NFC 核验，其安全要素、照片和签名在白光下检查，整个过程被录制以便审计。系统使用活体检测并采取额外措施防范伪造人脸技术，将本人面部与证件照片比对，出现任何疑点即终止流程。仅可使用生物识别数据这类特殊类别个人数据，并以电子方式记录本人的明确同意。流程上线前经过测试，且至少每年复查两次；责任仍在银行，远程获取的客户适用额外的安全措施。

   来源：UKTY（《银行远程身份核验方法条例》）第4条、第6条、第7条、第8条、第10条和第11条

   对您的移动应用意味着什么

   开户流程风险很高：涉及摄像头、NFC、生物识别和实时后端。它也是攻击者最先尝试的流程，会用上伪造人脸、模拟器和中间人拦截。

   Ostorlab 如何提供帮助

   Ostorlab 测试开户 API 和应用侧检查：在模拟器或 root 设备上的行为、活体检测能否被录像或合成人脸欺骗、会话如何保护，以及客户端如何存储身份要素。

   仍由您负责的部分

   客户代表流程、视频平台、证件核验判断、留存期限和监管报备。

8. 08

   KVKK 第6698号法第4条和第12条；KVKK《移动应用中隐私保护建议》，2025年3月（土耳其语文本）

   在手机上履行 KVKK 的安全义务

   文本的内容

   根据第6698号《个人数据保护法》，数据控制者必须采取一切必要的技术和组织措施，防止个人数据被非法处理和非法访问，并开展必要的审计。个人数据被他人非法获取时，数据控制者必须告知数据主体，并尽快通知委员会。KVKK 在2025年更新的移动应用建议中，要求落实隐私保护和默认隐私、对传输中和存储中的个人数据加密、对密码进行哈希处理、定期进行补丁管理和软件更新、发布前完成软件测试、限制登录失败次数，并让用户控制权限、通知和隐私设置。

   来源：KVKK 第6698号法第4条和第12条；KVKK《移动应用中隐私保护建议》，2025年3月（土耳其语文本）

   对您的移动应用意味着什么

   KVKK 义务关注应用收集什么、如何保护。权限、SDK 数据流、本地存储、日志和截图正是被测试的地方。

   Ostorlab 如何提供帮助

   Ostorlab 盘点构建包中的 SDK，梳理它们可以访问的范围，并检查存储、缓存、日志和截图中是否存在个人数据和令牌，同时检查传输保护并报告暴露内容和位置。

   仍由您负责的部分

   数据分类、法律依据、同意记录、留存期限和违规通知。

9. 09

   BSEBY 第16条；CBRT《支付机构和电子货币机构信息系统 Tebliğ》第12条（土耳其语文本）

   为漏洞管理设定修复期限

   文本的内容

   银行必须运行漏洞与补丁管理流程：跟踪漏洞信息、评估影响、确定修复方法和期限、保留记录，并在无法打补丁时设置补偿性控制。自动漏洞扫描工具将最关键的发现按优先级报告给信息安全负责人和受影响系统的负责人。对支付机构和电子货币机构，CBRT 的 Tebliğ 要求更具体：服务器和通信网络每年至少扫描六次并在首次投用前扫描，至少每年由持有国内或国际渗透测试资质、且不参与被测系统安全的人员或公司进行一次渗透测试。发现须在董事会批准的行动计划下尽快修复，并至少每年向 CBRT 提交涵盖安全事件、测试结果和关键漏洞的报告。

   来源：BSEBY 第16条；CBRT《支付机构和电子货币机构信息系统 Tebliğ》第12条（土耳其语文本）

   对您的移动应用意味着什么

   这里交汇了两种期限文化：BSEBY 下银行自定的补丁期限，以及 CBRT 对支付机构要求的每年六次扫描和一次年度测试。两者都需要可追溯的修复与复测闭环。

   Ostorlab 如何提供帮助

   发现按严重、高、中、低评级，归入平台或 Jira、ServiceNow 工单，关联到受影响的组件和版本，并在修复发布后复测。历史记录可用于行动计划与年度报告。

   仍由您负责的部分

   服务器和网络设备的补丁、董事会批准的行动计划，以及向 CBRT 的报送。

本页概述 BDDK、CBRT 和 KVKK 的公开文本，核对日期为2026年9月27日。BSEBY 条文依据 BDDK 的英文译本，另有注明（土耳其语文本）的除外；2023/1 号通函、2012年渗透测试通函和 CBRT Tebliğ 依据土耳其语文本概括。本页不构成法律意见。