前言¶
支付、清结算、绑卡鉴权类项目里，很多问题不会在功能测试阶段暴露：表结构里多留了 CVV、日志里打了完整卡号、留存策略写成 1825 天、测试配置却指向生产库。等监管或内审追问时，往往要对着历史提交和配置逐项解释。
通用敏感数据扫描能发现「像卡号、像手机号」的字符串，但很难对齐金融行业对支付敏感信息不得留存、反洗钱相关记录十年留存、传输与环境隔离等专门要求。feely0208/dsh-industry-finance（npm 包名 @deepwhale-cn/dsh-industry-finance）是 DeepSeek Harness（DSH）生态里面向 admin-security 的行业专项插件：在代码与配置层面，用 7 条静态判据把上述线索先筛一遍，并附上规范条款出处，供人工确认。
这是什么、不是什么¶
维护者 feely0208，仓库 github.com/feely0208/dsh-industry-finance，当前资料中的版本为 0.1.1（MIT 许可证）。社区目录页见 skillhub.cn/plugins/feely0208/dsh-industry-finance。
是：静态线索检查器。扫描内置 rules/ 中的判据，对可疑字段名、DDL、日志与模板插值、留存配置、传输配置、环境配置等给出位置与依据，提示「去确认」。
不是：
- 不是合规审计，不做数据流分析、接口画像或制度流程核查。
- 不是「合规通过」证明；零命中仅表示未扫到静态线索。
- 不是自动改代码的工具，只报告位置。
- 不是 PCI DSS 扫描器；依据以中国金融行业规范与支付相关条例为主。
七条判据在查什么¶
全部围绕「支付敏感信息 + 十年留存 + 传输/环境隔离」：
| 级别 | 规则 ID | 关注点 |
|---|---|---|
| 高 | FIN-PAY-SENSITIVE-RETENTION |
cvv、cvn、track1/2、magnetic_stripe、card_pwd、pay_pwd 等支付敏感信息被字段/模型/配置留存 |
| 高 | FIN-AUTH-PLAINTEXT |
口令、PIN、短信验证码明文落库、写日志或 System.out 打印 |
| 中 | FIN-PAN-DISPLAY |
模板/日志中 ${cardNo}、{{cardNo}} 等直接插值，未走 mask/substring/脱敏工具 |
| 高 | FIN-AMC-10Y |
留存配置短于 3650 天、INTERVAL 小于十年、分区清理短于十年 |
| 高 | FIN-CLIENT-LOCAL-STORE |
客户端将卡号/CVV/口令写入 SharedPreferences、MMKV、UserDefaults、localStorage 等 |
| 中 | FIN-TRANSPORT-PLAINTEXT |
useSSL=false、sslMode=DISABLED、verifyServerCertificate=false、支付/鉴权链路 http:///ftp://、TLSv1.0 等 |
| 中 | FIN-TESTENV-PROD-DATA |
application-test/dev/uat/sit 指向 prod/生产，或 profiles.active=prod，且同文件无脱敏开关 |
判据出处写在各规则 JSON 的 source 字段中；命令行可用 --list-rules 查看完整列表。资料中引用的规范包括《个人金融信息保护技术规范》（JR/T 0171—2020）、《非银行支付机构监督管理条例》（国令第768号）、《银行保险机构数据安全管理办法》（金规〔2024〕24号）、《中华人民共和国反洗钱法》（2024 修订）等相关条款。工具输出的是线索与出处，不展开法条解释。
如何降低误报¶
高风险规则带 when 条件：项目里没有支付/卡/客户端相关代码时，规则进入 notApplicable，报告中会说明有多少条因不适用未运行。
常见边界写法会被排除，例如：card_mask / card_token 不算支付敏感信息留存；同行出现 passwordEncoder、bcrypt、PBKDF2、SM3、SHA-256 的口令列不报；模板已调用 substring、mask、DesensitizedUtil 的卡号不报；测试配置含 desensitize / 脱敏 开关时不报测试连生产等。具体例外以仓库 rules/ 实现为准。
安装与启用¶
资料中的安装方式如下。DSH 要求 dsh 版本在 >=0.1.0-rc.6 <0.3.0，Node.js >=18。
dsh plugin --profile web add @deepwhale-cn/dsh-industry-finance
纯 CLI、不经过 DSH 进程时：
npx @deepwhale-cn/dsh-industry-finance
安装前建议阅读仓库源码与 MIT 许可证；插件以当前 dsh 进程权限扫描指定目录，只应在可信环境中对自有或已授权代码运行。
典型用法¶
先做演示或列规则，再对目标仓库跑检查：
dsh-industry-finance --demo # 查看检出效果
dsh-industry-finance --list-rules # 列出判据与依据
dsh-industry-finance --root ./my-app # 检查指定项目
dsh-industry-finance --html r.html # 生成 HTML 报告
--root 指向待检应用根目录；HTML 报告便于归档或评审截图。
边界与其它插件¶
能力边界（README 原文要点）：
- 仅静态线索，不做运行时抓包、不读库内真实数据。
- 不做「缺项」判定：没有留存配置不代表未由 DBA/归档平台统一满足十年要求。
- 不判断加密强度；明文与明文通道迹象以外的密钥与算法，可配合
dsh-cn-crypto等插件。
分工（同系列说明）：dsh-data-scan 覆盖通用敏感数据；dsh-data-lifecycle 覆盖通用留存；dsh-cn-log-retention 针对网络日志六个月留存，与交易类十年留存是不同条线；dsh-industry-medical、dsh-industry-education 为其它行业层，与金融层不重叠。需要编排多插件时，可参考维护者「深鲸网安守护」系列在 dsh-plugin.org、npm 上的配套插件。
结尾¶
dsh-industry-finance 把金融支付里七类高发静态风险（敏感信息留存、口令明文、卡号裸展示、留存不足十年、客户端本地存卡、明文传输、测试环境连生产）收敛到可复现的命令行检查，适合在 CI、改表结构或改配置前做一轮线索扫描。结论需人工核对业务与制度，不能替代正式合规审计。
