1. 事件背景：当开源信任沦为攻击跳板

近日，Python官方软件包仓库PyPI（Python Package Index）上曝出一起重大供应链攻击事件。黑客通过伪装成知名AI项目DeepSeek，上传了名为deepseeek和deepseekai的恶意软件包，企图利用开发者对开源生态的信任窃取敏感数据。根据Positive Expert Security Center（PT ESC）的研究，这两个软件包被下载超过200次，其恶意载荷通过云平台实时回传用户环境变量、API密钥、数据库凭证等核心信息，直接威胁企业基础设施安全。

此次事件不仅暴露了开源软件仓库的安全隐患，更揭示了现代软件供应链的脆弱性。攻击者瞄准PyPI这一全球Python开发者高度依赖的官方平台，通过仿冒流行项目名称，成功绕过开发者对开源组件的信任机制，将恶意代码植入目标环境。这一手法标志着供应链攻击的战术升级——从隐秘依赖漏洞利用转向主动伪造高知名度项目。

2. 攻击手法拆解：从代码细节到基础设施

恶意载荷的“三重收割”

研究人员分析发现，恶意软件包在执行时触发以下行为：

窃取环境变量：提取系统环境变量中的敏感数据，包括云服务API密钥、数据库访问凭证、SSH密钥等。

回传数据至C2服务器：利用Pipedream（一个云集成平台）作为命令与控制（C2）节点，实现数据外泄的隐蔽化和自动化。

持久化潜伏：代码中预留了后续加载远程恶意模块的接口，为横向渗透埋下伏笔。

攻击者的“AI助手痕迹”

恶意代码中出现了大量注释详细的函数说明，例如对数据加密逻辑、环境变量遍历方法的逐行解释。PT ESC团队指出，这些注释风格与AI编程助手（如GitHub Copilot或ChatGPT）生成的代码高度相似，表明攻击者可能借助AI工具快速构建恶意载荷。这一发现凸显了AI技术的双刃剑效应：一方面提升开发效率，另一方面降低了恶意软件开发的技术门槛。

账户行为中的“红旗信号”

上传恶意包的PyPI账户bvk自2023年6月注册后长期处于休眠状态，直至攻击前突然活跃。此类“低信誉账户发布高关注度包”的模式是典型的供应链攻击特征。然而，许多开发者因急于集成DeepSeek功能，忽视了账户历史审查这一关键步骤。

3.软件供应链安全：脆弱性解剖

开源生态的信任危机:PyPI、npm等开源仓库已成为现代软件开发的“水电煤”，但其开放性也使之成为攻击者的温床。据Sonatype统计，2023年PyPI恶意包数量同比激增315%，仿冒知名项目名称（Typosquatting）和依赖混淆（Dependency Confusion）是主流攻击手法。此次事件中，deepseeek与deepseekai通过名称拼写变体误导开发者，正是Typosquatting的典型应用。

供应链攻击的“蝴蝶效应”:恶意包的传播路径揭示了供应链攻击的链式反应：

开发者个体：因未验证依赖来源，引入恶意包至本地环境。

企业CI/CD管道：若恶意包通过测试进入生产环境，可导致核心数据泄露。

下游用户：若受感染软件被分发，攻击面将指数级扩大。

安全专家指出：“一次PyPI恶意包上传，可能引发从个人开发机到企业云集群的全链条沦陷。”

DeepSeek恶意包事件绝非孤立案例，而是当下软件供应链安全危机的缩影。随着AI驱动的攻击技术升级，开源生态必须构建更健壮的防御体系：开发者需摒弃“拿来主义”思维，企业应建立从代码到云端的全链路防护，而开源平台则需在便利性与安全性间寻找平衡点。

4. 破局之道：构建软件供应链与开源安全体系

软件供应链安全治理体系建设路径：

供方：完善开发和交付过程，提高软件供给能力

