软件供应链安全视角下的安全开发研究和应用*

吴汝钰，袁 忠，付玲玲

（中电科网络安全科技股份有限公司，四川 成都 610041）

0 引 言

《“十四五”软件和信息技术服务业发展规划》指出，软件是新一代信息技术的灵魂，是数字经济发展的基础，是制造强国、网络强国、数字中国建设的关键支撑。随着现代软件开发过程的不断演进，以及新技术平台的出现，特别是以开源为主的开发方式的出现，使得软件供应链条变得越来越复杂，暴露给攻击者的攻击面越来越多，攻击事件频发，从而对用户隐私、财产乃至国家安全造成重大威胁。

软件成为支撑社会正常运转的基本组件的同时，软件的安全问题也被认为是根本性、基础性问题，保障软件供应链安全已经成为业界关注的焦点，同时也成为企业的公共诉求。Gartner公司分析指出，“到2025 年，全球45%组织的软件供应链将遭受攻击，比2021 年增加3 倍”[1]。

基于当前突出的软件供应链安全问题，本文通过对业界软件供应链安全相关体系标准的研究和借鉴，围绕国有大型企事业单位场景，结合DevSecOps 体系实践探索出一套融入企业现有研发体系的安全开发方法，可为中大型国有企事业单位的实践落地提供参考。该安全开发方法通过在开发过程中持续关注和融入安全，保障软件出生前的安全。

1 背景

2021 年，安全类垂直媒体“安全牛”发布了第八版中国网络安全行业全景图，软件供应链安全成为网络安全行业的重要一级分类。数说安全发布的《2022 年中国网络安全十大创新方向》中，软件供应链安全与开发安全入围，其发布的《2022 年中国网络安全市场年度报告》显示，开发安全在2021 年荣登安全行业融资额同比增速榜首。近几年，围绕软件供应链安全，各国陆续出台相关法律法规、框架体系，逐步规范并提升行业软件供应链安全良好生态。

国际上对软件供应链管理早已达成共识，特别是美国在2015 年发布了供应链风险管理标准，2021 年美国总统拜登签署了第14017 号《美国供应链行政令》。随着网络安全形势的不断发展变化，我国在网络安全领域的重要法规频频出台，头部的互联网企业和安全厂商也纷纷投入软件供应链的安全建设中，持续构建符合各企业的安全防护体系。

在我国，目前针对关键基础设施的软件提供商主要集中在中大型国有企事业单位。这些企业因历史沿革和发展需要，均存在自有产品体系多、技术体系覆盖面广、业务应用及环境复杂、安全性要求高等特点，企业如何通过新的平台技术持续提升研发效能的同时，加强软件供应链安全性是当前普遍面临的问题。

2 业界软件供应链安全体系

本文主要对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 版本，该框架致力于减少已发布软件中的漏洞数量，降低未被发现或未解决的漏洞被利用时的潜在影响，并从源头上解决漏洞问题，防止漏洞再次发生[2]。

2022 年，CIS 发布了软件供应链安全指南1.0版本，该指南主要细化了从源码到交付全生命周期的100 多条管理和安全建议，其中包括源代码、构建管道、依赖项、制品、部署全流程主要环节。

微软发布的S2C2F 主要专注于开发集成人员对开源软件的使用安全。

中国信通院的软件供应链安全标准体系围绕软件引入、生产、应用3 大环节，建立了可信研发运营安全能力成熟度模型（Trustworthy evaluation of Security maturity Model，TSM）、软件供应链安全保障要求、开源治理体系、软件物料清单建设总体框架、DevSecOps 工具链5 大重要模块，构成了整个软件供应链安全管理标准。

目前，业界的软件供应链安全体系各有偏重，信通院的软件供应链安全体系较为全面，各体系仅能作为能力建设参考，企业在实际应用场景的实践过程中还需要结合企业本身的实际情况进行探索。

3 软件供应链安全解决方案

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）环境和工具执行集成构建打包，如果过程中使用了不安全的环境和工具，会导致代码存在被篡改、恶意植入等安全问题[3]。

针对大型国有企事业单位产品体系和业务复杂性的特点，一方面，为保障软件开发环境安全，首先需要厘清环境类别，从开发语言、编译构建依赖环境、编译构建工具、制品形态等方面的差异性，将环境分为以C/C++开发为主的设备类环境、以JAVA 开发为主的软件类环境、以Python 开发为主的数据类环境、以Windows终端和移动端为主的终端类环境、以go 开发为主的云原生基础设施类环境，通过梳理形成规范化的分类模板。另外，根据各开发过程不同环节的差异性，形成开发类、编译构建类、调测类3 类不同需求的标准环境模板，并持续根据开发架构的升级同步更新环境及各类工具，保证环境的可管理性和维护性。通过环境模板的版本化管理和基于模板自动创建使用能力提升开发过程环境一致性、规范性，保证开发工具来源安全合规、使用可靠统一。另一方面，为保障核心资产的安全、可靠管理和存储，企业需要统一建设内部私有化且配置安全防护及容灾策略的代码存储平台和持续集成平台，并通过定期安全扫描等多种方式保障工具平台环境安全性。

4.2 开源安全

Gartner 公司表示，现代软件大多数是被“组装”出来的，不是被“开发出来的”，80%～90%的代码来自开源软件[4]。如何正确使用开源软件，规避因开源漏洞、许可证和政治因素导致的开源风险，是企业共同面临的现实问题。

针对持续高发的开源安全问题，各企业应逐步建立企业内部的开源治理体系，以保障开源组件、框架的稳健性，提高企业对开源组件的维护、修复和应对能力。企业开源治理体系的目标主要包括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 流程中，实现开发—安全—运营一体化[5]。

在持续保障和提升软件供应链安全应对能力方面，企业应建立自己的安全开发流程和工具体系，通过安全开发流水线支撑安全开发体系落地。安全开发流水线除了利用常规的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《信息安全技术 关键信息基础设施安全保护要求》等标准的发布实施，对软件厂商的产品安全要求将更为严格。作为软件供应链安全的上游厂商应积极加强软件供应链安全相关标准体系研究和安全开发标准体系建设，确保向下游交付安全性良好的软件，积极应对软件供应链安全带来的一系列安全威胁。