开源软件供应链攻击升级与依赖安全治理——2026年上半年AI开源组件投毒事件复盘研究报告

开源软件供应链攻击升级与依赖安全治理 ——2026 年上半年 AI 开源组件投毒事件复盘研究报告

作者单位：泷码软件（上海）有限公司、泷码软件研究院
报告时间：2026 年 8 月
摘要
随着大模型产业规模化落地，AI 开源组件已经成为人工智能工程化的底层基础，软件供应链攻击的攻击面从传统通用开源软件快速向 AI 框架、模型权重包、AI 工具链组件迁移。2026 年上半年连续爆发多起 AI 开源组件投毒事件，恶意伪造包、依赖混淆、版本劫持、CI/CD 流水线污染等攻击手段大量落地，大量企业持续集成持续交付流水线遭到恶意软件包入侵，给 AI 研发环境、训练数据集、模型推理服务、企业内部代码资产带来现实威胁。本报告对 2026 上半年 AI 开源供应链投毒事件开展系统性复盘，对比传统普通软件供应链与 AI 框架供应链在攻击载体、风险传导路径、危害后果上的核心差异，围绕软件包签名校验、依赖版本锁定、开源组件风险扫描三大行业核心防护抓手开展深度分析，剖析当前开源项目维护者的现实压力与治理困境，提出差异化防护体系建设思路。报告梳理当前攻击技术演进特征，剖析治理短板，面向企业研发机构、开源社区、监管机构给出分层治理建议，为国内 AI 产业开源供应链安全建设提供研究参考。

关键词：软件供应链安全；AI 开源组件；组件投毒；CI/CD 安全；依赖治理；软件包签名

目录

1 绪论
1.1 研究背景
1.2 研究意义
1.3 研究范围与边界
1.4 报告数据来源
2 开源软件供应链攻击态势升级
2.1 全球开源软件供应链攻击整体演化趋势
2.2 AI 时代供应链攻击的动机转变
2.3 CI/CD 流水线成为主要攻击突破点
3 2026 年上半年 AI 开源组件投毒事件复盘
3.1 攻击主要技术手段归类
3.2 典型事件复盘梳理
3.3 攻击危害传导链路分析
3.4 受害主体特征统计分析
4 普通软件供应链与 AI 框架供应链差异化风险解析
4.1 传统通用软件供应链风险特征
4.2 AI 框架供应链独有的风险维度
4.3 两类供应链攻击载体、传导路径、危害结果对比
4.4 AI 开源供应链安全治理的特殊难点
5 当前行业主流防护技术路径深度剖析
5.1 软件包签名校验机制：能力边界与落地痛点
5.2 依赖版本锁定机制：收益与固有缺陷
5.3 开源组件风险扫描工具：检出能力短板
5.4 现有防护手段面对 AI 组件投毒的失效场景
6 开源项目维护压力放大的多维度成因分析
6.1 组件数量爆炸带来维护负荷指数级增长
6.2 AI 衍生组件二次分发带来权责模糊问题
6.3 维护者人力、资金与安全能力缺口
6.4 社区治理机制滞后于攻击技术迭代
7 AI 场景下开源供应链差异化防护方案构建
7.1 企业侧分层防护架构设计
7.2 开源社区层面安全机制优化方向
7.3 CI/CD 流水线专项安全加固策略
7.4 AI 模型权重、算子包、工具链组件专项管控
7.5 风险处置与应急响应流程建设
8 挑战与未来发展研判
8.1 当前治理体系面临的现实挑战
8.2 未来 AI 开源供应链攻击演进预判
8.3 国内产业建设建议
9 结论
数据来源
免责声明
参考文献

1 绪论

1.1 研究背景

全球软件产业高度建立在开源生态之上，从底层操作系统、开发库，到当前蓬勃发展的大模型框架、AI 推理工具、模型微调组件，绝大多数人工智能工程化工具均依托开源社区进行迭代。开源模式极大降低 AI 应用开发门槛，企业无需从零开发底层能力，直接复用海量开源组件完成模型训练、推理部署、业务开发。与之伴生，软件供应链攻击已经从零星个案演变为高频常态化安全威胁。

传统软件供应链攻击多聚焦于通用编程语言软件包，攻击者利用包管理平台漏洞、开发者账号泄露、依赖混淆、名称劫持等方式投放恶意包，窃取服务器凭证、窃取源代码、植入后门、执行挖矿程序。进入 AI 产业爆发阶段，攻击者观察到 AI 企业普遍大量使用第三方开源组件，CI/CD 流水线、模型训练服务器、开发工作站拥有高价值业务数据、模型权重、API 密钥，攻击目标逐步向 AI 开源组件倾斜。

