标签 供应链安全 下的文章

在过去一年中，我们见证了多起重大攻击事件，例如 Shai-Hulud 蠕虫攻击、Nx 构建系统被攻破，以及通过 tj-actions/changed-files 漏洞导致机密信息泄露到公开的 GitHub Actions 日志中。但仅仅是罗列各种攻击事件，就足以占据本文的全部篇幅，更不用说深入探讨了。

作为一个行业和生态系统，我们能感受到攻击频率的日益增加。仅在 2024 年，报告的恶意软件包数量就同比增长了 156%。鉴于 Mend 托管的 Renovate Cloud 平台受信于超过 130 万个代码仓库，我们在保护开源软件消费者方面处于非常有利的地位，同时也为自托管 Renovate 的用户提供了更强的安全默认设置。在一系列备受瞩目的 npm 供应链安全攻击之后，Mend Renovate 的维护者们决定，对于选择采纳“最佳实践”配置的用户，默认启用这项安全功能是最佳选择。

为了帮助客户更好地应对这些日益增多的攻击，维护团队正在 Mend Renovate 现有的“最佳实践”配置之上进行构建。该团队一直致力于提供更多“默认即安全”的配置，并首先从 npm 生态系统着手。

在最新的 Mend Renovate 42 版本中，使用“最佳实践”配置的用户将会发现，npm 生态系统中的依赖项更新现在需要通过一个“最短发布时间”的检查，即某个更新发布后必须经过 3 天的窗口期，Mend Renovate 才会提议进行更新。通过这种方法，组织可以确保只有经过验证的、稳定的和值得信赖的依赖项更新才能进入生产环境，从而在保持开发者效率的同时，最终降低供应链攻击的风险。

这有何帮助？
尽管影响广泛，但这些攻击通常利用了两种常见情况：

  • 依赖项的精确版本未被锁定。
  • 依赖项的精确版本已被锁定，但我们在其发布后极短时间内就尝试更新。

不锁定依赖项版本可能有其合理的原因。例如，在 npm 生态系统中，当你发布一个拥有若干依赖项且被许多其他包所依赖的包时。

如果每次你提升一个依赖版本都需要发布自己的包，那么所有依赖于你的包也同样需要提升版本并发布新版，从而在整个生态系统中引发连锁效应。

其中一些过程可以通过自动化来简化——自然是使用像 Mend Renovate 或 GitHub 的 Dependabot 这样的工具，但这仍然需要一定程度的人工审查。

与此同时，不锁定我们的依赖项可能会导致问题，用户可能会立即开始下载一个包的新版本。
在推荐锁定依赖版本后，下一个问题是我们应该多久更新一次。许多工具中现有的默认设置是“一旦有新版本就立即更新”，这可能导致一个恶意升级在其发布几分钟内就被创建为拉取请求 (Pull Request)。

尽管那个恶意的依赖项可能不会进入您开发人员的机器——但它有可能从您的自动化构建管道中窃取机密或其他特权信息——或者利用您 AI 驱动的代码审查工具中的提示注入漏洞。

如果我们增加软件包发布与它出现在您项目的拉取请求中的时间间隔，这就为安全研究人员和自动化安全工具提供了更多时间来发现软件包中的恶意意图，从而减少供应链攻击的可能性。
Mend Renovate 如何助力保障整个生态系统的安全

如上所述，在 Mend Renovate 的最新版本中，我们为所有使用“最佳实践”配置的用户启用了“最短发布时间”检查的强制执行。这适用于更新任何使用 npm 数据源的包，无论其使用的是何种 JavaScript/TypeScript 包管理器。

这项强制执行将：

  • 确保给定的依赖项更新包含其发布时间的元数据（“发布时间戳”）。
  • 确保在该版本发布后未满最少 3 天之前，不会创建任何分支。

如果发现不满足此要求的包更新，Mend Renovate 的依赖项仪表板中将包含一个“等待状态”的条目，并且需要人工明确请求才能更新——从而确保只有“安全”的包更新才会被提出。

（这里的一个告诫是，增加等待时间并不一定意味着所有问题都能被发现——由于针对性攻击或复杂的规避技术，所有问题可能无法都被捕获。）

