先确认标准的适用范围
讨论央行数字钱包测试标准有哪些风险检查要点，首先要区分正式规范、通用框架和工程检查思路。具体项目的合格条件，需要由适用的监管要求、业务规则及技术规范共同确定，不能仅凭通用安全文档作出判断。
NIST SP 800-218介绍的安全软件开发框架（SSDF），强调把安全实践融入软件开发生命周期，以减少漏洞、降低漏洞被利用的影响并处理根本原因。它可作为软件安全管理参考，但所列摘要不能证明央行数字钱包必须执行某套具体测试。中国人民银行新闻栏目正文没有列出数字钱包测试条款，因此不能据此确认专用标准或验收门槛。
软件安全检查应贯穿开发过程
按照上述框架的通用思路，检查不宜只集中在上线前。需求阶段应明确需要保护的资产和安全目标；开发与发布阶段关注代码、依赖组件和交付过程中的漏洞风险；发现问题后，还应验证修复效果并分析成因。以下检查方向属于通用工程解释，不代表某个央行项目已经采用的标准条款。
身份、权限与数据保护
对于包含登录、设备绑定或账户恢复功能的钱包，可检查身份校验能否被绕过、失效会话是否仍可使用，以及不同身份能否越权访问数据或执行操作。账户恢复也应纳入检查，避免正常入口受到保护，恢复入口却存在薄弱环节。
数据保护检查可覆盖存储、传输、日志和备份，关注敏感信息是否出现非必要暴露，以及密钥等关键材料的访问权限是否受到控制。测试范围应随钱包形态和系统职责调整，不能假定全部安全能力都由客户端承担。
支付状态与异常恢复
对于承担支付处理的钱包系统，通用检查问题包括：重复请求是否造成重复处理，网络中断后状态是否可核对，并发操作是否破坏业务规则，以及失败后的恢复是否保持记录一致。若支持离线支付，还需另行明确离线条件下的风险控制与重新联网后的核验要求；不能默认所有钱包都支持该功能。
常见问题与验收证据
通过漏洞扫描是否就代表测试合格？扫描只能覆盖部分问题，业务逻辑、权限边界和异常恢复仍需相应验证。采用SSDF是否等于获得央行认证？该框架的通用开发建议不能单独支持这一结论。
可复核的测试记录应说明依据的规范版本、适用功能、测试条件、预期结果、实际结果及缺陷修复情况。没有明确条款支持时，不宜自行设定统一性能门槛，也不宜把某次测试通过扩大解释为钱包整体安全获得保证。