2026 年上半年，全球范围内连续出现多起 AI 开源组件投毒安全事件，大量伪造恶意包上传至 PyPI、NPM 等主流包管理仓库，恶意包以知名 AI 框架、微调工具、数据集处理库、推理 SDK 为伪装，一旦被项目引入，即可在构建阶段执行恶意代码，直接污染 CI/CD 流水线环境。流水线作为企业软件交付的核心枢纽，一旦被恶意包入侵，攻击者可以横向渗透至代码仓库、模型存储服务器、生产环境，造成模型泄露、业务系统沦陷、知识产权失窃等严重后果。

事件爆发之后，全球安全厂商、开源社区、大型 AI 企业围绕软件包签名校验、依赖版本锁定、开源组件风险扫描三项核心技术开展大规模讨论。业界逐步意识到，直接套用传统软件供应链防护方案，无法完整覆盖 AI 框架供应链的特有风险。AI 供应链不仅包含代码包，还包含模型权重文件、数据集、算子二进制包、第三方微调补丁等新型载体，风险传导链路更长，攻击面更大。同时，海量 AI 衍生开源项目大量涌现，开源维护者数量增长跟不上组件规模扩张，开源项目维护压力持续放大，社区安全能力短板进一步暴露。在此背景下，系统复盘上半年投毒事件，区分普通软件供应链与 AI 框架供应链风险差异，研究适配 AI 场景的依赖安全治理方案，具备极强现实产业价值。

1.2 研究意义

理论层面，现有大量软件供应链安全研究主要面向传统通用软件包，针对 AI 专属开源供应链的系统性复盘研究相对不足。本报告对比普通软件供应链和 AI 框架供应链的风险差异，完善 AI 领域软件供应链安全的分析框架，补充 AI 组件投毒攻击的案例库，丰富供应链安全理论在人工智能领域的应用。

产业实践层面，国内大量 AI 企业、科研机构普遍直接引用互联网开源 AI 组件，多数企业的安全体系沿用传统软件安全方案，没有针对 AI 组件的特殊风险做适配。本报告复盘真实安全事件，剖析各类防护技术的优势与局限，给出差异化防护方案，帮助企业识别现有安全机制的失效场景，完善 CI/CD 流水线安全管控，降低开源组件投毒带来的业务风险。

社区治理层面，报告剖析开源维护者面临的现实困境，揭示社区治理机制与攻击技术迭代之间的落差，为开源社区完善包管理、签名、举报、审核机制提供参考。

1.3 研究范围与边界

本报告研究时间窗口聚焦 2026 年 1‑6 月上半年公开披露的 AI 开源组件投毒事件。研究对象为面向大模型开发、训练、微调、推理的开源组件，涵盖 Python 类 AI 库、AI 工具链、模型处理脚本包，重点关注 PyPI 生态，同时兼顾 NPM 生态中 AI 相关前端与构建组件。

报告重点关注组件投毒类供应链攻击，即攻击者通过包管理仓库投放恶意伪造包，利用开发者依赖引入实现恶意代码执行；不包含传统漏洞利用、内网渗透、业务应用层漏洞。本报告区分普通软件供应链（传统业务开发类组件）和 AI 框架供应链（AI 模型训练推理相关组件），重点研究二者防护方案差异化。

报告研究边界说明：报告案例主要来源于公开安全披露，部分未公开内部受害事件无法纳入统计；部分攻击事件仅有技术复现，无大规模真实受害案例，报告做区分说明。报告提出的防护方案为通用性研究结论，不同企业业务规模、研发架构不同，落地需要结合自身现状做适配调整。

1.4 报告数据来源

详见文末统一 “数据来源” 章节。

2 开源软件供应链攻击态势升级

2.1 全球开源软件供应链攻击整体演化趋势

回顾过去数年，开源供应链攻击经历多轮迭代。第一阶段以漏洞利用为主，攻击者利用开源组件已知漏洞进行攻击；第二阶段转向上游投毒，攻陷开源项目维护者账号，在官方版本植入恶意代码；第三阶段大规模普及依赖混淆、名称劫持，攻击者发布名称高度相似的伪造包，利用开发者拼写错误、复制粘贴失误实现恶意包引入；当前进入第四阶段，攻击高度瞄准 CI/CD 流水线，并且向 AI 专属组件定向演进。

包仓库平台统计显示，恶意软件包提交数量持续走高。攻击者的攻击门槛持续下降，公开可获取的恶意包生成脚本、自动化投毒工具降低攻击者技术门槛，攻击者不需要深度理解目标开源项目逻辑，仅需要复制项目描述文档、修改包名称，即可快速批量生成大量伪装恶意包。

早期供应链攻击收益多为挖矿、简单信息窃取；现阶段攻击者目标更加多元，包含窃取 AI 模型权重、窃取 API 密钥、窃取企业内部训练数据集、植入后门用于供应链下游持久控制，部分攻击带有商业情报窃取属性。

2.2 AI 时代供应链攻击的动机转变