通过将此功能直接添加到我们的“最佳实践”配置中，那些已经选择遵循行业最佳实践的用户将默认受到保护。而其他所有人也能够添加此功能，例如：
codeJSON

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["security:minimumReleaseAgeNpm"]
}

此外，还可以调整此行为——将等待窗口设置得任意长或短——或者对受信任的内部开发包绕过“最短发布时间”功能。

纵深防御
除了让 Mend Renovate 在满足特定条件（即经过一个给定的窗口期）前不发起更新之外，我们还建议建立多层防御：

在可能的情况下，在您的包管理器中启用此功能，以保护开发人员的机器；和/或在您的自动化构建管道中启用此功能，在发布窗口期过去之前使构建失败。

在撰写本文时，pnpm 10.6 和 yarn 4.2.0 已添加了对这些功能的支持，我们也看到其他包管理器正在考虑添加类似功能。

下一步计划？
继此版本的工作之后，维护团队将继续研究其他包生态系统，以便为我们的“最佳实践”配置启用相应功能，从而进一步保障面向消费者的产品和内部开发环境的安全！

勒索软件组织 RansomHub 对苹果核心供应商立讯精密发起勒索攻击，窃取超 1TB 敏感数据，其中包含 2019 至 2025 年间的产品设计原理图与未发布产品规划方案。此次数据泄露暴露了供应链的网络安全漏洞，不仅让苹果的竞争优势面临被竞品和仿冒厂商觊觎的风险，更凸显出全球制造网络亟需强化网络安全防护措施的紧迫性。

揭秘此次数据泄露：立讯精密遭遇网络攻击，苹果创新核心资产岌岌可危

在技术制造领域，保密的重要性堪比核心芯片，而苹果一家关键供应商近期遭遇的网络攻击，已在行业内引发轩然大波。苹果产品的重要中国代工厂立讯精密工业股份有限公司 沦为勒索软件攻击受害者，超 1TB 敏感数据遭泄露。这起于 2025 年 12 月末首次被披露的事件，现已证实由臭名昭著的勒索软件组织 RansomHub 所为，该组织还扬言将公布窃取的文件，其中包括工程设计原理图、3D 计算机辅助设计模型以及机密产品规划方案。
此次泄露直指全球供应链的安全短板，对于苹果这类依靠国际合作伙伴网络维持消费电子领域竞争优势的企业而言，影响尤为重大。从网络安全论坛和行业报告披露的细节来看，攻击者入侵立讯精密系统后，窃取的资料可能涉及苹果 2019 至 2025 年间所有未发布产品信息。这并非一次普通的黑客攻击，这些数据对竞品厂商、仿冒者，甚至试图窥探苹果未来产品布局的国家行为体而言，都堪称价值连城的信息宝库。
苹果素来以严苛的安全防护体系自居，但此次事件暴露了这家科技巨头对供应商安全防御能力的高度依赖。立讯精密负责 iPhone、AirPods 等多款苹果设备的零部件组装，是苹果生产生态中的核心节点。近年来该企业业务规模大幅扩张，甚至成为富士康等老牌代工厂的强劲竞争对手，而此次数据泄露则表明，其业务扩张或许是以牺牲完善的网络安全防护为代价。

过往入侵事件的警示与持续升级的网络威胁