供方是开展软件产品开发、交付、运维、废止等生命周期活动的组织。为需求方直接提供产品或服务的供应商为一级供应商，一级供应商的供应商为二级供应商，以此类推。一级供应商与需求方存在直接供应关系，应承担供应链安全的主要责任。本报告中供方指需方的一级供应商，将供方企业软件供应链安全治理体系建设分为四部分：一是建立组织与制度流程，包括软件供应链安全治理团队和制度、协作流程；二是软件开发环节安全治理，包括安全需求和设计、安全编码和验证、开源治理、生成软件物料清单；三是软件交付过程安全治理，包括明确软件交付流程、建立安全的访问控制和传输方式；四是软件服务支持过程治理，包括明确服务方式、提供主动和被动的服务支持。

1. 建立组织与制度流程，统筹供给关键活动

建立软件供应链安全治理团队，统筹软件开发、软件交付、服务支持等软件供应链关键活动。组织层面，企业可由安全部门牵头，联合信息管理中心、质量管理中心、开源办公室等建立实体或虚拟的软件供应链安全治理组织，在软件供应链引入开源软件外包开发软件等第三方非自研组件、代码时进行统一评审。项目层面，针对具体的软件项目，提高开发人员的安全意识，从需求阶段便考虑安全，将安全贯穿至软件开发全生命周期，实现安全左移。同时，提高项目运维服务人员安全意识，能够有效地履行服务职责。

2.强化软件全生命周期安全，实现“安全左移”

将安全融入软件开发全生命周期，实施“安全左移”。供方企业应避免传统研发运营安全模式中安全介入相对滞后导致的修复成本较高等问题，将安全融入软件开发全生命周期，从需求设计阶段便引入安全，采取相关技术与管理手段，避免漏洞与威胁的产生，加固应用服务安全，提升软件质量安全。需求设计阶段明确安全需求，通过多种方式进行安全设计。供方企业进行软件开发时，在需求分析阶段应明确系统的安全需求，识别潜在的威胁和风险，制定相应的安全策略，包括安全相关的软件功能需求和软件安全机制等。在设计阶段制定统一的设计原则，除针对安全需求进行设计外，还需针对系统架构、数据流、身份认证、授权、通信和其他关键组件进行分析和设计，以确保系统对各种攻击和安全威胁具有抵御能力。同时，可通过受攻击面分析、威胁建模等方式进行安全设计，并执行风险消减设计。

3. 明确软件交付流程，保障交付渠道安全

明确交付流程，确保软件交付物安全性、准确性、完整性。软件主要的传递机制是将软件产品及配套文件作为交付物通过供应链从供应商直接到用户，供方企业应和需求方共同建立完善的软件交付流程，包括但不限于制度流程、验收方式等。此外，交付双方应明确软件交付物详情，包括但不限于软件产品、产品说明书、软件物料清单、设计文档、测试文档、部署文档、安装手册等。供方企业应确保提供的软件中不存在公开已知或易于识别的漏洞。同时，供方企业需采取措施保护交付物信息不被篡改和泄露，并提供所交付软件的完整性校验方法。针对软件物料清单，交付方式可分为直接交付和动态访问。直接交付指供方企业将软件物料清单作为交付物之一交付至软件需求方，可作为软件的附加文件提供。由于软件生态系统的多样性，单一的软件物料清单传递机制并不能完全满足需要，对于本地存储资源和电源有限制条件的 IoT 等设备来说，可采用动态访问的方式，包括但不限于软件物料清单订阅平台、URL 等。

4.增强软件服务支持能力，提升安全事件响应速度

明确出软件服务支持方式、服务水平、安全服务协议等内容。供方企业应与需方企业明确服务支持方式，包括线上指导、提供文档说明、培训咨询、驻场等。此外，供方企业应与需方企业供方共同签订服务支持协议，包括服务水平协议和信息安全协议等。服务水平协议用于明确软件交付部署方式、后续维保、新增需求的后续开发及服务支持方式等内容。信息安全服务协议用于明确保密协议、知识产权归属及软件交付安全标准等相关信息。

需方：规范引入和使用过程，夯实内部治理能力

需方是从其他组织获取软件产品的组织，泛指软件用户，或者软件采购方。在软件供应链中主要涉及软件采购、获取、运营等活动。本报告中将需方企业软件供应链安全治理体系建设分为四部分：一是建立组织与制度流程，包括软件供应链安全治理团队和制度、协作流程；二是供应商引入治理，包括供应商资质审查、安全审查、风险监控和退出管理；三是软件获取过程治理，包括软件安全、合规、完整性评估和软件物料清单评估；四是软件使用过程治理，包括软件供应链风险识别和评估、软件资产管理、风险监控与安全事件响应。