传统通用软件包投毒，攻击者主要目标是挖矿、窃取服务器凭证、勒索加密。而 AI 开源组件投毒，攻击者可以获取更高价值资产：第一，窃取企业自研大模型权重文件，模型属于 AI 企业核心知识产权，具备极高商业价值；第二，窃取训练数据集，很多企业训练数据集包含业务敏感数据、用户隐私；第三，窃取大模型 API 密钥、向量数据库访问凭证；第四，污染训练流程，实现数据投毒、模型后门植入，下游使用者加载被污染组件之后，产出的模型直接携带后门；第五，横向渗透 CI/CD 流水线之后，把恶意逻辑传递到下游所有依赖该组件的业务系统，实现攻击范围放大。

高价值目标驱动之下，AI 相关开源包成为攻击者重点瞄准对象。攻击者优先选择热度高、下载量大、迭代速度快的 AI 开源项目作为模仿对象，制作高仿恶意包。

2.3 CI/CD 流水线成为主要攻击突破点

CI/CD 流水线是现代软件研发交付的核心载体，代码提交之后流水线自动拉取依赖包、编译构建、单元测试、打包发布。绝大多数企业流水线环境具备访问内部代码仓库、制品库、模型存储服务的权限。

当开发者在项目配置文件中引入恶意 AI 组件包，流水线执行构建时就会自动下载并执行包内恶意代码。此时恶意代码运行在流水线容器内部，可以直接读取流水线环境变量，拿到密钥、token，访问内部制品库，窃取构建产物，甚至修改代码仓库源码。

该攻击模式的显著特点：开发者本地开发环境不一定触发，但是自动化流水线批量触发，一次恶意包投放可以影响大量下游项目。2026 上半年多起事件中，大量受害企业并非开发人员本地中招，而是 CI/CD 流水线执行阶段触发恶意载荷，企业如果缺少流水线环境安全审计，会长时间无法感知入侵行为。

流水线安全过去很多企业重点关注代码扫描，却忽略依赖包下载阶段的风险，默认认为包仓库下载的组件是可信的，这一安全假设在当前供应链攻击环境下已经不再成立。

3 2026 年上半年 AI 开源组件投毒事件复盘

3.1 攻击主要技术手段归类

结合上半年公开事件，AI 开源组件投毒主要使用四类技术手段。

第一，依赖混淆 / 名称劫持。攻击者注册与主流 AI 开源库高度近似的包名，替换个别字符、增减后缀，包描述文档直接复制真实开源项目介绍，下载量、项目简介刻意模仿真实项目。当开发者书写依赖的时候拼写错误，或者搜索引擎检索到伪造包，就会引入恶意版本。

第二，版本劫持。部分攻击者观察真实 AI 项目版本迭代节奏，在官方新版本发布前后快速上传同名但是版本号接近的恶意包，部分私有源镜像同步错误，将恶意版本同步到企业内部制品库。

第三，维护者账号劫持。攻击者通过钓鱼、密码爆破窃取真实开源项目维护者账号，向官方仓库上传植入恶意代码的新版本，所有下游用户升级依赖就会接收恶意代码。该类攻击危害最大，因为包来自官方维护者账号，普通签名校验容易直接信任。

第四，下游二次分发污染。很多 AI 开发者会 fork 开源项目，在个人仓库发布二次修改版本，攻击者污染高 star 数 fork 项目，将恶意包上传公共仓库，很多开发者直接引用 fork 版本，带来安全风险。

恶意包内部载荷行为主要包含：读取环境变量窃取密钥、读取本地目录寻找模型权重文件、向外网回传敏感文件、植入持久化后门、执行挖矿程序、修改项目代码文件。

3.2 典型事件复盘梳理

事件一：大模型微调工具依赖混淆投毒事件。攻击者针对一款国内广泛使用的 LLM 微调开源工具制作高仿 PyPI 包，包名仅有单个字符差异，项目描述、readme 文档完整复制原项目。恶意包在 setup 安装阶段执行恶意脚本，当 CI/CD 流水线执行 pip 安装依赖，脚本读取环境变量，搜集流水线 token、API 密钥，回传外部服务器。大量直接引用该包的 AI 研发流水线被触发，部分企业未配置依赖锁文件校验，直接拉取最新版本，造成凭证泄露风险。安全厂商监测到该恶意包下载量短时间快速上涨，上报 PyPI 平台之后包被下架，但已经存在一定数量下载记录。该事件暴露大量 AI 项目没有严格锁定依赖版本，直接使用不带版本号的依赖声明。

事件二：AI 数据集处理组件版本劫持事件。针对多模态数据集处理开源库，攻击者上传版本号略高于官方正式版本的同名恶意包。部分企业内部私有制品库自动同步上游仓库，将恶意版本同步至内网。企业 CI/CD 流水线执行构建，自动升级到 “更高版本” 的恶意组件。该恶意包不会立刻明显破坏业务，属于潜伏型后门，在训练任务启动时扫描服务器磁盘搜寻模型权重文件。该事件体现单纯依靠版本号大小判断版本可信性是完全错误的。