业内人士指出，此次攻击是针对苹果供应链的一系列网络攻击的最新一环。早在 2021 年，苹果另一家供应商广达电脑就曾遭遇 REvil 勒索软件组织的类似攻击，导致未发布 MacBook 的设计原理图被泄露。据苹果科技资讯网站 MacRumors 的相关报道，该事件迫使苹果加快对所有合作供应商的安全审计工作。而此次立讯精密的数据泄露事件性质更为严重，黑客宣称已获取产线相关数据，此举或将直接扰乱苹果的产品制造进度。
发起此次攻击的 RansomHub 组织，向来以针对知名企业实施大胆的网络攻击著称。该组织的关联人员在暗网发帖炫耀，称已窃取包含电路设计、产品蓝图在内的立讯精密内部文件。匿名的网络安全专家表示，此次被盗数据可能包含苹果多款未发布设备的原型机信息，甚至包括增强现实硬件和下一代可穿戴设备的技术升级细节。RansomHub 组织扬言，若未收到赎金就将泄露全部数据，这让事件的紧迫性进一步升级 —— 任何信息的公开，都可能严重削弱苹果的行业竞争优势。
苹果对此的回应延续了其一贯的谨慎风格，暂未就此次数据泄露事件直接置评。但知情人士透露，苹果正与立讯精密紧密合作，开展损失评估并强化安全防御体系。这一合作至关重要，苹果 2023 年在官方新闻中心发布的一份研究报告就曾强调，全球数据泄露威胁正持续加剧，而苹果向来依靠端到端加密技术保护用户数据安全。

供应链安全漏洞全面暴露

此次事件的影响远不止于直接的数据丢失。对于行业从业者而言，这起泄露事件引发了人们对科技制造领域主流准时制生产模式抗风险能力的质疑。立讯精密在中国的生产基地承担了苹果大量产品的组装工作，如今其网络安全的潜在漏洞已成为行业关注的焦点。据印度时报新闻网报道，此次攻击可能是利用了系统老旧软件的漏洞，或通过内部人员权限入侵，使得黑客得以在数周内隐匿在立讯精密内部系统中进行操作。
此次事件难免让人联想到近期发生的其他网络安全事故。就在去年，研究人员发现苹果 M 系列芯片存在一个名为 GoFetch 的安全漏洞，攻击者可通过该漏洞从系统缓存中提取加密密钥。网络安全记者金・泽特在 X 平台援引相关论文细节指出，这一漏洞影响了 M1、M2、M3 全系列处理器，凸显出硬件层面的安全风险与立讯精密这类软件层面的数据泄露形成叠加威胁。尽管苹果已通过软件更新修复了该漏洞，但这一事件也印证了没有任何系统能做到绝对安全。
此外，立讯精密遭攻击的时间节点，恰逢美中贸易关系引发的地缘政治紧张局势升级。苹果此前已在推进供应链多元化布局，减少对中国制造商的依赖，将部分产能转移至印度和越南。业内人士推测，此次数据泄露事件可能会加速这一进程，促使苹果对所有合作供应商制定更严苛的网络安全标准。一家竞品代工厂的高管表示：“这不仅仅是数据泄露的问题，更是对整个苹果生态系统信任的考验。”

勒索软件的攻击手段与行业连锁反应

深入分析 RansomHub 的攻击手段可以发现，该组织使用的勒索软件技术十分先进，可在对文件进行加密的同时，将数据窃取至外部服务器作为勒索筹码。此次该组织宣称窃取了超 1TB 苹果机密信息，这一数据量远超以往多数数据泄露事件。网络安全资讯网站 Help Net Security 的报告证实，RansomHub 的关联人员已在地下论坛发布了部分被盗数据样本，其中包括看似真实的工程图纸片段。
此次事件给苹果带来的潜在损失是多方面的。一旦数据被公开，苹果未来数年的产品路线图将提前曝光，三星、华为等竞品厂商可据此提前布局，针对性地抗衡苹果的创新成果。例如，未发布 iPhone 机型的设计原理图、智能家居设备的实验性功能细节等，都可能流入黑市，进而引发仿冒产品的泛滥。行业分析师估算，此类知识产权泄露事件曾导致企业蒙受数十亿美元的营收损失。
而立讯精密自身也面临着品牌声誉受损和潜在经济处罚的风险。作为苹果第二大代工厂，立讯精密为扩张产能投入了巨额资金，此次数据泄露事件可能会引发苹果对双方合作合同的重新审核，甚至面临合作终止的后果。苹果科技资讯网站 AppleInsider 等账号在 X 平台发布的信息显示，暗网上已出现兜售此次被盗数据的信息，显然已有买家开始争相接洽。这种地下交易市场正借助此类数据泄露事件不断发展，数据中间商愿意为独家的技术机密支付高价。

苹果的战略应对与未来的安全防护措施

