已发布的 npm 包中的机密信息与代码仓库中的机密信息属于不同的集合。机密扫描器会读取整个 Git 树；而 npm pack 仅打包 package.json 中 files 允许列表内的文件。leak_probe.py 会对两者进行测量并打印出差异。在下面的测试用例中，它发现了 6 个命中项，并标记其中 3 个为实际会被打包发布。
太长不看版
- 扫描器读取的是你的 Git 树。打包器读取的是
files允许列表。它们所涵盖的文件集合并不相同。 - 在该测试包中：总共发现 6 个机密命中项，其中 3 个会被打包进 tar 包，另外 3 个仅存在于 Git 中（一个位于
test/目录下的伪造文件和一个根目录下的run.log，两者均不在files允许列表内）。程序退出码为 1。 -
leak_probe.py是一个约 80 行的 Python 脚本：包含提供商正则表达式、熵值计算以及一个打包过滤器。无需网络连接，无需模型，无需执行外部命令，也无需安装额外依赖。 - 命中项仅是一个信号，而非确认有效的活跃机密。请使用
npm pack --dry-run验证其打包状态。 - 运行时间约为 60 秒，无需 API 密钥。代码和测试用例均在文中提供。
无人扫描的盲区
运行 gitleaks 或 trufflehog 会得到工作树中的机密信息列表。这很有用。但该列表回答的是关于你代码仓库的问题，而非关于你发布版本的问题。推送到 npm 的内容取决于 npm pack 决定包含哪些文件，而 npm pack 有其自身的规则：files 数组是一个允许列表，.npmignore 从剩余文件中排除特定文件，此外少数文件（如 package.json、README.md）总是会被打包发布。
因此，两种失败模式隐藏在这一差异之中。
第一种：扫描器大声警告并用红色标记的机密信息位于 test/fixtures.js 中，该文件不在你的 files 允许列表中，因此永远不会被发布。你却花了一个下午轮换一个根本不会离开你笔记本电脑的密钥。
第二种，也是更糟糕的一种：src/ 目录中的一个机密信息被你的团队归类为“低优先级，只是个占位符”，结果却随着公共 tar 包发布给了每一个安装者。扫描器看到了它。风险评估降低了它的优先级。但打包器依然将其发布了出去。
我本人从未将泄露的密钥推送到 npm。但这种情况并非理论推测。GitGuardian 发布的《2026 年机密信息蔓延状态报告》（2026 年 3 月 17 日发布）指出，由 Claude Code 辅助提交的代码中，机密信息泄露率为 3.2%，而所有公共 GitHub 提交的基准泄露率为 1.5%，并且2025 年人工智能服务相关的机密信息数量达到 1,275,105 条，同比增长 81%（blog.gitguardian.com）。他们的头条数据是：2025 年新增至公共 GitHub 的硬编码机密信息达 2865 万条。这些是 GitGuardian 对 Git 历史的测量数据，而非我的数据，且他们统计的是提交记录，而非已发布的包。我引用这些数据是为了提供背景，而非作为我的结果。我要提出的观点更为狭窄，且由我亲自测量：即使扫描器发现了机密信息，“被发现”和“被发布”也是两个不同的集合。
反直觉的观点，陈述于此供你反驳
以下是这一主张，表述得足够尖锐以便争论：在你的代码仓库上运行机密扫描器并不能告诉你哪些内容会被发布。 一个被扫描器标记的机密信息可能永远不会离开你的机器。而一个被扫描器降低优先级的机密信息却可能发布给每一个安装者。
这一主张是可以被证伪的，我也希望如此。基本事实依据是 免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。npm pack --dry-run，它会列出 tar 包中的确切文件。如果该集合始终等于你的 Git 树，那么该主张即为错误，leak_probe.py 也将毫无意义。在下面的测试用例中，这两个集合存在差异：Git 树中有 6 个命中项，而 tar 包中只有 3 个。运行 npm pack --dry-run