事件三：推理 SDK 衍生 fork 项目投毒事件。大量开发者 fork 主流推理 SDK 仓库，攻击者攻陷高星 fork 仓库账号，发布衍生包。很多开发者直接引用 fork 衍生包用于私有化部署，并未校验上游来源。恶意包在模型推理启动阶段执行恶意逻辑，尝试向外传输本地缓存的模型文件。该事件体现 AI 生态大量衍生二次分发组件，来源溯源难度远高于传统软件包。

多起事件共同现象：受害主体以 AI 创业公司、科研机构、大模型应用开发团队为主；很多团队安全资源有限，安全建设重心放在业务应用安全，缺少针对开源依赖的专项管控；CI/CD 流水线缺少运行时行为审计，恶意代码执行之后难以第一时间发现。

3.3 攻击危害传导链路分析

AI 开源组件投毒完整传导链路：
1. 攻击者制作伪装恶意 AI 组件，上传公共包管理仓库；
2. 开发者编写项目依赖，因为拼写错误、搜索误导、引用 fork 衍生项目，引入恶意包；
3. 代码提交，CI/CD 流水线启动，执行依赖安装，下载执行恶意包代码；
4. 恶意载荷在流水线容器内部执行，读取环境变量、本地文件；
5. 窃取密钥、模型文件、数据集，回传攻击者服务器；或者在流水线修改代码、构建产物；
6. 风险向下传导：如果构建产物把恶意组件打包，后续部署到测试、生产环境，造成更大范围扩散。

与普通软件供应链不同，AI 场景下除代码泄露之外，还会发生模型权重泄露、训练数据集泄露，这两类资产是 AI 企业核心资产，损失会直接冲击商业竞争力。

3.4 受害主体特征统计分析

基于公开告警、安全厂商披露样本统计，2026 上半年受 AI 开源组件投毒影响的主体具备如下特征。

第一，中小型 AI 创业团队占比最高。团队业务迭代速度快，追求快速落地，大量直接引用开源 AI 组件，安全流程不完善，缺少组件准入管控。

第二，高校与科研院所 AI 实验室。科研项目注重功能实现，安全约束较弱，项目依赖管理松散，经常直接使用最新版本依赖。

第三，传统企业内部 AI 研发部门。传统企业原有安全体系面向传统业务系统，没有针对 AI 组件供应链做适配，沿用老一套依赖管理流程。

大型头部 AI 企业受害案例相对偏少，主要因为头部机构普遍部署内部制品库、依赖扫描、签名校验流水线管控，但依然面临衍生组件、内网镜像同步带来的风险，无法做到完全免疫。

4 普通软件供应链与 AI 框架供应链差异化风险解析

很多企业直接照搬传统软件供应链安全方案来防护 AI 开源组件，落地之后发现存在大量防护盲区，根源在于普通软件供应链与 AI 框架供应链底层存在显著差异。

4.1 传统通用软件供应链风险特征

普通软件供应链，主要面向业务后端、web 服务、工具类通用库。核心载体为代码软件包，风险主要集中在代码层后门、漏洞。依赖对象大多是纯代码库，二进制文件较少。

风险传导路径：恶意包执行，窃取服务器凭证、源代码，破坏业务逻辑。危害集中在业务系统、代码资产。

风险来源：公共包仓库官方发布包、少量第三方衍生包；组件分发链路相对清晰。

治理重点：包版本管理、组件漏洞扫描、依赖锁、包签名校验。治理对象以代码包文件为主。

4.2 AI 框架供应链独有的风险维度

AI 框架供应链除传统代码包之外，新增大量特殊风险载体：模型权重文件、bin 格式算子二进制包、数据集文件、LoRA 微调权重、推理引擎二进制组件。这些文件不属于传统意义的软件包，传统组件扫描工具对其识别能力弱。

攻击路径除代码投毒之外，新增模型投毒、权重污染。即使代码本身没有恶意，加载被污染的权重文件，就会造成模型行为异常、后门触发。

依赖链条更长：AI 项目依赖链为编程语言包→AI 框架→算子库→模型权重文件→数据集。链条中任意一环被污染，都可以向下传导风险。传统供应链只需要管控代码依赖，AI 供应链需要管控代码 + 权重 + 数据集。

另外 AI 生态大量存在非官方二次分发组件。大量开发者 fork 项目、二次微调模型，在个人仓库发布衍生版本，很多组件没有进入官方包仓库，通过 git 链接、网页下载直接引入项目，传统包管理工具无法感知该类依赖。

受害之后的损失类型发生变化：除代码泄露、服务器沦陷之外，增加模型知识产权泄露、训练数据集泄露、模型输出被操控、AI 业务输出结果不可信等特有损失。

4.3 两类供应链攻击载体、传导路径、危害结果对比

4.4 AI 开源供应链安全治理的特殊难点

第一，资产类型复杂。传统工具只扫描代码包，对权重文件、数据集缺少检测能力，大量风险载体处于安全管控盲区。