此次数据泄露事件后，苹果大概率会采取多维度的应对策略。在企业内部，技术团队可能正在开展溯源分析，追踪攻击源头，并与专业网络安全公司合作弥补安全漏洞；在外部，苹果将进一步向供应商施压，要求其采用零信任安全架构—— 即系统内任何主体都不会被默认赋予信任权限。这一转变也与行业整体发展趋势相契合，2025 年微软就曾披露过一个编号为 CVE-2025-31199 的 macOS 系统漏洞，攻击者可通过该漏洞窃取私人文件数据，这一事件也推动了行业对安全架构升级的重视。
展望未来，立讯精密数据泄露事件可能会推动相关监管政策的调整。各国政府，尤其是美国政府，正推动出台数据泄露强制上报制度，并强化供应链安全监管。拜登政府推出的网络安全行政令或将迎来新的实施动力，迫使科技巨头对合作供应商开展更严格的安全审计。对苹果而言，这意味着需要在创新速度与安全防护之间找到平衡，这一难题也一直贯穿于苹果与安卓生态的竞争过程中。
业内人士同时强调了人为因素的重要性：立讯精密等供应商必须加强员工网络安全培训，提升全员钓鱼邮件识别意识。网络安全资讯账号 Dark Web Informer 在 X 平台发布的一则消息称，2024 年苹果曾发生内部工具数据泄露事件，这一前车之鉴表明，即便是微小的信息暴露，也可能演变成严重的安全事故。企业通过集成先进的人工智能驱动威胁检测技术，能更精准地预判网络攻击，将被动的安全补救转变为主动的防御。

全球影响与企业竞争优势的重构

此次数据泄露事件造成的全球影响不容小觑。在知识产权已成为国家战略资产的时代，这类事件正不断引发各界对国际网络安全规则的探讨。中国作为全球制造业中心，让此次事件的影响更添复杂性，尽管目前没有任何证据，但仍有部分专家猜测此次攻击可能涉及国家行为，不过现阶段调查焦点仍集中在 RansomHub 这类跨境作案、逍遥法外的犯罪集团上。
对于苹果的竞品厂商而言，此次事件既是机遇，也暗藏风险。部分厂商可能会试图利用泄露的数据分析苹果的研发方向，但与此同时，这些企业自身也可能成为勒索软件组织的攻击目标，这或将推动整个行业联合起来，建立网络安全情报共享机制。美国网络安全和基础设施安全局等机构，早已在倡导搭建协作框架，共同对抗勒索软件威胁。
归根结底，此次事件将考验苹果的抗风险能力。苹果此前曾经历过新冠疫情、贸易战等多重供应链危机，且每次都能浴火重生，发展得更为强劲。尽管此次数据泄露事件性质严重，但也可能推动苹果在安全制造领域实现技术创新，确保未来的新产品在正式发布前，始终保持高度保密的状态。

从此次事件中汲取的行业教训

行业领军企业从此次事件中强调了供应链多元化的重要性：苹果扩大供应商版图的举措虽能降低单一供应商带来的风险，但真正的安全防护需要实现供应链的端到端可视化管理。区块链等用于追踪数据完整性的技术正逐渐得到应用，可为敏感文件打造不可篡改的分布式账本，提升数据安全等级。
此外，黑客发起勒索攻击背后的巨额经济利益，也凸显出企业亟需建立完善的网络安全保险机制和数据恢复预案。立讯精密此次选择支付赎金或是拒绝妥协，都将为其他供应商处理此类网络安全危机树立先例。
随着事件的逐渐平息，立讯精密数据泄露事件也为现代制造业敲响了警钟 —— 数字时代的网络威胁无处不在。对苹果而言，这不仅是强化自身安全防线的号召，更是要筑牢整个供应链的安全屏障，唯有如此，才能守住支撑其市场主导地位的产品神秘感与技术创新优势。

一、代码签名沦为恶意软件的“护身符”

当你在运行某个软件时，看到如下所示的弹框，“已验证的发布者：XXX有限公司”，你是否会不假思索地点击“是”？然而，大量安全事件表明这样的信任已经被攻击者滥用，看似安全的软件来源可能来自于精心设计的伪装。

