供应链投毒态势严峻,企业软件供应链安全治理四大要点浅析

Background

背景

近期，软件"供应链投毒"攻击呈现集中爆发态势。国家网络安全通报中心监测显示，多起攻击事件涉及开源软件仓库和商用工具两大核心供应链场景，呈现出攻击隐蔽性强、影响范围广、危害程度高、传播速度快的共性特征，可造成凭据窃取、远程代码执行和敏感数据泄露等严重危害。党中央、国务院高度重视人工智能和产业链供应链发展，李强总理此前签署发布《国务院关于产业链供应链安全的规定》，该规定是我国首部产业链供应链安全领域的行政法规，为防范产业链供应链安全风险提供政策支撑。

中国信息通信研究院云计算与数字化研究所自2019年起，开展软件供应链治理研究工作，围绕开源安全、开发安全、软件物料清单（SBOM）、供应商管理等重点内容牵头制定国家、行业和团体标准二十余项，涵盖GB/T 43848-2024《网络安全技术软件产品开源代码安全评价方法》、《软件供应链安全管理要求》、《软件物料清单总体能力要求》、《可信研发运营安全能力成熟度要求》、《软件供应链供应商安全管理能力要求》等重点内容，具体工作架构图如下所示。

中国信通院软件供应链安全治理工作体系

此外，中国信息通信研究院依托云计算开源产业联盟于2022年牵头成立“3S-Lab软件供应链安全实验室”，目前已有八十余家成员单位，涵盖通信、金融、能源、汽车、软件、安全厂商等重点行业企业。实验室旨在联合政、产、学、研、用多方力量，助力软件供应链安全产业发展与推进。

目前依托实验室，中国信通院已开展十余场主题活动，形成《软件供应链安全发展洞察报告》、《软件物料清单发展洞察报告》、《开源安全发展洞察报告》等十余本研究报告，阐述软件供应链安全国内现状，企业软件供应链安全建设挑战，软件供应链建设愿景等重点问题，助力提升产业认知。结合行业研究与标准实践，企业软件供应链安全治理应聚焦开源治理、安全开发、供应商选型和软件物料清单（SBOM）四大要点，构建覆盖全生命周期的纵深防御体系。

一、开源治理：筑牢软件供应链安全的第一道防线

开源组件已成为现代软件开发的基石，但也成为供应链投毒的主要攻击面。攻击者通过篡改开源代码仓库源码、劫持开发者账号、污染软件安装包等方式，将恶意代码植入广泛使用的开源组件中，实现"一次投毒、批量感染"的放大效应。

（一）开源组件风险评估方法

企业应建立严格的开源组件准入机制，按照《网络安全技术软件产品开源代码安全评价方法》等国标要求，建立内部可信源，坚持从官方网站、主流开源社区等渠道获取组件，避免使用来源不明的开源组件。引入组件前，评估组件的活跃度、维护团队规模和社区声誉。对长期无人维护、来源不清、版本过旧的组件，应谨慎引入或及时替换。

（二）漏洞追踪机制

建立开源组件漏洞持续监控机制，对接国内外主流漏洞数据库和安全情报源，实现漏洞信息的实时推送与预警。当新漏洞披露时，通过软件资产管理平台、软件物料清单等系统快速定位受影响的业务系统，评估风险等级，并制定修复优先级。对于高风险漏洞，采取升级安全版本、临时防护措施或功能禁用等手段，降低被利用风险。

（三）许可证合规管理策略

开源许可证合规是开源治理的核心要求之一。企业应对引入的开源组件进行许可证类型识别，评估其传染性、商业使用限制等法律风险。避免在商业产品中引入强传染性许可证的组件，防止知识产权纠纷。

二、安全开发：将安全融入软件生命周期全流程

安全开发是软件供应链安全的内生保障。进入AI Coding时代，AI编程助手等工具大幅提升了开发效率，但也给软件供应链安全带来了新的挑战。AI编码中可能包含存在漏洞的代码、许可证不明确的开源代码片段，甚至被植入后门的恶意代码。软件工程的安全理念在AI时代同样适用，企业仍需践行安全左移理念，将安全要求嵌入软件开发全生命周期。

（一）代码安全审查流程设计

建立多层次的代码安全审查机制：一是借助Agentic代码安全相关工具，在编码阶段自动扫描源代码中的安全缺陷；二是开展软件成分分析（SCA），识别代码中引入的第三方开源组件及其漏洞；三是对核心业务逻辑、安全敏感模块进行二次审计。重点系统上线前，必须开展全面的代码安全检测、依赖项扫描和恶意代码排查。

