边界变异测试：密钥扫描器在凭据边界处会漏报

当天发生了什么

2026-09-02（UTC），Shweta Mishra 在 arXiv 提交了论文《Boundary-Mutation Testing for Pattern-Based Secret Detection》的 v1。作者指出，基于正则的密钥扫描器通常只用固定样例测试，而这些样例只改变凭据周围的文本。论文的方法是：按每条规则自己的正则生成凭据，放进真实的源码上下文，并按规则而非按工具统计结果。论文评估了一个 43 条规则的开源扫描器、Gitleaks 8.21.2 和 TruffleHog 3.82.13。在主要研究对象上，十种上下文下检出率接近完美，但当凭据以连字符结尾时降到 0.5233，涉及五条规则；其中两条使用固定次数量词的规则完全且确定地失败。作者还报告，一个看似合理的首次修复悄悄破坏了另外两条规则，只有重跑完整测试才发现。论文称 Gitleaks 有一个经源码确认的缺陷，TruffleHog 无边界脆弱性但覆盖最窄；各工具召回率差异均未达到统计显著。

对保护应用逻辑的人意味着什么

很多团队把“扫描器没报”当作“安装包里没有密钥”的证据。这篇论文说明，扫描结果只能证明在被测试过的规则和上下文下没有发现问题。对客户端应用而言，漏报的后果更直接：字符串会原样进入 APK、IPA 或 asar，混淆通常不会让它消失。需要诚实说明的是，论文测试的是特定旧版本，当前版本的表现可能不同，也不能据此给扫描器排名——作者本人报告的是零结果。真正的启示在流程上：扫描器是一道有盲区的检查，而不是保证；修改规则同样是一次可能引入回归的变更。

可以做的检查

第一，除了扫描源码仓库，也扫描构建产物：解包后的 APK、IPA、asar 或桌面安装目录，因为构建步骤可能注入配置。第二，考虑并行使用不止一款扫描器，并记录各自版本。第三，在测试分支中放入格式边界各异的无效测试凭据，确认你的规则组合能检出；自定义规则改动后重跑全部用例。第四，一旦发现真实密钥进入过发布物，先吊销并轮换，再讨论如何隐藏。第五，能放到服务端的凭据不要随客户端分发。

行动清单

• 扫描解包后的发布产物，而不只是源码
• 用边界格式各异的无效测试凭据验证规则组合
• 修改规则后全量回归；真实泄露先吊销轮换