StepSecurity 在合法的 kilocode npm 版本中检测到早期供应链风险信号，展示了微小的行为变化如何在攻击发生前悄然削弱信任
供应链安全故事通常聚焦于已确认的入侵事件。但许多真实的风险在更早阶段就已经开始——通过微小而合法的改动，悄然削弱信任。
这篇文章讲述的是一个有效的 npm 版本如何引入了降低已建立信任信号的行为变化，这些变化如何被早期检测到，以及为何这类信号对维护者和使用者都很重要。
我们观察到的情况
1 月 29 日，StepSecurity 的监控标记了 @kilocode/cli 的一个新 npm 版本，与之前的版本在几个重要方面存在差异。
该版本显示：
- 缺失 npm 来源证明（provenance attestations），尽管早期版本包含这些证明。发布流水线已迁移到新仓库，来源证明未能延续。
- 新引入的 postinstall 脚本。该脚本执行操作系统和架构检测，并创建指向平台特定二进制文件的符号链接，如 @kilocode/cli-darwin-arm64。这些二进制文件未使用校验和或签名进行验证。
这些变化之所以引人注目，是因为它们改变了包的构建、发布和安装执行方式。
该版本是合法的。我们提交了一个 GitHub issue 来标记风险信号，维护者响应迅速并修复了问题。
您可以在此处查看完整讨论：https://github.com/Kilo-Org/kilocode/issues/5547
这是一个积极的结果，也是维护者积极参与安全反馈的很好案例。
为什么这很有趣
该版本重要性的原因与恶意意图无关。它重要是因为它改变了信任假设。
预安装脚本是高风险执行点
预安装脚本在开发者机器上以用户权限自动运行。这使其成为一个强大而敏感的机制。
近期的攻击活动（包括 Shai-Hulud）滥用预安装脚本来获得初步立足点，例如：
- 投放恶意二进制文件
- 执行 shell 命令
- 窃取凭据
因此，引入新的预安装脚本是一个有意义的行为变化，即使目的是便利性或平台支持。
当二进制文件在安装时被获取或链接时，使用校验和或签名验证其完整性至关重要。
在常规流水线变更期间来源证明可能丢失
迁移发布流水线或更改仓库是常见且通常必要的操作。
容易被忽视的是在该过渡期间来源证明（provenance attestations）的静默丢失。
来源证明提供了关于包在哪里以及如何构建和发布的密码学证明。当它消失时，使用者失去一个重要的信任信号，即使包的功能可能完全如预期般正常运行。
没有东西被破坏，但信任被削弱了。
供应链问题通常始于有效版本
许多高影响的供应链攻击并非从明显的恶意代码开始。
它们始于引入新行为、新执行路径或新信任假设的合法版本。
到了恶意软件出现时，早期干预的机会通常已经消失。
这就是为什么检测行为变化很重要。
这是如何被检测到的
该信号由 StepSecurity 的智能包分析平台识别，该平台实时持续评估 npm 包和版本。
系统评估了：
- 与先前版本相比的发布行为变化
- 之前存在的来源证明的缺失
- 安装时执行路径的引入
- 无完整性验证的二进制文件处理
这类分析聚焦于偏差和风险信号，而非仅仅确认的事件。
我们的目标是在这些信号还有时间响应和修复问题、避免升级的早期阶段将它们浮现出来。
npm 维护者的最佳实践
如果您维护 npm 包，尤其是广泛使用的 CLI 工具，一些实践可以显著提升信任：
- 在所有版本中保留来源证明。即使更改仓库或 CI 流水线，也要确保来源证明保持完整。
- 将预安装脚本作为最后手段。如果必须使用它们，请保持逻辑最小化和透明。
- 验证安装期间使用的所有二进制文件。使用校验和或签名确保完整性。
- 假设使用者正在监控行为变化。清晰的文档和一致性建立长期信任。