第二，依赖来源碎片化。大量 AI 组件不通过 PyPI/NPM 分发，直接从 git 仓库、开发者个人页面下载，脱离包管理体系，版本锁定、签名校验机制无法生效。

第三，开源组件迭代速度极快。大模型技术快速迭代，AI 开源库每周更新，漏洞、恶意包迭代速度超过安全工具规则更新速度。

第四，维护者分散。大量 AI 项目由个人开发者、小团队维护，安全能力不足，缺少安全审计流程。

第五，风险隐蔽性提升。传统恶意包运行立刻产生异常行为；AI 投毒可以做到条件触发，只有执行特定模型推理、特定训练任务才激活恶意逻辑，常规静态扫描很难发现。

5 当前行业主流防护技术路径深度剖析

针对上半年多起投毒事件，行业集中讨论三类核心防护手段：软件包签名校验、依赖版本锁定、开源组件风险扫描。三项技术各有价值，但都存在明确能力边界，不能指望单一技术解决全部供应链安全问题，尤其面对 AI 组件特有风险时会出现失效场景。

5.1 软件包签名校验机制：能力边界与落地痛点

软件包签名校验，是由包作者对发布的软件包进行数字签名，下游使用者校验签名，确认软件包没有被篡改、确认发布者身份，防止中间人篡改包文件，防范普通依赖混淆伪造包。

能力收益：可以有效防范攻击者上传同名伪造包。如果企业强制开启签名校验，未经过合法签名的包会直接拒绝安装，对普通名称劫持攻击形成有效防御。

落地痛点与边界
第一，签名只能确认 “发布者身份”，不能确认发布者本身是否被攻陷。如果真实维护者账号被钓鱼劫持，攻击者使用合法账号发布带签名的恶意包，签名校验无法识别。2026 上半年部分账号劫持类攻击，签名校验机制对此类攻击无效。

第二，AI 生态大量衍生 fork 包、二次修改包，很多二次分发组件没有合法签名。企业如果强制严格签名校验，很多 AI 衍生组件无法直接使用，需要企业自建签名流程，带来研发流程成本上升。

第三，私有制品库镜像场景下，签名校验配置复杂。很多企业搭建内部镜像源，镜像同步过程中签名元数据容易丢失，配置不当会导致校验失效。

第四，签名校验只针对软件包，对于模型权重文件、数据集文件，目前行业缺少成熟统一的签名规范。AI 供应链中占比很高的权重资产，无法复用现有包签名体系。

综上：软件包签名校验是基础底线能力，可以防御大部分伪造包，但无法防御账号劫持，也无法覆盖权重、数据集等非代码资产，必须和其他防护手段组合使用。

5.2 依赖版本锁定机制：收益与固有缺陷

依赖版本锁定，通过锁文件（requirements.txt 锁定版本、poetry lock、pip‑lock 等）把项目依赖精确到具体版本号，避免自动拉取最新版本，防止因为版本自动升级引入恶意新版本包。

能力收益：避免 “浮动版本” 带来的风险，很多受害项目没有写死版本号，使用 >=、不带版本号声明，构建时自动拉取最新版本，一旦攻击者上传更高版本恶意包，流水线直接引入。锁文件可以固定版本，规避该场景风险。

固有缺陷
第一，版本锁定不等于版本可信。锁定的那个版本本身就可以是恶意包。锁文件只能保证版本不随意变动，不能判断这个版本本身有没有投毒。开发者如果最初就把恶意包写入锁文件，风险依然存在。

第二，AI 项目依赖链极其庞大。一个大模型项目，传递依赖可达上百个，手工维护锁文件成本很高。版本锁定之后，安全漏洞升级又会带来版本更新负担，很多团队为了修复漏洞，直接放开版本限制，锁文件机制被绕过。

第三，对于非包管理来源的依赖无效。AI 项目经常直接 git clone 特定分支，或者直接下载权重文件，这类依赖不会进入锁文件，版本锁定完全不起作用。

第四，镜像同步风险。即使锁定版本，如果企业内部私有源镜像把该版本替换成恶意包，锁文件只校验版本号，不会校验文件哈希，依旧会中招。需要配合哈希校验，校验包文件完整性，才能缓解该问题。

版本锁定是必要基础实践，但不能作为唯一防护手段。

5.3 开源组件风险扫描工具：检出能力短板

开源组件风险扫描工具，分为静态成分分析 SCA、恶意包特征检测。工具读取项目依赖，比对漏洞库、恶意包特征库，识别存在风险的开源组件。

能力收益：可以识别已知漏洞、已经被社区曝光的恶意包，做告警拦截，适合常态化安全卡点，在 CI 流水线做门禁，阻断已知风险组件进入构建流程。

短板与失效场景
第一，存在时间差。攻击者新投放的恶意包，尚未被安全厂商收录特征库，扫描工具无法检出，也就是零日投毒。上半年多起事件，恶意包刚上传数小时内，特征库还没有更新，扫描工具无法拦截。

