一个开源AI包的三个版本，撕开了政府集中采购中长期被忽视的漏洞。

一、一条"安静"的供应链攻击，是怎么被发现的？

4月22日，腾讯云安全中心发布紧急通告：AI模型部署工具Xinference（PyPI官方仓库包名同为xinference）在三个版本（2.6.0、2.6.1、2.6.2）中存在严重的供应链投毒风险。攻击者通过入侵合法贡献者的账户，在项目的__init__.py文件中植入了经过多层Base64混淆的恶意载荷。

当开发者执行"pip install xinference"或直接在代码中"import xinference"时，恶意代码会在内存中自动解码并执行。它会顺着服务器翻找：

·• AWS、GCP、腾讯云、阿里云等云服务凭证

·• Kubernetes访问令牌

·• SSH密钥和authorized_keys

·• 加密货币钱包文件

·• SQL、Redis、MongoDB等数据库连接字符串

·• Shell历史记录及系统环境变量

这些数据最后被打包发送至境外C2服务器。换句话说，一旦政府信息化系统安装了这个包，攻击者几乎等同于拿到了一台"数字钥匙盒"——云账号密码、数据库权限、SSH通道，全部敞开。

二、受影响范围：不止是开发测试环境

影响版本：Xinference = 2.6.0、2.6.1、2.6.2 

安全版本：Xinference ≤ 2.5.0 

这里有一个值得警惕的事实：Xinference是广泛使用的开源AI模型部署框架，国内不少政务AI项目、政府数据中心、企业内部知识库系统都可能在生产环境中使用。而这次攻击的触发条件极低——"import xinference"一行代码即可，不必刻意调用任何函数。攻击者拿到的不只是测试环境的访问权限，而是生产服务器的完整身份凭证。

三、为什么这个问题在招投标场景下更棘手？

1. 政府采购的"技术路线锁定"困境

政府采购信息化项目有一个普遍现象：招标文件一旦指定了某款开源组件的特定版本，中标方往往会严格按标书要求实施，"锁定"技术路线难以更改。开源组件版本迭代速度快，安全维护质量参差不齐，一个版本可能三个月前还是"安全"的，三个后就成了"投毒源"。

2. 集中采购的"一荣俱荣，一损俱损"

政务云、智慧城市、政务大数据平台……这类项目往往是几十个业务系统共用同一个底层开源AI组件库。一旦上游包管理器中的某个版本被投毒，影响的不是一台服务器，而是一整批系统。集中采购的规模效应，在这里反成了风险的放大器。

3. 投标文件技术方案审核的盲区

现行投标文件的技术审核，普遍关注功能满足度、性能指标、售后服务，对"开源组件来源安全性审查"基本没有硬性要求。大多数评分细则里，找不到一条针对"是否使用可信来源的AI开源包"或"依赖项是否存在已知漏洞"的检查项。这等于在评标环节留下了一个制度性空白。

四、深度思考：AI开源供应链的风险本质是什么？

1. "信任链"的脆弱性

开源生态的核心逻辑是"信任传递"：你信任PyPI，PyPI信任贡献者，贡献者信任自动化工具——这条链上任何一个节点被攻破，终端用户就会无辜受害。这次Xinference事件，正是通过入侵"合法贡献者账户"实现的，伪装程度极高，普通开发者根本无从辨别。

2. "安全版本"并非绝对安全

腾讯云给出的修复建议是"降级至2.5.0"。但这又引出了另一个深层问题：一个开源项目一旦被曝出供应链投毒，说明其开发和发布流程已存在系统性漏洞。历史上有太多案例证明，供应链投毒往往是冰山一角，攻击者在得手后会长期潜伏，等待下一次机会。

3. AI模型的"黑箱性"加剧了风险

相比传统软件，AI模型的训练和推理过程缺乏透明性。一个AI模型在推理阶段会调用哪些底层库、访问哪些系统资源，大多数用户一无所知。这就给了供应链投毒更肥沃的土壤：你以为只是在跑一个文本生成模型，实际上后台可能在悄悄"打电话回家"。

4. 政府侧安全意识的结构性滞后

国内政务信息化采购的安全规范，主要形成于传统软件时代，对AI组件的依赖管理基本处于空白。没有SBOM（软件物料清单）强制要求，没有依赖项安全扫描的硬性指标，没有针对AI开源模型的专项安全审查——这些制度建设的滞后，正在积累系统性风险。

五、实操指南：招标文件里该加哪些"安检项"？

① 要求提供AI组件SBOM（软件物料清单）

强制要求投标方提供所有使用的开源AI组件及其版本清单，涵盖模型推理框架、底层依赖库、预训练模型来源，并对清单中的每一个组件标注安全扫描结果。

② 增加"依赖项安全声明"条款

要求投标方声明所有AI组件的pip/conda来源，并对来源仓库的完整性（如有签名验证）进行说明。对于使用了PyPI等公开仓库的，需提供版本锁定文件并说明校验机制。

③ 明确"投毒响应预案"要求

要求投标方在技术方案中包含"开源组件安全事件应急响应预案"，明确一旦发生类似Xinference事件，响应流程、版本回退机制、系统隔离方案等。

④ 建立"入围后二次审查"机制

在中标后、合同签订前，增加一轮针对中标方案技术架构的安全审查，由采购方或第三方安全机构对AI组件清单进行漏洞扫描和供应链评估。这不是额外成本，而是避免踩坑的必要投入。

⑤ 逐步推进"可信AI算力"白名单制度

建议政府采购目录逐步建立AI开源组件的白名单/黑名单制度，对主流AI框架、推理引擎、模型库的安全性进行持续跟踪和评级，并定期向采购单位发布预警清单。

六、写在最后

Xinference供应链投毒事件，不是第一起，也不会是最后一起。它再次提醒我们：AI时代的信息安全战争，早已从"防外"蔓延到"防内"——不仅要防外部黑客攻击，更要防自己信任的"队友"在背后开门揖盗。

对于招投标从业者而言，这一次的教训很直接：技术方案评审的清单里，该加一条"开源组件安全性"了。不是可选项，而是必选项。不是走过场，而是要动真格地查。

安全是1，其他都是后面的0。在AI采购这件事上，这个道理同样适用——甚至，比任何时候都更适用。

————————————————————————————————