近年来，软件供应链安全事件频发，为了保护软件真实性与完整性，代码签名机制应运而生。代码签名主要依赖公钥基础设施 PKI 技术，旨在确保软件来自真实来源且软件内容未被篡改。当终端用户安装或以管理员权限运行软件时，操作系统会验证代码签名的有效性，帮助用户判断此软件是否值得信任（如上图所示）。然而，攻击者有时会反过来利用代码签名 PKI 信任体系中的安全缺陷，通过某种手段为恶意软件配置代码签名，帮助恶意软件绕过操作系统和杀毒软件的检查，我们称之为“代码签名滥用”。

为了应对代码签名滥用带来的安全威胁，奇安信技术研究院星图实验室与清华大学、中关村实验室联合研究团队在 NDSS 2026 会议上发表了论文《Understanding the Status and Strategies of the Code Signing Abuse Ecosystem》。这项工作由清华大学和奇安信联合培养的卓越工程师计划博士研究生赵汉卿主导完成，导师为段海新教授（清华大学）和应凌云博士（奇安信星图实验室）。其他作者分别为张一铭（清华大学）、张明明（中关村实验室）、刘保君（清华大学）、游子权（清华大学）、张书豪（奇安信星图实验室）。

在这项工作中，我们利用从真实世界中收集的 3,216,113 个已签名的恶意 PE 文件，对 Windows 代码签名滥用行为进行了大规模测量。通过细粒度的代码签名滥用检测分类算法，我们检测到了 43,286 张滥用证书，构建了迄今为止最大的滥用标记数据集。分析发现当前代码签名滥用现象普遍存在，影响了 46 家 CA 厂商以及 114 个国家或地区的证书。我们发现了五种滥用者的攻击策略，并根据当前代码签名 PKI 存在的安全缺陷提出了若干缓解措施。

二、代码签名研究的三大挑战

与传统的 Web PKI 不同，代码签名 PKI 测量研究存在三大挑战：

  1. 缺少大规模数据集：在 Web PKI 中，研究者可以通过 TLS 扫描主动收集数据或被动分析 TLS 流量。Censys 和 Rapid7 等公共数据集也能为测量工作提供支持。此外，证书透明度（CT）机制提供了 CA 颁发记录，方便研究者批量获取证书数据。然而，代码签名生态系统相对封闭，无法通过主动扫描或 CT 等手段获取大规模数据集，这是制约代码签名测量研究的最大障碍。
  2. 缺少 Ground Truth：尽管近年来代码签名滥用事件频发，但是学术界尚未找到代码签名滥用检测分类相关的 Ground Truth，以往基于签发行为的分类方法被证实可能会被攻击者绕过。这阻碍了对代码签名证书进行标注和聚类分析。
  3. 问题根源难以溯源：CA 端的操作和实现并不透明，即便定位到代码签名滥用行为，也难以由此溯源到造成滥用的根源所在，导致无法提出有针对性的缓解措施。

我们的工作分别通过综合公共数据集与私有沙箱样本、设计基于撤销信息的滥用检测分类算法、按照不同滥用类型作细粒度分析等方法解决了以上三大挑战。

三、代码签名滥用测量的创新方法设计

为了解决以上挑战，我们提出了针对代码签名滥用测量的一系列创新方法设计，以实现大规模、细粒度、可溯源的滥用测量分析。

数据收集方面，我们综合了公共数据集与私有沙箱样本。我们收集了公共恶意软件存储库 VirusShare 在 2020 年 10 月至 2024 年 10 月期间发布的所有样本，经过过滤保留了 176,968 个签名 PE 样本。此外，我们还从合作公司沙箱中补充收集了 3,828,744 个签名的 PE 文件。两个数据集通过合并去重后共得到 3,962,788 个签名样本，通过反病毒引擎分析最终筛选出了 3,216,113 个恶意签名样本。此外，我们还从多个维度对样本特征进行了扩充，比如爬取 CRL 撤销信息、收集样本恶意行为分析报告等，以实现更精准的检测与分析。

