该论文聚焦一个长期被忽视的防护缺口：部署前的密钥扫描只作用于源代码仓库，而从不检查生产应用实际向浏览器下发的资源。作者在一次获得授权的评估中审计了某组织约 2,000 个企业级 Web 资产，发现其中 113 个（5.65%）在生产 JavaScript 打包文件中直接下发仍然有效的凭证，包括 Azure AD 客户端凭证与 API 管理（APIM）订阅密钥；这些凭证被证实可用于账户接管和大规模数据暴露，形成了完整的两条利用链。为量化“左移扫描”与真实运行态之间的差距，作者构建了独立的 Ground Truth 集合 GT-194，包含 194 条真实可用的密钥级凭证，构建流程为 Claude Opus 4.7 自动抽取加人工分析师复核，并由 GPT-5.5 对 247 条 LLM 抽取候选做独立校验（Brennan-Prediger kappa = 0.676）。核心发现具有结构性：GT-194 中有 13.9%（27/194）只能通过人工分析发现，所评估的九款生产级扫描器无一能够检出，属于与工具无关的系统性盲区；此外，采用 CryptoJS 加密的配置项可击败所有静态扫描器，因为凭证只有在与密钥同址存放并被运行时解密后才存在，只有具备运行时感知能力的检测才能触达。九款扫描器合计覆盖率仅停留在 86.1%，其中最佳静态扫描器召回 36.6%，最佳运行时感知扫描器为 77.8%（F1 = 0.818，McNemar p < 0.001）。研究还指出，在 86 个暴露密钥的应用中有 63 个（73.3%）其完整的 Azure AD 令牌签发链条与凭证同处一个打包文件，可从浏览器侧代码直接触达。作者归纳了凭证绕过检测进入生产环境的五条路径，并提出分层运行时检测方法论与修复框架。局限性在于召回率结论仅适用于单一组织的 Azure 重度依赖语料。