一个字符的错误导致恶意软件传播
事情始于一个拼写错误。在功能推送和 PR 合并的海量热潮中，有人输入了 @utils_core 而不是 @utils-核心 到 的package.json那个单字符错误并没有引发错误。相反，它悄悄地拉进了一个 恶意相似包在下一个 CI/CD 运行，利用对固定版本和自动化的信任。 欢迎来到开源域名抢注的世界。
域名抢注：利用人为错误滋生的攻击媒介
域名抢注顾名思义就是恶意行为者注册与合法软件包名称几乎相同的软件包。在快节奏的环境中，这种方法之所以有效，是因为开发人员相信他们的 的package.json 以及 包lock.json 反映他们的期望。少了一个字符？在 PR diff 中可能看不到它。
NPM 曾被域名抢注者利用。类似 交叉环境 而不是 跨环境 or 事件流 后门程序已经证明了这些仿制品的有效性。这些伪造的软件包通常能够通过审核，仅仅是因为它们看起来没问题，而且不会立即抛出运行时错误。
常见的陷阱包括：
- 连字符与下划线： lodash核心 vs lodash_core
- 复数： 请求 vs 要求
- 替换的字符： 快递 而不是 特快
package-lock.json 的盲点
开发人员修复了他们的拼写错误。或者他们以为是这样。但是现在， 包lock.json 已经锁定了攻击者的包裹。真正的风险就隐藏在这里。
不比 的package.json，并经过手动编辑和更严格的审查， 包lock.json 由自动生成 NPM因此，它常常被视为一种形式，被跳过，或只是略过 pull request 评论。团队将其标记为“太嘈杂”或不深入研究就默认信任它的情况并不少见。
攻击者知道这一点。他们依赖它。一旦 恶意包 被引用，由于拼写错误 package.json、package-lock.json 记录已解析的版本。即使之后拼写错误被纠正，恶意条目仍会持续存在，除非明确重新生成锁文件。
更糟糕的是，版本锁定本应确保一致性，但却可能适得其反。攻击者可以将伪造的软件包版本设置为与合法软件包完全相同。如果 CI/CD 系统盲目信任固定版本，它不会检测到它正在安装具有已知良好版本号但来自不同恶意来源的软件包。
正是这种默默的坚持，才使得 包lock.json 太危险了。它确实确保了确定性的构建，但它也意味着除非手动捕获并清理，否则坏包会一直存在。
CI/CD：恶意软件攻击的位置 – package.json
在一个典型的 CI/CD pipeline，恶意程序包无需等到运行时。它在流程中更早地得到解析和触发：
依赖解析
此 pipeline 从 p 中提取精确的依赖版本包-锁.json，现在包括 由于拼写错误导致的域名抢注 包.json。
安装阶段
在 npm ci 运行期间，所有依赖项都会安装，包括恶意依赖项。没有警告，没有提示，只是静默安装。
安装后脚本执行
类似软件包包含一个安装后脚本，该脚本会在安装完成后自动运行。这就是入侵发生的地方。
伪代码示例：
if (installation_phase_active) {
runHiddenPayload()
}伪代码描述：
在安装阶段，如果存在安装后生命周期钩子，伪造软件包就会触发其隐藏逻辑——通常在构建或测试运行之前。这可能涉及发出外部请求、注入后门或其他未经授权的操作。
⚠️ 警告：此伪代码仅用于演示目的，不得在实际环境中使用。
没有触发任何警报。没有任何故障。环境已经受到威胁，在你 pipeline 甚至达到测试阶段。
及早发现差异
一个常见的错误：假设 的package.json 讲述了整个故事。它没有。真正的力量在于 包.json + 包-lock.json。
这是寻找的东西：
- 是否 包lock.json 包括意外的包裹吗？
- 是否有任何依赖项来自未知的注册表或具有奇怪的范围？
- 版本号是否过于具体或者不一致？
使用如下 CLI 工具：
- npm审计 标记已知问题
- npm ls 查看完整的依赖关系树
- 差异 比较版本 的package.json 以及 包lock.json
强化你的 Pipeline：有效的防御
防范域名抢注：
- 强制执行范围限制 包.json。
- 添加预合并 hooks 检查并验证依赖关系。
- 绝大部分储备使用 国家管理委员会 以避免无意的版本漂移。
- 定期扫描 包lock.json 寻找异常。
最重要的是：将未经验证的条目 包lock.json 视为潜在风险。每个 commit 应被视为供应链检查点。
自动检测：Xygeni 等工具如何提供帮助
虽然这不是灵丹妙药，但自动化工具 西吉尼 在减少域名抢注猖獗的人为错误因素方面发挥着关键作用。Xygeni 可直接集成到您的 DevOps 工作流程中，在依赖劫持执行之前添加一层实时保护，防止其被劫持。
Xygeni 的帮助如下：
- 可疑包名称检测：
使用智能启发式方法来检测域名抢注模式 的package.json，寻找知名软件包名称中的细微变化（例如添加下划线、转置或字母交换）。 - 未知哈希验证：
比较每个依赖项的哈希值 包lock.json 针对来自受信任注册中心的已知良好工件数据库进行检查。即使软件包名称和版本看起来没有问题，哈希值不匹配也会引起警觉。 - 构建前的阻塞：
在安装或安装后阶段之前拦截并阻止任何未经验证或可疑的软件包的安装 CI/CD pipeline. - 依赖图分析：
持续检查完整的依赖树，以查找间接的域名抢注尝试或恶意的传递依赖关系。 - 警报和报告：
提供详细、可操作的警报，显示标记的内容、原因以及依赖链中的来源。
随着软件包生态系统变得越来越复杂，像 Xygeni 这样的工具变得至关重要。手动审查无法随着依赖项的蔓延或快速迭代而扩展。Xygeni 介入，将现代的关键检查自动化 pipeline的需求，缩小信任与验证之间的差距。
一个角色。真正的后果。
这不是什么奇特的事情 零日。这是拼写错误。 的package.json，默默地强化了 包lock.json恶意软件在例行程序中自动发送 CI/CD 运行。
这就是域名抢注的真正危险之处：它不需要复杂性。它利用的是速度、信任和自动化。 如果采取正确的控制措施，这种妥协是可以避免的：
- 自动扫描 在安装之前捕获可疑的包名称和版本。
- 锁文件审计 检测未审核或意外的条目 包lock.json.
- 名称验证启发式 标记与可信包近似匹配的包。
一个字符就够了。正确的检查应该可以在它接触到你的 pipeline信任是不够的。在现代 DevSecOps 中，你必须验证一切，否则就会承担一切风险。