为了实现细粒度的分析，我们提出了一种代码签名滥用检测分类算法。受益于近年来 CA 撤销透明度的改善，我们得以通过已撤销证书被披露的撤销原因（Revocation Reason）来推知证书滥用背后的原因。我们依据样本对应的 SignTool 输出结果、CRL 撤销信息以及 OpenCorporates 查询结果设计了新的检测分类方法，将滥用分为签名复制、私钥窃取、身份盗用、空壳公司、自签证书等五种滥用类型。不同的滥用类型采取了不同的滥用手段，其产生的安全威胁与影响范围也有所不同。对于私钥窃取、身份盗用以及空壳公司这三类相对高级的滥用类型而言，由于攻击者掌握受信任证书的私钥，他们可以任意为恶意软件进行签名且不会触发操作系统的安全告警，具有隐蔽性强、影响范围大的特点。

此外，我们还设计了一种基于 LLM 的证书关联方法，通过输入证书主题字段以及公钥信息来推断滥用证书是否来自同一攻击者。这一方法不仅帮助我们扩展标记了 287 张未标记滥用证书，还以此聚类得到了 3,484 个证书多态类簇，为后续滥用策略分析提供支撑。

四、核心贡献与关键发现

构建迄今最大的滥用标记数据集

利用代码签名滥用检测分类算法，我们最终收集到了 3,216,113 个来自真实世界的已签名的恶意 PE 文件，从中提取得到了 43,286 张滥用证书，构建了迄今为止最大的代码签名滥用标记数据集。值得注意的是，其中有 23,252 张滥用证书由公共可信 CA 颁发，我们的工作重点关注这些具有高威胁的证书样本。

对滥用生态开展全面测量

我们利用上述代码签名滥用标记数据集对滥用生态开展了全面而深入的测量分析工作。分析发现当前代码签名滥用现象普遍存在，影响了 46 家 CA 厂商以及 114 个国家或地区的证书。我们发现部分 CA 明显更受攻击者青睐，且与市场份额与证书价格无关，这可能反映出某些 CA 对于证书申请者的身份审核存在漏洞。

良性样本与恶意样本代码签名中的 CA 分布对比

首次发现“幽灵证书”

阻止滥用证书的唯一有效手段是证书撤销，测量发现为恶意软件签名的滥用证书撤销率仅为 17.56%。我们首次发现了制约撤销率提高的关键因素——“幽灵证书”，即已被确定为滥用却无法被撤销的证书。这些证书由于其颁发者证书过期、撤销或停止运营导致撤销设施（CRL/OCSP）失效，即使识别到滥用行为也无法发布撤销信息，而它们的代码签名即使在签名证书过期后由于时间戳（TSA）的存在依然有效。我们发现已确认被滥用但仍未被撤销的证书中至少有 38.96% 符合“幽灵证书”的条件。

“幽灵证书”示意图

发现五种滥用策略

为了找到当前代码签名 PKI 的安全缺陷并提出有针对性的缓解措施，我们深入分析了攻击者的行为和策略。我们通过分析标记数据集总结出了五种滥用策略，旨在逃避检查、降低成本和扩大攻击影响。例如，在证书申请阶段，攻击者可能会利用不同国家之间 CA 身份审查宽松程度的差异有选择性地申请证书（比如假以越南、亚美尼亚等国公司的身份进行申请）。在证书签名阶段，攻击者可能会为恶意软件精心配置“双签名”，通过附加兼容旧密码算法的签名来扩大攻击影响范围。

深入挖掘证书多态现象

证书多态也是攻击者常用的滥用策略之一。证书多态是指同一实体使用相同（或稍有修改）身份向相同或不同的 CA 申请多张证书的现象。借助证书多态，攻击者可以以相对较低的成本批量获得多个证书（避免注册多个空壳公司带来的巨额开销），同时逃避 CA 撤销的检查（一张证书被撤销不影响其他证书）。我们通过证书关联方法识别了 3,484 个证书多态类簇，发现了 315 个利用多态绕过撤销检查的真实案例。此外，我们还首次发现了利用特殊字符实施证书多态的实例（如下图所示）。