（二）流水线中的安全卡点设置

在安全开发流程和CI/CD流水线的关键节点设置安全质量门禁，未通过安全检查的代码和中间产物不得进入下一环节。常见的安全卡点要求包括：安全设计的执行、代码提交前的安全扫描、构建阶段的依赖项漏洞检查、测试阶段的全面安全检测、制品入库前的安全审计、部署前的安全检查、配置核查等。

三、供应商选型：强化商采第三方供应链风险管控

企业依赖外部软件产品服务供应商获取解决方案，以满足其业务拓展、流程管理等方面需求已成为业界常态。从底层基础软件到上层应用软件，供应商提供的软件产品和服务贯穿企业价值链的各个环节，与企业安全生产、业务稳定运行等密切相关，供应商安全能力直接影响企业软件供应链整体安全水位。

（一）第三方供应商安全评估标准

建立系统化的供应商安全评估体系，从多个维度对供应商进行全面评估：一是安全能力成熟度，包括安全组织架构、安全制度流程、安全技术能力等；二是历史安全记录，核查供应商是否发生过重大安全事件、漏洞响应是否及时；三是供应链透明度，评估供应商能否提供其产品的组件构成、安全检测报告等信息。

（二）准入机制

将安全评估作为供应商准入的必要条件，未通过安全评估的供应商不得纳入采购范围。在采购商业软件、外包开发和技术服务时，应在合同中明确安全责任条款，包括但不限于：安全开发义务、漏洞修复时限、组件来源说明、数据保护责任、应急响应机制等。不能只重功能、不问安全，要将安全要求写入合同，以法律形式约束供应商的安全行为。

（三）持续监控体系

供应商安全管理不是一次性的准入评估，而是持续的动态监控过程。企业应建立供应商安全持续监控机制：定期开展供应商安全审计，验证其安全能力的持续性；要求供应商及时披露安全事件和重大漏洞；建立供应商安全评级体系，对评级下降的供应商采取预警、限期整改甚至淘汰等措施。

四、软件物料清单（SBOM）：提升供应链透明度的核心抓手

软件物料清单（Software Bill of Materials，SBOM）指软件成分列表，识别并列出了软件组件、相关组件的信息以及它们之间的供应链关系。软件物料清单自诞生之初便有明确目标，即提高软件组件及供应链透明度。软件物料清单提供了一组附加信息，把软件的组成成分和依赖关系等信息可视化，并统一记录管理，大大提升了软件供应链整体透明度，对于降低软件使用和维护成本，保障软件供应链安全具有重要意义。

（一）SBOM的构建方法

SBOM的构建应采用自动化工具与人工校验相结合的方式。自动化工具方面，可通过软件成分分析（SCA）工具等扫描源代码、二进制文件，自动识别其中的开源组件、商业组件及其版本信息。对于无法自动识别的自研组件、动态加载组件等，需要人工补充完善。SBOM应包含组件名称、版本号、供应商、许可证类型、依赖关系、哈希校验值等关键信息，确保信息的完整性与准确性。

（二）维护更新机制

SBOM不是静态文档，而是需要与软件版本同步更新的动态资产。企业应建立SBOM更新维护机制：软件每次版本发布时，同步生成对应版本的SBOM；当组件发生升级、替换或新增时，及时更新SBOM记录；对已发布的旧版本软件，也要保留其SBOM快照，以便历史版本的漏洞追溯。建议将SBOM的生成与维护纳入CI/CD流水线，实现自动化、流程化管理。

软件供应链安全治理是一个系统工程，需要各方长期持续的建设。人工智能时代，全球新一轮科技革命和产业变革加速演进，在软件供应链领域，从大语言模型的爆发式发展，到AI编程助手的广泛普及，人工智能正在从单纯的“辅助工具”演变为深度的“参与者”甚至“决策者”，极大提升了软件产业的生产效率，也随之带来复杂多元的安全风险与治理挑战。AI供应链不再局限于代码和组件，而是演变为涵盖数据、模型、工具的复杂系统。中国信通院相关团队紧跟技术趋势，围绕AI供应链、AI编程助手、Agentic代码安全等系列工具、智能体开发管理平台、智能体供应链等建立标准体系，实现从软件供应链向AI供应链的延伸与升级。