信息化时代软件成为社会运作基本组件，地位及其重要性不断提高。特别是数字中国建设的提出进一步强化了软件的地位，软件行业快速发展并通过软件定义快速融入生活的方方面面。随之而来的软件供应链安全问题也趋于复杂化和多样化，软件供应链安全问题已经成为一个全球性的问题。从软件生产者视角研究了软件供应链安全体系，并通过安全开发实践，提出了软件开发过程中保障软件供应链安全的开发方法。通过提供软件出生前的安全保障，尽可能地消除软件安全缺陷，确保向下游交付安全的软件，以保护软件供应链安全不受或者少受攻击。
《“十四五”软件和信息技术服务业发展 规划》指出，软件是新一代信息技术的灵魂， 是数字经济发展的基础，是制造强国、网络强国、 数字中国建设的关键支撑。 随着现代软件开发 过程的不断演进，以及新技术平台的出现，特 别是以开源为主的开发方式的出现，使得软件 供应链条变得越来越复杂，暴露给攻击者的攻 击面越来越多，攻击事件频发，从而对用户隐私、 财产乃至国家安全造成重大威胁。
软件成为支撑社会正常运转的基本组件的 同时，软件的安全问题也被认为是根本性、基础 性问题，保障软件供应链安全已经成为业界关 注的焦点，同时也成为企业的公共诉求。 Gartner 公司分析指出，“到 2025 年，全球 45% 组织的 软件供应链将遭受攻击，比 2021 年增加 3 倍”。
基于当前突出的软件供应链安全问题，本 文通过对业界软件供应链安全相关体系标准的 研究和借鉴，围绕国有大型企事业单位场景， 结合 DevSecOps 体系实践探索出一套融入企业 现有研发体系的安全开发方法，可为中大型国 有企事业单位的实践落地提供参考。 该安全开 发方法通过在开发过程中持续关注和融入安全， 保障软件出生前的安全。
1
背 景
2021 年，安全类垂直媒体“安全牛”发布 了第八版中国网络安全行业全景图，软件供应 链安全成为网络安全行业的重要一级分类。 数 说安全发布的《2022 年中国网络安全十大创新 方向》中，软件供应链安全与开发安全入围， 其发布的《2022 年中国网络安全市场年度报告》 显示，开发安全在 2021 年荣登安全行业融资额 同比增速榜首。 近几年，围绕软件供应链安全， 各国陆续出台相关法律法规、框架体系，逐步 规范并提升行业软件供应链安全良好生态。
国际上对软件供应链管理早已达成共识， 特别是美国在 2015 年发布了供应链风险管理标 准，2021 年美国总统拜登签署了第 14017 号《美 国供应链行政令》。 随着网络安全形势的不断 发展变化，我国在网络安全领域的重要法规频 频出台，头部的互联网企业和安全厂商也纷纷 投入软件供应链的安全建设中，持续构建符合 各企业的安全防护体系。
在我国，目前针对关键基础设施的软件提 供商主要集中在中大型国有企事业单位。 这些 企业因历史沿革和发展需要，均存在自有产品 体系多、技术体系覆盖面广、业务应用及环境 复杂、安全性要求高等特点，企业如何通过新 的平台技术持续提升研发效能的同时，加强软 件供应链安全性是当前普遍面临的问题。
２
业界软件供应链安全体系
本文主要对 4 个软件供应链安全及安全 开发体系进行了研究借鉴，包括美国国家标 准 与 技 术 研 究 院（National Institute of Standards and Technology，NIST） 发 布 的 软 件 开 发 安 全 框 架（Secure Software Development Framework， SSDF）、 互 联 网 安 全 中 心（Center for Internet Security，CIS）发布的软件供应链安全指南、 微软发布的安全供应链消费框架（Secure Supply Chain Consumption Framework，S2C2F）和中国信 通院发布的软件供应链安全标准体系。
2022 年，NIST 发 布 了 SSDF1.1 版 本， 该 框架致力于减少已发布软件中的漏洞数量，降 低未被发现或未解决的漏洞被利用时的潜在影 响，并从源头上解决漏洞问题，防止漏洞再次 发生 。
2022 年，CIS 发布了软件供应链安全指南 1.0 版本，该指南主要细化了从源码到交付全生命 周期的 100 多条管理和安全建议，其中包括源 代码、构建管道、依赖项、制品、部署全流程 主要环节。
微软发布的 S2C2F 主要专注于开发集成人 员对开源软件的使用安全。
中国信通院的软件供应链安全标准体系围 绕软件引入、生产、应用 3 大环节，建立了可 信研发运营安全能力成熟度模型（Trustworthy evaluation of Security maturity Model，TSM）、 软 件供应链安全保障要求、开源治理体系、软件物 料清单建设总体框架、DevSecOps 工具链 5 大重 要模块，构成了整个软件供应链安全管理标准。
目前，业界的软件供应链安全体系各有偏 重，信通院的软件供应链安全体系较为全面， 各体系仅能作为能力建设参考，企业在实际应 用场景的实践过程中还需要结合企业本身的实 际情况进行探索。
３
软件供应链安全解决方案
3.1 企业解决方案
软件供应链安全是解决软件研制生产整个 过程中的设计、编码、工具、设备、环境、供 应商以及最终交付等所面临的安全问题。 本文 提出的软件供应链安全解决方案框架如图 1 所 示。 解决方案主要以开发全生命周期安全融入 为核心，围绕开源安全、开发过程安全和开发 环境安全 3 个方面进行安全设计和实践。
图 1 软件供应链安全解决方案框架
3.2 安全开发流程
围绕解决方案，本文提出了开发全流程融 入安全工具和质量门禁后的安全开发全流程， 如图 2 所示。
图 2 安全开发全流程
安全开发全流程在实践过程中主要依托企 业原有的研发流程，在关键环节融入安全工具 和门限要求，通过安全融入实现从安全需求分 析、安全设计、安全编码、安全开发流水线、 安全测试、安全交付、持续反馈全流程的安全 活动开展和反馈闭环。
在 需 求 分 析 阶 段， 围 绕 公 司 业 务 的 特 殊 性，除了产品本身需要考虑一系列国家标准和 行业标准，还需结合如开放式 Web 应用程序 安全（Open Web Application Security Project， OWASP）组织发布的应用安全验证标准，详细 分析可能涉及的安全需求，确保开展各个层面的 安全需求分析，从需求源头保证业务应用安全。
在安全设计阶段，依托公司战略规划构建 一系列自带安全基因的基础软件硬件平台，各 产品可快速基于基础平台开发，让产品团队聚 焦业务功能，大幅提升产品研发效率、质量和 安全性。
在 安 全 编 码 阶 段， 建 立 各 类 开 发 语 言 的 安全编码规范，并使用统一安全合规的开发环 境、开发工具和开发资源，通过自动化流程和 工具进行门限控制。 例如，将安全编码规范规 则配置到集成开发环境（Integrated Development Environment，IDE）中，通过代码提交前的自动 检查和阻断控制源代码的质量和安全性。
在安全开发流水线阶段，一方面，建成基 于 DevSecOps 黄金管道的全环节安全自动化检 测工具； 另一方面，基于企业复杂的产品体系 建立了多样化的标准编译环境，可通过流水线 配置自动化分配，提升产品编译环境的安全管 控能力。
在安全测试阶段，每个产品版本都必须经 过专项的安全测试，包括但不限于主机安全、 通信安全、客户端安全、数据安全、Web 安全、 业务安全合规、云安全、测评机构要求等各类 针对业务的安全测试，通过全面的测试进一步 保证制品的安全性。
在安全交付阶段，一方面，针对专网用户， 由工程售后人员对部署交付物进行完整性校验， 确保交付物来源可靠安全后才执行用户环境部 署并上线； 另一方面，在公司内网建立产品验 证试验田，将涉及传输安全、边界安全、安全 管理、身份安全、安全应用等方面的产品应用 于公司生产环境，在产品定版归档后，通过自 动化流水线自动发布到公司环境，快速试用进 而发现问题，进一步提升产品的安全可靠性。
在产品交付后的问题反馈阶段，建立多种 产品反馈渠道，使用户及公司市场人员、工程 实施人员、售后人员可以通过如移动端产品反 馈入口快速反馈产品问题，并打通移动端与研 发管理工具平台的自动化转入和反馈处理，实 现产品反馈问题的快速闭环。
在整个安全开发流程中严格执行安全质量 门限卡点，例如，在需求分析和安全设计阶段， 必须进行组织级需求评审和设计评审，评审人 员应包括安全技术专家和业务安全专家，共同 把关产品安全需求和设计的合理性。 在开发阶 段，代码提交前必须通过 IDE 质量门禁以及代 码人工审查。 在安全开发流水线环节，通过各 环节门禁卡点控制产品安全质量，控制风险软 件的发布，在自动归档环节对制品包再次进行 病毒扫描等，通过关键环节的安全门禁控制持 续提升产品交付后的安全可靠性。
4
安全开发实践
安全开发是指通过开发全生命周期的每个 阶段都从安全的角度指导开发，将安全融入开 发过程，全面保障软件供应链安全。 在实践上 重点推进了开发环境安全、开源安全和安全工 具链 3 个方面。
4.1 开发环境安全
在软件开发过程中，需要借助提前准备的 开发环境、开发工具编码实现业务功能，代码实 现后需要提交到统一的代码存储平台进行管理， 并借助持续集成（Continuous Integration，CI）、 持续交付（Continuous Delivery，CD）环境和工 具执行集成构建打包，如果过程中使用了不安 全的环境和工具，会导致代码存在被篡改、恶 意植入等安全问题。
针对大型国有企事业单位产品体系和业务 复杂性的特点，一方面，为保障软件开发环境安 全，首先需要厘清环境类别，从开发语言、编 译构建依赖环境、编译构建工具、制品形态等 方面的差异性，将环境分为以 C/C++ 开发为主 的设备类环境、以 JAVA 开发为主的软件类环境、 以 Python 开发为主的数据类环境、以 Windows 终端和移动端为主的终端类环境、以 go 开发为 主的云原生基础设施类环境，通过梳理形成规 范化的分类模板。 另外，根据各开发过程不同 环节的差异性，形成开发类、编译构建类、调 测类 3 类不同需求的标准环境模板，并持续根 据开发架构的升级同步更新环境及各类工具， 保证环境的可管理性和维护性。 通过环境模板 的版本化管理和基于模板自动创建使用能力提 升开发过程环境一致性、规范性，保证开发工 具来源安全合规、使用可靠统一。 另一方面， 为保障核心资产的安全、可靠管理和存储，企 业需要统一建设内部私有化且配置安全防护及 容灾策略的代码存储平台和持续集成平台，并 通过定期安全扫描等多种方式保障工具平台环 境安全性。
4.2 开源安全
Gartner 公 司 表 示， 现 代 软 件 大 多 数 是 被 “ 组 装” 出 来 的， 不 是 被“ 开 发 出 来 的”， 80% ～ 90% 的代码来自开源软件。 如何正确 使用开源软件，规避因开源漏洞、许可证和政 治因素导致的开源风险，是企业共同面临的现 实问题。
针对持续高发的开源安全问题，各企业应 逐步建立企业内部的开源治理体系，以保障开 源组件、框架的稳健性，提高企业对开源组件 的维护、修复和应对能力。 企业开源治理体系 的目标主要包括 4 个方面： 摸清企业所有开源 组件的使用情况； 定义企业开源组件使用质量 标准； 尽可能地通过工具实现自动化监测和跟 踪； 提升开源组件漏洞的快速响应能力。
基于上述目标，各企业需要建立一套符合 本企业应用场景的开源组件全生命周期管理工 具、流程和规范，形成从组件引入、使用、应 急处理、归档到停用下线全流程的开源组件管 理规范要求，开源组件全生命周期管理流程如 图 3 所示。
图 3 开源组件全生命周期管理流程
同时，基于管理规范建立配套的工具平台 支撑规范落地。 为减少运维及规范管控环节的 人力投入和可能出现的问题，建议企业将开源 组件扫描、审查及管理工具逐步融入 DevSecOps 工 具 平 台 中， 通 过 如 CI/CD 流 水 线 能 力 将 各 工具系统串联的同时，持续将管理要求和相 关质量门禁工具化、自动化落实到日常开发 过程中。
4.2.1 严格控制开源组件引入
各企业应逐步控制和收敛开源组件的引入， 通过开发框架、开发平台的规范化梳理形成企 业自有的开源组件白名单，并结合开发框架和 项目脚手架工程在基础开发平台中预置基础框 架白名单组件，方便同类产品直接复用框架和 白名单组件。 同时，依托最小化引入原则对非 白名单组件的引入建立严格的审查机制。 一方 面，通过便捷的自动化工具及时规避安全漏洞 及因协议不合规带来的知识产权问题； 另一方 面，结合技术和业务评判组件引入的必要性， 通过严格的引入评审对漏洞可利用性、漏洞影 响范围、漏洞组件可替代性进行评估，对于无 可替换的问题组件需要结合产品业务分析漏洞 利用可规避的措施及触发条件等严格审核后才 能引入。
在管理上，确保引入的开源组件是由专业 团队根据引入的组件清单从可信来源下载并导 入企业统一的安全合规组件库，进而形成组织 级安全合规组件资产清单。
4.2.2 严格把控产品构建和归档环节组件来源 安全合规
持续加强产品集成和归档环节开源组件 的安全合规性。 各企业需要在已有 DevSecOps 流 水 线 环 节 中 增 加 软 件 成 分 分 析（Software Composition Analysis，SCA）检测工具和组件来 源检查工具，一方面，持续对产品引用组件的 漏洞风险进行评估； 另一方面，通过组件来源 检查确保产品对外交付的第三方组件均来源于 组织级的安全合规组件资产库，进一步确保对 外交付的开源组件的安全合规性。
4.2.3 通过 SBOM 提高软件透明度
围 绕 软 件 组 成 成 分 方 面， 各 企 业 应 逐 步 根据企业实际情况，定义形成适合自己企业标 准的软件物料清单（Software Bill of Materials， SBOM），并通过开发全流程逐步实现对软件全 生命周期 SBOM 生成、更新和归档标识，形成 透明的软件组成成分使用、流转和交付全流程 自动化审查控制，通过对 SBOM 进行流程化、 工具化的管理，可持续支撑对 0day 漏洞组件进 行快速定位和应急响应。
SBOM 管理在产业界已有一些标准和工具， 在实践中需要持续依托 CI/CD 流水线，通过在 流水线中集成适合的工具，可自动化、持续地 生成和更新软件 SBOM 清单。 例如，在开发阶段， 通过流水线自动化生成 SBOM 清单并标识出新 引入的组件和存在的问题； 在提交测试的流水 线中自动生成 SBOM 并与安全合规组件库进行 来源验证； 在归档环节自动生成 SBOM 并归入 配置库，同时将 SBOM 导入组织级组件管理系统， 方便在后续发现 0day 漏洞时能够基于组件管理 系统进行快速的影响面分析，提升应急响应的 执行效率。
除逐步建立上述对开源组件进行全生命周 期管理体系外，各企业还需重点推进存量开源 组件资产盘点，通过盘点形成组织级组件白名 单，同时在盘点过程中逐步清理冗余组件，通 过阶段性的清库存工作逐步建立企业开源组件 资产清单，摸清企业开源组件的实际使用情况， 形成软件安全合规基线。
基于以上的实践，基本实现了开源组件全 生命周期管理工具化和自动化，并将工具融入 开发流程，可提升企业开源组件安全应对能力， 规避开源组件引入使用带来的安全风险。
4.3 安全工具链
安全工具链即围绕业界 DevSecOps 工具平 台体系实践和落地后形成的从代码提交后触发 全流程安全工具扫描审查的自动化流水线。 DevSecOps 是由 Gartner 公司于 2016 年提出的框 架，将威胁建模工具、安全编码工具、安全测 试工具、容器安全检测工具、基线加固工具、 漏洞管理工具等自动化无缝集成到 DevOps 流程 中，实现开发—安全—运营一体化 。
在持续保障和提升软件供应链安全应对能 力方面，企业应建立自己的安全开发流程和工 具体系，通过安全开发流水线支撑安全开发体 系落地。 安全开发流水线除了利用常规的 CI/CD 环节提升编译构建效率，在安全方面也应该围 绕安全质量指标融入包括病毒、静态应用程序 安 全 测 试（Static Application Security Testing， SAST）、SCA、动态应用程序安全测试（Dynamic Application Security Testing，DAST）、交互式应 用程序安全测试（Interactive Application Security Testing，IAST）、容器安全等多环节工具。 考虑 到各企业安全需求的差异性及业务应用场景的 复杂性，建议各企业结合商业工具、开源工具 和自研发工具等多种工具形成互补，从多个方 面对开发人员提交的代码进行全面安全分析和 检测，并将发现的问题前置到开发阶段解决， 实现工具链门限管控真正的安全左移。
安全开发流水线的应用场景应结合不同团 队人员角色的质量把关需求设置不同的环节和 门禁要求。 在大类上可以设置开发人员、研发 负责人和测试负责人等不同角色形成针对不同 安全要求的多场景流水线，通过不同角色的安 全质量要求设置不同门禁，实现不同场景的安 全质量控制，全面提升产品开发过程安全性。
在支撑组织级安全开发流程落地到安全开 发流水线后，应持续提升流水线的可自助式编 排和可视化能力。 一方面，应提供更方便易用 的编排工具，方便产品团队根据自身需求自助 式地定义项目自身的流水线环节和项目级门禁要 求； 另一方面，对不同环节和门禁的构建结果进 行统一的可视化展示，进一步对发现的问题进行 全流程闭环，持续提升产品的质量和安全性。
5
特色做法
在整个安全开发全流程落地过程中更强调 过程控制的工具自动化能力，入库管控更严格， 出口管控更精细。
5.1 开发流程各环节的管控工具化
开发流程各环节的安全控制工具化主要体 现在以下 3 个方面。
（1）开发环境模板化、流程化、工具自助化， 通过将企业各类复杂产品类型所依赖的开发环 境梳理形成模板，并依托业务流程系统实现按 需申请，自助化生成使用，保障了各类环境的 安全可靠性。
（2）开发了一系列工具实现对开源组件和 商采组件的工具化、自动化管控，并基于 SBOM 实现对组件从引入、使用、应急处理、归档和 停用下线的全流程管理。
（3）实现了复杂产品研制体系下，各种类 型产品从源代码提交触发流水线自动化构建部 署，并融入了包括病毒、静态代码扫描、组件 漏洞扫描、组件来源合规、动态应用程序扫描、 容器安全扫描等环节的安全工具链，通过多环 节、多工具的安全扫描审查自动化实现安全问 题早发现、早解决。
5.2 开源及第三方软件和组件入库管控更严格
对开发过程中使用的开源及第三方软件和 组件引入进行严格管控。 一方面，通过梳理形 成各类标准的开发工具、开发组件、部署组件 白名单，在开发过程中通过工具化和人工审查 等多种方式确保使用白名单软件和组件； 另一 方面，对于引入的软件或组件遵循最小化引入 原则、安全合规可控原则和业务必要性原则， 必须进行严格评审后才能引入，以保证各产品 开发过程工具和组件的安全可信可控。
5.3 实现出口精细化管控
针对开发过程中各种可能引入的开源组件 和开源代码的情况，开发实现了针对制品包检 查的工具，并集成到归档流水线中，通过将制 品包逐层分解后，对每个组成进行特征码提取 和识别的方式严格追溯制品包中引入的开源及 第三方组件来源于安全合规仓库，通过来源卡 点保证了交付到用户环境的制品成分安全可信。
6
实践效果
基于以上实践基本建立了企业实际可落地 实施的安全开发流程和软件供应链安全体系， 通过安全开发流水线强控安全门限，将安全问 题前置到开发阶段解决，极大地降低了交付用 户后安全事件发生的频率，一定程度上提升了 产品质量与安全性。 目前，该体系已通过中国 信通院 TSM 可信研发运营安全能力成熟度模型 增强级测评。
7
结 语
软件供应链安全涉及软件研制的全生命周 期，开发安全是核心。 针对软件开发过程除保 障环境安全、开源组件引入使用安全，并通过 工具链将安全问题发现前置到开发阶段外，各 企业应加强围绕业务的开发全流程安全融入， 并通过创新技术和方法提升安全能力，真正实 现软件内生安全。
随着 GB/T 39204—2022《信息安全技术 关 键信息基础设施安全保护要求》等标准的发布 实施，对软件厂商的产品安全要求将更为严格。 作为软件供应链安全的上游厂商应积极加强软 件供应链安全相关标准体系研究和安全开发标 准体系建设，确保向下游交付安全性良好的软 件，积极应对软件供应链安全带来的一系列安 全威胁。
免责声明： 本文转自信息安全与通信保密杂志社，原作者吴汝钰 , 袁忠 , 付玲玲 。 文章内容系原作者个人观点，本公众号编译/转载仅为分享、传达不同观点，如有任何异议，欢迎联系我们！
转自 丨信息安全与通信保密杂志社
作者 丨吴汝钰 , 袁忠 , 付玲玲
研究所简介
国际技术经济研究所（IITE）成立于1985年11月，是隶属于国务院发展研究中心的非营利性研究机构，主要职能是研究我国经济、科技社会发展中的重大政策性、战略性、前瞻性问题，跟踪和分析世界科技、经济发展态势，为中央和有关部委提供决策咨询服务。“全球技术地图”为国际技术经济研究所官方微信账号，致力于向公众传递前沿技术资讯和科技创新洞见。
地址：北京市海淀区小南庄20号楼A座
电话：010-82635522
微信：iite_er
