NPM “意外” 删除 Stylus 合法包全球流水线和构建被迫中断-CSDN博客

聚焦源代码安全，网罗国内外最新资讯！

专栏·供应链安全

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

NPM 下架Stylus 合法库的所有版本并以“安全占位”页面，使全球依赖于该包的流水线和构建流程均被迫中断。

安全占位页面通常会在全球最大的软件注册表 npmjs.com （主要用于 JavaScript 和 Node.js 开发）的管理员删除恶意包和恶意库后显示。但 Stylus 的情况并非如此：它是一款合法的“革命性”库，每周下载量达300万次，为开发人员提供了一种富有表现力的生成CSS 的方式。

Stylus “意外被 npmjs 禁止”

几个小时前，npmjs 删除了所有版本的Stylus 包并以“安全占位”页面取而代之。早些时候，Stylus 的开发人员 Lei Chen 在 GitHub 的一个议题中提到，“Stylus 意外遭 npmjs 禁止”，而他“正在等待 npmjs 恢复对 Stylus 的访问权限”。

Chen 还在 X 平台上发布帖子称，“我是Stylus 当前的维护人员。Stylus 库已被标记为恶意……导致很多依赖于Styus 的库和框架无法安装。请帮我转发这条信息，希望 npmjs 官方团队会注意到这个问题。”

Stylus 的原始 npmjs 页面显示，该合法库是 CSS 开发领域的“革命性新语言”，每周下载量近300万次。

很多依赖于 Stylus 的开发人员发表担忧，其中一名表示“我的构建失败了，这个管理员失误导致我的软件更新无法发布”。而全栈开发人员 Chanuka Asanka 提到，typescript-plugin-css-modules（每周下载量大到50万次）也依赖于 Stylus，“流水钱正在崩溃。有人知道 npm/yarn 在计划这么做时，是否发布了任何提前通知？” Frappe 论坛上一名Docker 开发人员写到，“我像往常一样通过CI/CD流水线部署 Frappe/ERPNext 时，突然失败了。”新加坡的一名开发人员 Hasseeb Elahi 提醒道，Stylus “是 Angular 12 包的官方依赖。肯定数千个 Angular 构建崩溃了。”

事实确实如此。Angular CLI 的 GitHub 仓库用户分享了因Stylus 依赖消失构建开始中断而导致的出错日志。

到底发生了什么？

一般来说，npm 包会因为违反其中一条开源服务条款而被下架，这种情况对于包含恶意代码的包而言非常常见。但Stylus 的情况并非如此，它的所有版本看似都是干净且运行正常的。

Mend.io 公司的安全研究员 Tom Abai 认为，在调查这起事件时发现，至少 Stylus 的最新版本0.64.0 是“干净的”，但跟该包相关的一件怪事是，“我们调查过程中发现了一件怪事，panyakor 似乎是 stylus npm 包的所有人之一，他上周发布了三个恶意包……”

Npmjs.com和很多开源开发平台一样，允许多个维护人员向同一个包做出贡献。虽然Chen 可能是 Stylus 的主要开发人员，但维护人员名单下列出了其它 npm 账号。

Abai 提到，“Panya 是Stylus 包的维护人员之一，他发布了恶意包并因此账号被禁，所有与他相关联的包都被下降，包括 Stylus。这就是事情的原委，是NPM 发出的一个巨大误报。”

BleepingComputer 进一步证实该 npm 账号 “panya” 确实在 npmjs.com 上被列为 Stylus 以及与 Stylus 不相关的Abai提到的其它三个程序包的维护人员之一。Abai 标记的这三个包是 @pwa-ib/eslint-plugin-compat、@blocks-shared/desktop-title 和 @tui-react-internal/select-account-icon，发布者是 “panya”，目前这三个包要求先在 npmjs.com 注册表上进行认证才能访问，因此不对外公开。

BleepingComputer 报道称，获取并查看这些包后证实了 Abai 的发现。例如，@blocks-shared/desktop-title 中的 “extract.js” 文件是一个已多次看到的概念验证依赖混淆利用。

供应链安全公司 Socket 提到，npm 账号 “panya” 过去至少是12个包的一名维护人员。不过在本文写作之时，该账号名下并未列出任何包，这表明该注册表可能不小心清除了所有的 PoC 利用并删除了 Stylus。

如何应对

幸运的是，Stylus 开发人员和开源社区成员也同步分享了针对依赖 Stylus维持库访问权限和恢复构建的详细方法。

Npm 开发人员可选择“通过动态方式指定 package.json 的 dependencies 部分中的分支、标记或提交哈希”的方式，引用该 Stylus 包。

另外也可使用覆写的方式，“你可以覆写其它依赖使用的 stylus 包版本，方法是在 overrides 部分（在npm v8.3.0及后续版本中支持）进行指定。注意：确保所指定的标签、分支或提交（如 0.54.4）存在于 stylus/stylus 仓库中。如果遇到过时依赖相关的问题，则清空 npm 缓存 (npm cache clean –force)。”

Chen 强调称，“Stylus 中并不包含恶意代码；这一点已得到证实。Npmmirror.com（阿里巴巴资助的一个非盈利性镜像）已恢复了该库的访问权限。目前尚不清楚这是否是巧合，但一款名为 Stylus Tools 的工具组件已被指存在一个CVE漏洞。虽然Panya（Stylus 之前的维护人员）用自己的账号发布了一个包含恶意代码的包（可能是为了安全研究？我不确定），但并未发布包含恶意代码的 Stylus 新版本。我们正在等待 npmjs 的官方措施。是的，我们正在等待他们来处理。评论中已发布应变措施，如需请应用。一些个人感想：如果你所在的公司受 Stylus 事件影响，你需要重新评估 npmjs 和 npm 镜像之间的关系，并设计更可靠的开发流程。”

BleepingComputer 联系npm注册表及其母公司 GitHub 寻求评论，但只被告知参照现已被移除的之前将 Stylus 标记为“恶意软件”的安全公告。

不过，Chen 证实称已经收到 GitHub 的回应，GitHub 称正在着手恢复该项目：“感谢让我们了解这件事情。看似与 stylus 包存在关联的一名维护人员发布了一个恶意包，导致该账号被挂起，相关联包被删除。我们的工程师正在着手恢复 stylus，完成后我们将同步相关消息。如有任何我们可以帮助的地方，请告知。”

过去，开源开发人员曾因意见不合将自己的库从注册表中拖出，或者直接损坏其代码以示抗议而引发热议。而这是注册表有史以来第一次下架整个合法项目，且似乎是管理失误。