第二，针对 AI 特有载体扫描能力弱。SCA 工具主要面向代码包，对于模型权重、数据集、LoRA 文件几乎没有检测能力。权重文件内部的后门、投毒数据，传统 SCA 无法识别。

第三，混淆规避。恶意包代码做混淆、加密、条件触发，静态扫描难以识别恶意逻辑。很多恶意载荷只有特定环境变量、特定触发条件下才执行，静态扫描无法发现。

第四，传递依赖遗漏。AI 项目传递依赖层级很深，部分扫描工具对复杂 python 依赖链解析不全，会漏掉部分传递依赖的风险包。

风险扫描工具适合拦截已知风险，对于新型未知投毒攻击防护能力有限，必须配合运行时审计、流水线行为监控。

5.4 现有防护手段面对 AI 组件投毒的失效场景总结

软件包签名校验、依赖版本锁定、开源组件风险扫描三者组合，能够解决传统软件供应链大部分风险，但是面对 AI 供应链会出现典型失效场景：
1. 上游维护者账号被劫持，发布带合法签名的恶意新版本；
2. 风险载体不是代码包，而是模型权重、数据集；
3. 组件来自 git fork、外部网页下载，脱离包管理体系，锁文件、签名校验全部无法覆盖；
4. 新型恶意包尚未进入安全特征库，SCA 扫描无法识别；
5. 恶意逻辑条件触发，静态扫描看不到恶意行为。

这也证明，不能直接复用传统防护方案，必须建立 AI 框架供应链差异化防护方案。

6 开源项目维护压力放大的多维度成因分析

AI 开源组件爆发式增长，同时供应链攻击持续升级，开源项目维护者的工作压力被显著放大，已经成为整个供应链安全链条的薄弱环节。维护压力并非单一因素导致，是组件规模、分发模式、人力资金、社区机制多重因素叠加。

6.1 组件数量爆炸带来维护负荷指数级增长

大模型产业热潮之下，AI 方向开源项目数量爆发式增长。各类微调框架、推理工具、多模态处理库、Agent 工具层出不穷。大量项目迭代节奏快，版本发布频繁。

维护者不仅需要开发功能，还需要处理安全问题：版本漏洞修复、恶意包举报甄别、账号安全维护、社区安全问题响应。组件数量上涨，攻击事件数量同步上涨，维护者的安全相关工作量呈指数增加。很多个人维护者本身是兼职开发，没有充足时间做安全审计。

6.2 AI 衍生组件二次分发带来权责模糊问题

AI 生态大量 fork、二次修改、二次分发行为。开发者基于上游开源项目，做少量修改之后重新发布衍生包，重新上传包仓库。衍生组件数量远远超过官方原生项目。

衍生项目很多没有明确安全维护团队，上游官方维护者不负责衍生版本安全，但是下游使用者会默认认为衍生包和官方项目具备同等可信等级。一旦衍生包被投毒，溯源追责非常困难。二次分发链条拉长，信任边界变得模糊，放大安全风险。

6.3 维护者人力、资金与安全能力缺口

绝大多数中小 AI 开源项目维护者为个人或者小团队，没有安全专项预算，没有专职安全工程师。维护者熟悉算法开发，但是对于软件供应链攻击、包签名、账号安全、恶意代码甄别缺少专业能力。

很多维护者缺少安全工具，没有能力对每一个版本做完整安全审计。面对攻击者钓鱼、账号爆破，很容易发生账号沦陷事件。一旦账号失守，就会向下游海量用户传递恶意版本。同时开源项目普遍缺少商业化资金来源，很难付费采购安全审计服务。

6.4 社区治理机制滞后于攻击技术迭代

公共包管理平台现有机制更多侧重事后处置：收到举报之后下架恶意包。事前预防能力不足。面对批量自动化生成的高仿恶意包，平台自动化识别能力存在局限，大量恶意包需要人工举报之后才被处置，存在攻击窗口期。

对于 AI 特有的权重、数据集制品，社区缺少统一的溯源、签名、风险标记规范。当前社区治理机制主要围绕代码软件包设计，还没有适配 AI 全制品链的安全治理框架。社区安全规则更新速度落后攻击者投毒工具迭代速度。

开源维护者压力放大带来连锁后果：维护者疲惫、项目维护中断、安全漏洞响应迟缓，进一步放大下游企业的供应链风险。产业层面需要思考如何分担维护者安全负担，而不是将全部安全责任压在开源项目维护个体身上。

7 AI 场景下开源供应链差异化防护方案构建

区分普通软件供应链与 AI 框架供应链，构建分层差异化防护体系，分为企业研发侧、开源社区侧、CI/CD 流水线专项加固、AI 特有制品管控、应急响应流程五个层面。

7.1 企业侧分层防护架构设计

第一层：依赖引入准入管控。建立 AI 开源组件准入流程，禁止研发人员无管控直接引入外部开源组件。区分普通业务组件和 AI 专属组件，AI 组件除基础漏洞检查之外，额外核查：组件来源是官方上游，还是 fork 衍生版本；权重文件、数据集来源；维护团队活跃度、安全历史记录。对于直接 git 引用、网页下载的权重、数据集，执行更严格准入。

