沙丘 》的粉丝们一定知道 "沙伊-胡卢德 "这个名字，它是一种巨大的沙虫，以其不可阻挡的力量重塑了沙漠。现在，开源社区也面临着同样可怕的网络威胁。9 月 15 日，开源软件社区遭遇了迄今为止最具破坏性的危机之一：一种名为 "Shai-Hulud"的自我复制蠕虫病毒在 npm 生态系统中传播，数小时内就入侵了 180 多个软件包。
可信图书馆，如 @ctrl/tinycolor, crowdstrike-nodejs, string-kit, json-sugar, photon-colors 的分叉 typed.js 和 日期和时间 已经受到影响。随着每周数百万次的下载，企业在不知不觉中将活跃的感染病毒直接引入其构建管道。
该蠕虫利用 npm 生命周期钩子窃取 GitHub 和公共云凭证，然后利用这些机密向其他项目发布中毒更新。
攻击流程
- 一个被破解的
@ctrl/tinycolor注入本地恶意脚本 (bundle.js)。 - bundle.js 脚本会下载并执行 TruffleHog，扫描受害者机器上的 GitHub 秘密。
- 脚本会使用发现的 GitHub 秘密，枚举可访问的软件源（所有者、协作者或组织成员）。
- 对于每个版本库，它都会获取默认分支，创建一个
谢赫鲁德分支，并将工作流文件上传到.github/workflows/shai-hulud-workflow.yml. - 工作流被配置为在推送事件发生时触发。GitHub Actions 运行程序在存储库上下文中执行作业，存储库可以访问机密。
- 该工作流读取 GitHub 秘密并将其外泄到攻击者控制的端点。
为什么这对当前和长远都很重要？
开放源代码的设计是开放的。npm 注册表每月提供数千亿次下载，任何人都可以发布软件包。这种开放性推动了创新，但也为攻击者大规模利用信任创造了机会。
疫情的爆发让一个事实无法回避：信任不是永恒的。今天安全的包裹，明天就可能受到损害。
建议：指定准确的依赖版本
我们强烈建议开发人员避免自动安装最新版本。取而代之的是，定义要安装的特定版本，并在验证后手动审查和升级到更新的版本。
用 >= 或 * 声明的依赖关系可能会引入意外更新，包括受损版本。请指定一个精确的、经过审核的版本：
"dependencies": {
"lodash": "4.17.0"
}
只有在验证新版本的真实性和安全性后，才能进行升级。
现在与未来：平衡自动化与人工干预
| 现在立即响应 | 下一页下一篇： 长期复原力 |
|---|---|
| 自动化： 使用多个引擎审核 npm 依赖关系并扫描人工制品。 人类 开发人员会暂停盲安装，并手动确认依赖源。 | 自动化： 在每个流水线中嵌入持续的 SBOM 验证和恶意软件扫描。 人类 安全团队定期审查高风险软件包，并在出现异常时上报。 |
| 自动化： 撤销和轮换已暴露的机密。 人类 安全团队评估可疑的凭证使用情况，并决定遏制步骤。 | 自动化： 执行自动轮换策略和最小权限默认设置。 人类 高管制定治理标准，确保供应链信任的问责制。 |
| 自动化： 在 CI/CD 中执行 MFA 和签名检查。 人类 领导者决定何时放慢交付速度，以保护诚信。 | 自动化： 要求所有版本都要有签名提交和可验证的构建出处。 人类 董事会将软件信任作为一个战略弹性问题，而不是一个合规性复选框。 |
大局观
对于企业高管来说，这次攻击提醒他们，软件供应链风险就是企业风险。监管机构希望有可验证的控制措施，客户希望有诚信的证明。董事会再也不能推卸为关键业务提供动力的代码的责任了。
对于从业人员来说，这次疫情表明管道必须不断发展。在证明安全之前，每个开源依赖都应被视为不可信任的。SBOM、恶意软件扫描和消毒提供了基线，但人的意识--暂停、质疑、升级--是防止盲目自动化导入下一个蠕虫病毒的关键。
OPSWAT的观点
建立Supply Chain 信任
针对 npm 等开源环境的供应链攻击等事件证明，软件供应链现已成为关键工作负载。业界必须从盲目信任转向可验证的信任。
在OPSWAT，我们相信供应链信任必须建立，而不是假设。我们的方法侧重于纵深防御：
- 通过 SBOM 集成实现全面的软件供应链可视性，以跟踪每个软件组件、识别漏洞、在整个 SDLC 中管理风险，并在每个阶段验证出处。
- 使用 30 多个引擎进行Multiscanning ，以捕获软件包中的Multiscanning 恶意软件和其他恶意软件，尤其是第三方开源软件。
- CDR（内容解除和重构）可在恶意有效载荷执行前将其解除。
- Secure 存储和传输控制，可跨 CI/CD 管道执行信任边界。
- 这些控制措施不仅能检测风险，还能主动清除文件并加强信任，从而降低类似事件向下游蔓延的几率。
快速开发和强大的安全性并不相互排斥。开发团队需要在软件供应链中内置自动扫描和审批工作流，这样他们就能在不降低速度的情况下保护代码。
与时俱进的安全性
借助OPSWAT，安全性可直接集成到现有工作流程中：
- CI/CD 管道集成- 在 Jenkins、GitHub Actions、GitLab 和其他构建环境中自动扫描和执行策略。
- 无缝工件扫描- 作为常规构建步骤的一部分，验证 npm 软件包、容器和二进制文件。
- 按需生成和验证 SBOM--为每个版本自动生成和验证 SBOM，无需额外开支即可确保出处。
- 透明的开发人员体验- 安全性在后台运行，只有在真正需要干预时才会出现问题。
- 自动修复钩子- 无需中断构建即可隔离或清除受损文件。
以速度为导向的开发文化不需要与必要的安全验证相冲突；自动扫描和审批工作流程应该是必须的，而且对开发速度的影响应该降到最低。
通过将这些功能嵌入软件生命周期，OPSWAT 可帮助企业同时实现开发速度和可验证的信任，而这正是 npm 事件所证明的目前至关重要的平衡。
外卖
Shai-Hulud npm 蠕虫是当今软件威胁的一个明确信号。攻击者不需要侵入你的代码库。他们可以说服你安装它们。验证每一个工件，在每一个阶段嵌入弹性，当仅有自动化还不够时，授权员工采取行动。现在就认真对待这个问题的组织将决定安全软件供应链的未来。
准备好通过量身定制、无缝集成的解决方案保护您的软件供应链免受最新网络威胁的侵害了吗？