1.建立组织与制度流程，统筹治理关键活动

建立软件供应链安全治理团队，统筹供应商和产品引入、软件获取和使用等软件供应链关键活动。组织层面，企业可由安全部门牵头，联合信息管理中心、质量管理中心、开源办公室等建立实体或虚拟的软件供应链安全治理组织，在软件供应链引入供应商、商采软件等进行统一评审，主要针对供应商资质、软件产品安全合规等内容。同时，提高全员的软件供应链风险防范意识，确保所有涉及软件供应链安全治理的员工都对策略、程序和工具有充分的理解，能够有效地履行职责。项目层面，在软件供应链安全治理组织的领导下，将软件供应链引入治理下放到各个项目团队，各个团队针对软件供应链关键活动进行第一层管控，并提交相关评审材料到安全部门，随后由安全部门进行总收口，进行第二层安全管控。针对重要或核心业务场景，应设立专职软件供应链管理机构开展软件供应链安全管理工作。

2.构建供应商评估模型，完善引入评审流程

多角度进行供应链商评审，确保软件供应链引入的供应商安全可信。软件供应商作为供应商上游，其自身及开发过程的安全性对软件供应链各个环节均产生较大影响。对供应商的严格把控和选择有助于降低软件供应链下游企业和用户风险。需方企业应结合自身需求，规划供应商管理计划，构建软件供应商考核标准和评估模型，包括软件产品供应商和外包服务人员供应商。具体包括供应商资质审查、供应商安全审查、供应商风险监控、供应商退出管理。

3.全方位进行软件评估，确保交付物安全可信

针对软件产品进行多方位评估，明确软件满足功能需求和安全合规需求。需方企业应与供方企业共同建立完善的软件交付流程，包括但不限于交付成果、交付方式、验收方式等。此外，需方企业在接受软件产品之前需进行产品全方位检查，除满足功能需求外，还需采取系列措施评估软件产品的安全性、合规性、完整性以及软件物料清单，具体包括：软件安全评估、软件合规评估、软件完整性评估、软件完整性评估。

4.识别软件供应链资产，持续监控和处置风险

建立安全基线，助力识别和评估软件供应链风险。风险基线是组织认为可接受的风险级别，可以清楚地了解组织的风险状况，进而做出更明确地决策，同时为风险识别、评估和环节活动奠定了基础。需方企业可制定安全基线，展示风险管理的流程，具体可包括风险识别、风险评估、风险优先级排序、风险缓解措施等。通过清晰化、流程化软件供应链风险评估、应对流程，在一定程度上可以预测和减轻潜在的供应链攻击，增强企业内部软件供应链弹性。

悬镜安全作为国内软件供应链安全代表厂商，提供全栈软件供应链安全解决方案，涵盖了代码缺陷扫描、开源风险治理、风险发现、渗透测试、积极防御等多个阶段，保障企业用户数字供应链安全风险的高效治理。悬镜安全创始人兼CEO子芽在DSS大会上提到，站在供应链安全全流程治理与运营的视角，将整个数字供应链安全划分为“ 供应链引入、生产链、供应链交付运营”三大环节。对应由 ASOC、SBOM、TMA、SAST、SCA、IAST、DRA、RASP、PTE 等技术手段予以支撑。子芽强调称，在整个过程中敏捷安全将是未来的主要趋势，其中 SBOM 也是数字供应链安全的关键部分。SBOM 即软件物料清单是建立数字供应链的安全基线，将在辅助安全设计评审，交叉安全测试和动态发布等环节发挥重要作用。

正如安全牛在报告中提到，基于供应链视角开展软件安全审查，不仅是满足安全合规的要求，更是保障国家数字经济高质量发展的重要支撑，亦是当前国情下必须落实的重要安全举措。软件供应链安全牵系着整个数字生态的安危，其建设过程布满荆棘，困难重重。但只要我们怀揣对网络安全的坚定信念，积极投身于技术创新、协作共享和标准完善之中，定能开辟出一条安全坦途，让软件供应链在稳固的防护下，助力数字经济蓬勃发展 。