利用特殊字符实施证书多态的示意图

五、总结

代码签名是验证发布者身份并确保软件完整性的重要机制。然而，我们的研究发现代码签名滥用已经成为了软件生态的重大安全威胁之一。我们对现实世界的代码签名滥用生态系统进行了大规模测量研究，开发了一种针对证书滥用类型的细粒度检测分类方法，获得了迄今为止最大的滥用证书标记数据集（43,286 个证书）。利用该数据集，我们对代码签名生态系统与攻击者行为进行了全面而深入的分析，揭示了攻击者一系列的代码签名滥用策略。

我们认为造成代码签名滥用持续泛滥的安全缺陷主要来自于 CA 端，包括颁发过程缺乏标准化、消极的滥用治理等。我们建议 CA 增强证书颁发与撤销的透明度（比如建立 CT）、主动监测野外滥用行为、为证书主题字段建立统一标准。同时，我们也希望 Windows 做出相应调整以缓解“幽灵证书”的影响。

最后，本文构建的代码签名滥用数据集已开源发布，期待能为后续研究工作提供参考。我们希望安全社区能够给予代码签名领域更多关注，以更好地维护健康的软件生态。感谢您的阅读！

论文&项目开源地址：https://github.com/XingTuLab/Code_Signing_Abuse_Dataset

学术动态, 技术报告, ,

基于人工智能的流行集成开发环境解决方案（如 Cursor、Windsurf、Google Antigravity 和 Trae）会推荐 OpenVSX 注册表中不存在的扩展，这使得威胁行为者能够占用其命名空间并上传恶意扩展。

这些 AI 辅助 IDE 是从 Microsoft VSCode 分支而来，但由于许可限制，无法使用官方商店中的扩展。相反，它们由 OpenVSX 提供支持，这是一个适用于 VSCode 兼容扩展的开源市场替代方案。

分支的结果是，这些 IDE 继承了官方推荐扩展列表，这些列表硬编码在配置文件中，并指向 Microsoft 的 Visual Studio Marketplace。

这些推荐以两种形式出现：一种是基于文件的，在打开如 azure-pipelines.yaml 这类文件时触发，并推荐 Azure Pipelines 扩展；另一种是基于软件的，在检测到开发者系统上安装了 PostgreSQL 时发生，并建议 PostgreSQL 扩展。

然而，并非所有推荐的扩展都存在于 OpenVSX 上，因此相应的发布者命名空间未被占用。

供应链安全公司 Koi 的研究人员表示，威胁行为者可能利用用户对应用推荐的信任，注册未被占用的命名空间来推送恶意软件。

研究人员于 2025 年 11 月下旬向 Google、Windsurf 和 Cursor 报告了此问题。Cursor 于 12 月 1 日做出反应，修复了该漏洞。Google 最初于 12 月 26 日从其 IDE 中移除了 13 个扩展推荐，并于 1 月 1 日将该问题标记为已修复。Windsurf 尚未回应研究人员。

与此同时，Koi 研究人员占用了以下扩展的命名空间，以防止恶意利用：

ms-ossdata.vscode-postgresql
ms-azure-devops.azure-pipelines
msazurermtools.azurerm-vscode-tools
usqlextpublisher.usql-vscode-ext
cake-build.cake-vscode
pkosta2005.heroku-command

研究人员上传了非功能性的占位扩展，这些扩展不提供实际功能，但仍能阻止供应链攻击。

此外，他们已与 OpenVSX 的运营方 Eclipse Foundation 协调，以验证剩余的引用命名空间，移除非官方贡献者，并应用更广泛的注册表级别保护措施。

目前，没有迹象表明恶意行为者在 Koi 研究人员发现并采取行动之前利用了此安全漏洞。

建议分支 IDE 的用户始终通过手动访问 OpenVSX 注册表并检查扩展是否来自信誉良好的发布者来验证扩展推荐。

更新 [东部时间 1月5日 14:09]：
文章已编辑，以反映 Cursor 告知 Koi 研究人员其已于 2025 年 12 月 1 日修复了该问题。