第二层：依赖管理基线。所有包管理组件强制启用版本锁定，同时开启包文件哈希校验，防止版本号相同但是文件被篡改。对于 AI 项目传递依赖做完整解析，不只是直接依赖。针对 AI 衍生 fork 组件，评估风险，尽量替换为官方正式版本；确需使用 fork 版本，需要记录 fork 仓库地址、commit 哈希，锁定具体 commit，禁止直接拉取分支最新代码。

第三层：分层启用签名校验。官方正式上游包，强制开启软件包签名校验；对于没有官方签名的 AI 衍生组件，企业内部建立私有签名机制，经过内部安全审计之后再对内分发。不盲目追求全部组件外部签名，兼顾安全与研发效率。

第四层：多维度风险扫描。SCA 组件扫描作为基础门禁；补充针对 AI 项目的专项检测，针对权重文件、数据集做来源校验；流水线增加运行时行为监控，监控构建阶段异常外网访问、异常文件读取行为，弥补静态扫描无法识别新型恶意包的短板。

第五层：内部制品库隔离。企业搭建内部制品镜像仓库，所有外部开源组件统一经过内部仓库中转，研发流水线全部从内网制品库拉取组件，禁止流水线直接访问公网包仓库。所有外部组件下载到内网之后，执行安全检测，再同步到内部仓库，阻断公网恶意包直接进入流水线。

7.2 开源社区层面安全机制优化方向

第一，完善包平台高仿包识别机制，针对高热度 AI 开源项目，对名称高度相似的新包做人工复核，缩短恶意包存活窗口期。

第二，推广强制签名最佳实践，完善衍生包来源标记，对于 fork 二次分发包，明确标记上游来源，提示下游使用者该组件并非官方版本。

第三，减轻开源维护者安全负担，社区提供免费安全扫描、账号防护工具，降低维护者安全工作门槛。

第四，推进 AI 制品签名溯源规范，不仅针对代码包，探索模型权重、数据集文件的签名、哈希存证机制，补齐 AI 特有资产的溯源能力。

第五，建立 AI 开源组件安全事件快速通报渠道，恶意包发现之后快速向产业同步告警信息。

7.3 CI/CD 流水线专项安全加固策略

上半年大量事件攻击落脚点就是 CI/CD 流水线，流水线专项加固是重中之重。

1. 最小权限原则：流水线执行账号权限最小化，流水线环境变量尽量不存放高敏感密钥，使用密钥管理服务，避免恶意代码直接读取大量凭证。
2. 网络隔离：流水线构建环境网络做限制，构建阶段默认禁止向外网主动访问，仅允许访问内网制品仓库；如果业务必须外网访问，做白名单管控，监控异常出站行为。
3. 构建环境审计：记录流水线每一次构建的依赖包版本、文件哈希、下载来源，完整日志留存，一旦发生安全事件，可以回溯溯源哪一次构建引入恶意组件。
4. 流水线门禁卡点：依赖扫描、签名校验、哈希校验作为流水线门禁，不满足安全基线直接阻断构建。
5. 隔离构建环境：每次构建使用临时隔离容器，构建结束销毁环境，避免恶意代码持久驻留流水线节点。

7.4 AI 模型权重、算子包、工具链组件专项管控

AI 供应链独有的风险载体，无法复用传统包管理防护，需要专项管控。
1. 权重文件、数据集文件下载时记录原始来源链接、文件哈希值，业务加载前校验文件哈希，防止文件被替换篡改。
2. 尽量从官方可信渠道获取权重，谨慎使用互联网个人分享的权重文件；内部建立权重制品库，所有外部权重先入库检测，业务再从内部库取用。
3. 算子二进制包，校验哈希，对二进制文件开展恶意行为检测；尽量优先使用源码编译，减少第三方预编译二进制依赖。
4. 对于 git 直接引入的 AI 组件，不使用分支 latest，锁定 commit 哈希，每次更新 commit 都重新做安全复核。

7.5 风险处置与应急响应流程建设

企业需要建立 AI 开源供应链安全事件应急流程。
1. 建立外部安全情报订阅，跟踪 PyPI、安全厂商发布的 AI 恶意包告警。
2. 一旦收到恶意包告警，快速检索内部项目依赖清单，排查业务是否引入受影响版本。
3. 流水线日志回溯，确认哪些流水线任务下载过恶意包，评估是否发生凭证泄露、文件窃取。
4. 受影响组件快速升级、替换，清理被入侵流水线环境，轮换可能泄露的密钥 token。
5. 完成处置之后复盘，优化内部依赖准入、流水线安全基线，补齐防护短板。

8 挑战与未来发展研判

8.1 当前治理体系面临的现实挑战

