关于加强AI软件供应链安全审查防范开源组件投毒攻击的建议

一、存在的主要问题和风险

（一）开源组件成"供应链攻击"首选目标

开源软件因其免费、开放、易获取的特点，成为企业构建信息系统的核心依赖。据统计，现代软件系统中开源组件占比超过70%，然而开源组件的安全治理却严重滞后。攻击者只需入侵一个热门开源项目，即可"以点带面"影响数百万用户。此次LiteLLM事件中，攻击者通过入侵项目CI/CD流水线中的Trivy工具获取发布权限，进而推送带毒版本，攻击链路清晰、隐蔽性强。开源生态的"信任传递"机制，反而成为攻击者的"放大器"。

（二）Python生态安全机制"形同虚设"

此次攻击利用了Python的.pth配置文件特性，实现了"无交互感染"。用户只需安装恶意版本，任何Python调用都会触发恶意代码执行，无需用户手动导入模块或进行任何交互。这一攻击手法暴露了Python生态的深层安全隐患：.pth文件本用于简化模块导入，却成为攻击者的"后门钥匙"；PyPI官方仓库缺乏有效的恶意代码检测机制，攻击者可轻易上传带毒包；Python解释器启动时自动处理.pth文件，用户难以察觉异常。Python生态的安全"默认值"亟待重新审视。

（三）企业供应链安全审查"薄弱"

从此次事件看，大量企业在引入开源组件时缺乏基本的安全审查。LiteLLM作为支撑数千家企业AI架构的关键工具，其安全风险直接传导至下游用户，然而多数企业在安装使用前并未进行代码审计、漏洞扫描、来源验证等安全检查。软件物料清单制度尚未普及，企业对自身系统使用了哪些开源组件、存在哪些已知漏洞、如何追踪更新补丁等问题"心中无数"。供应链安全审查的缺位，使企业暴露在"供应链投毒"风险之下。

（四）安全工具自身"被攻破"引发连锁反应

此次攻击的源头是安全工具Trivy被入侵。Trivy是一款广泛使用的容器镜像扫描工具，LiteLLM在其CI/CD流水线中使用了Trivy，攻击者通过入侵Trivy获取了LiteLLM的发布权限。这一攻击路径揭示了一个严峻现实：安全工具自身也可能成为攻击目标，一旦被攻破将引发连锁反应。企业安全体系中的"信任节点"——代码仓库、构建工具、安全扫描器——都可能成为攻击者的"跳板"。

（五）开源项目维护力量"捉襟见肘"

开源项目的安全维护往往依赖于有限的志愿贡献者，安全投入严重不足。LiteLLM作为一个月安装量近亿次的工具，其核心维护团队规模有限，难以应对复杂的安全威胁。攻击者正是利用了开源项目"高影响力、低维护"的特点，通过入侵关联工具实施攻击。开源生态的可持续发展，需要建立更健全的安全治理机制和资金支持体系。

二、对策建议

（一）让"供应链安全"成为强制标准

建议网信部门会同工信部门，加快制定开源软件供应链安全标准和管理办法。明确企业在引入开源组件时的安全审查要求，建立软件物料清单制度，要求企业对使用的所有开源组件进行登记、追踪、更新。推动关键信息基础设施运营者建立开源组件安全准入机制，对引入的开源项目进行代码审计、漏洞扫描、来源验证。将供应链安全纳入网络安全等级保护要求，提升企业安全意识。

（二）让"安全审查"成为准入门槛

建议推动PyPI、npm、Maven等软件仓库建立更严格的安全审查机制。对上传的软件包进行自动化的恶意代码检测、行为分析、来源验证；建立软件包签名制度，确保发布者身份可信；完善漏洞报告和下架机制，缩短恶意包的存活时间。同时，鼓励企业使用私有软件仓库，对引入的开源组件进行二次安全验证，避免直接从公共仓库"裸奔"安装。

（三）让"安全工具"接受安全审计

建议网络安全主管部门组织对广泛使用的安全工具进行专项安全审计。重点关注代码仓库、CI/CD工具、漏洞扫描器、容器镜像等关键安全组件，排查潜在的安全漏洞和供应链风险。推动安全工具厂商建立安全开发流程，对安全工具本身实施更严格的安全管控，避免"安全工具被攻破导致连锁反应"的悲剧重演。

（四）让"应急响应"跑赢攻击传播

建议建立开源软件供应链安全事件应急响应机制。当发现开源组件存在恶意代码或严重漏洞时，能够快速通报、及时下架、广泛预警。推动企业建立软件供应链安全应急响应预案，明确发现供应链攻击后的处置流程：版本核查、密钥更换、日志审计、影响评估等。鼓励安全社区建立威胁情报共享机制，提升整体防御能力。

（五）让"开源生态"获得可持续支持

建议科技部门加大对开源项目的安全支持力度。设立开源软件安全专项基金，支持关键开源项目的安全审计、漏洞修复、维护能力建设；推动建立开源项目安全评级机制，为企业选择开源组件提供参考；鼓励企业参与开源项目安全贡献，形成"使用—反馈—改进"的良性循环。构建可信、安全、可持续的开源生态系统。