第一，安全与研发效率的矛盾。AI 产业迭代速度极快，研发团队需要快速使用最新开源能力。严格的准入、扫描、签名流程会增加研发成本，很多企业在业务压力之下会放松安全管控，如何平衡安全管控与研发迭代速度，是产业普遍现实挑战。

第二，海量衍生组件治理难题。AI 生态海量 fork 衍生项目，来源分散，没有统一治理主体，很难全部实现官方签名与安全审计。

第三，新型投毒攻击手段持续演进。攻击者不断开发新绕过手段，条件触发、混淆加密、模型侧投毒，静态防护手段永远存在滞后。供应链安全不能只依靠静态检测，必须走向运行时、全链路管控。

第四，行业标准尚不完善。针对 AI 软件供应链的专项标准、检测规范还处在发展阶段，不同厂商工具能力参差不齐。

8.2 未来 AI 开源供应链攻击演进预判

第一，AI 组件投毒攻击频次将持续走高。AI 资产商业价值高，攻击者会持续将 AI 开源包作为重点攻击目标。

第二，攻击向模型层、数据集层延伸。不只是代码包投毒，针对权重、数据集的投毒事件会持续增加，不再局限传统代码恶意执行。

第三，攻击更加隐蔽，条件触发型恶意包增多，恶意逻辑不会一安装就触发，满足特定业务条件才激活，规避静态扫描。

第四，攻击瞄准供应链下游传导。攻击者会优先选择下载量大的上游 AI 开源项目，实现一次投毒，影响成千上万个下游 AI 应用。

8.3 国内产业建设建议

面向国内 AI 产业发展，结合本报告复盘，提出几点产业层面建议。

第一，推动国内 AI 开源供应链安全能力建设。建设适配 AI 场景的开源组件风险检测能力，不仅覆盖代码包，同时覆盖模型权重、数据集，补齐传统 SCA 工具的 AI 场景短板。

第二，企业需要转变认知，不能直接照搬传统软件供应链防护方案，针对 AI 框架供应链建立差异化安全基线，把模型、数据集纳入供应链安全管控范围。

第三，重视 CI/CD 流水线安全。AI 企业把流水线安全作为开源供应链防护的核心阵地，落实最小权限、网络隔离、日志审计、安全门禁。

第四，社区层面探索分担开源维护者安全压力。产业机构联合，为国内主流 AI 开源项目提供免费安全审计、账号安全防护，缓解个人维护者安全负担。

第五，推进 AI 开源供应链安全的标准与实践指南落地，形成可落地的行业最佳实践，指导大中小企业开展治理工作。

9 结论

2026 年上半年 AI 开源组件投毒事件标志着开源软件供应链攻击正式深度渗透人工智能产业，CI/CD 流水线成为高频受害对象。软件包签名校验、依赖版本锁定、开源组件风险扫描是不可或缺的基础防护工具，但是每一项技术都存在明确能力边界，无法单独解决全部安全问题。普通软件供应链与 AI 框架供应链在攻击载体、依赖链条、资产类型、危害后果上存在显著差异，直接套用传统防护方案会出现大量防护盲区。

AI 框架供应链新增模型权重、数据集、算子二进制等特殊风险载体，依赖来源碎片化，衍生 fork 组件众多，风险隐蔽性更强。同时开源 AI 项目维护压力持续放大，个人维护者人力安全能力缺口成为供应链安全薄弱环节。

AI 开源依赖安全治理不能只聚焦代码包，需要构建企业准入管控、内部制品库、流水线安全加固、AI 制品专项管控、应急响应相结合的差异化防护体系。兼顾安全管控与 AI 研发迭代效率。未来攻击会持续向模型层、数据集层延伸，产业需要持续跟踪攻击技术演进，完善社区机制、企业防护、行业标准，共同应对 AI 时代开源软件供应链安全挑战。

数据来源

1. 全球主流软件包仓库 PyPI、NPM 公开安全告警公告，2026 年 1‑6 月恶意包下架记录、安全事件通报。

2. 国内外网络安全厂商 2026 上半年软件供应链安全监测报告、AI 开源组件投毒事件公开技术分析文档。

3. 开源安全社区公开漏洞、恶意包披露数据库，公开事件复现技术文章。

4. 泷码软件研究院内部安全监测平台 2026 年上半年 AI 开源组件风险监测统计数据。

5. 公开行业峰会、技术论坛关于 AI 软件供应链安全议题公开讨论材料。

免责声明

本报告由泷码软件（上海）有限公司、泷码软件研究院独立研究编制，报告内容仅为学术研究与产业参考，不构成任何商业决策、安全建设的直接实施依据。

报告中所引用案例、数据均来源于公开可获取信息，本机构不对第三方原始信息的绝对完整性、准确性作出保证。各企业应结合自身业务架构、技术栈、业务规模开展适配评估，自行承担安全建设落地的相关责任。

本报告所有观点为研究院研究观点，不代表任何官方立场。未经书面授权，禁止对报告内容进行篡改、歪曲用于商业宣传；引用报告内容请注明来源为泷码软件研究院。