随着容器、微服务等新技术日新月异，开源软件成为业界主流形态，软件行业快速发展。但同时，软件供应链也越来越趋于复杂化和多样化，软件供应链安全风险不断加剧，针对软件供应链薄弱环节的网络攻击随之增加，软件供应链成为影响软件安全的关键因素之一。近年来，全球针对软件供应链的安全事件频发，影响巨大，软件供应链安全已然成为一个全球性问题。全面、高效地保障软件供应链的安全对于我国软件行业发展、数字化进程推进具有重要意义。

近日，在由中国信通院指导、悬镜安全主办的中国首届DevSecOps敏捷安全大会（DSO 2021）现场，《软件供应链安全白皮书（2021）》（以下简称“白皮书”）正式发布。本白皮书着重分析了软件供应链安全，梳理了软件供应链的安全现状，透过现状全面剖析软件供应链的安全风险及面临的安全挑战，有针对性地提出如何对软件供应链的安全风险进行防范与治理，系统阐述了软件供应链安全的防护体系及软件供应链安全的应用实践以供参考，最后白皮书结合现在软件供应链安全的发展趋势进行了全面的分析及展望。

由于篇幅有限，仅摘选本报告“软件供应链安全治理”及“软件供应链应用实践”两部分进行分享。

图：《软件供应链安全白皮书》封面

目前，业界已充分认识到造成网络安全事件出现的主要原因之一，是由于软件开发者在开发过程中对开发工具、开发团队、开发生命周期和软件产品自身管理不当，致使软件存在着安全缺陷，破坏或影响最终用户的信息安全。

通过推进针对软件生命周期进行全流程安全管控的落地实践，有助于从软件生命周期的源头保障软件供应链安全。通过建立软件开发过程中保证软件供应链安全的体系化方法，为软件开发过程中尽可能避免和消除软件的安全缺陷、保证软件供应链安全奠定重要基础。

从软件安全开发生命周期角度分析软件供应链安全的应用实践方法，主要有以下几个阶段。

1、体系构建阶段

SDL 软件安全开发生命周期

微软在21世纪初期的软件产品开发实践中，意识到无法通过技术层面彻底解决软件面临的安全风险。因此，微软尝试从流程和管理的角度解决这个问题，并探索在各个软件开发环节中加入安全过程、把控安全风险，确保每个环节交付到下一环节的交付物都安全可控。于是，针对传统的瀑布式模型微软提出了“SDL 软件安全开发生命周期” 这一概念。

软件安全开发生命周期（SDL），是一个在帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。SDL将软件开发生命周期划分为7 个阶段（如图所示），并提出了 17 项重要的安全活动，旨在将安全集成在软件开发的每一个阶段，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。SDL更侧重的是软件开发的安全保障过程，旨在开发出安全的软件产品。

图 1 SDL 软件安全开发生命周期

在 SDL 的 7 个阶段中（如图 1所示），SDL 要求前 6 个阶段的 16 项安全活动，为开发团队必须完成的安全活动。 同时，SDL 认为开发团队应该保持灵活性，以便选择更多合适的安全活动，如人工代码分析、渗透测试、相似应 用程序的漏洞分析，以确保对某些软件组件进行更高级别的安全分析。SDL 重视各种工具的使用，重心在从需求阶段到测试阶段的工具集，如威胁建模、静态源代码分析等工具。

SDL 的 7 个阶段主要的含义如下：

培训：针对开发团队进行安全意识与能力的培训，以确保 SDL 能有效实施并落地，同时针对新的安全问题与形势 持续提升团队的安全能力；

需求：通过安全需求分析，定义软件产品安全实现过程中所需要的安全标准和相关要求；

设计：通过分析攻击面，设计相对应的功能和策略，降低和减少不必要的安全风险。同时通过威胁建模，分析软 件的安全威胁，提出缓解措施；

实施：按设计要求，实现对应功能和策略，以及缓解措施涉及的安全功能和策略。同时通过安全编码和禁用不安 全的 API，减少实施时导致的安全问题，尽量避免引入编码级的安全漏洞，并通过代码审计等措施来确保安全编码规范的实行；

验证：通过安全测试检测软件的安全漏洞，并全面核查攻击面，各个关键因素上的威胁缓解措施是否得以验证；

发布：建立相应的响应计划，进行最终安全检查，确认所有安全活动均完成后将最终版本发送给客户；

响应：当出现安全事件与漏洞报告时，及时实施应急响应和漏洞修复。在此过程中新发现的问题和安全问题模式，可用于 SDL 的持续改进过程中。

DevSecOps

DevSecOps 是一种全新的安全理念和模式，由 DevOps 的概念延伸和演变而来。其核心理念是安全是整个 IT 团队 每个人的责任，需要贯穿从开发到运营整个业务生命周期每一个环节才能提供有效保障。

DevSecOps 覆盖编码阶段、测试阶段、预发布阶段、发布阶段、线上运营阶段，强调自动化与平台化，由 CI/CD 平台推动整个开发和运营流程自动化。DevSecOps 依赖于 DevOps 流程工具链（如图 2 所示），将威胁建模工具、安全编码工具、安全测试工具、容器安全检测工具、基线加固工具、漏洞管理工具等自动化工具无缝集成到 DevOps 流程中，进而实现开发 – 安全 – 运营一体化。

图 2 DevSecOps 工具链

很多企业在向 DevSecOps 转型时，会发现很多传统的安全工具在集成性和实用性上都难以满足 DevSecOps 的需求， 因此，在 DevSecOps 的不同阶段需要采用不同的 DevSecOps 安全工具（如图 3 所示），这些安全工具主要的共同特点是高度自动化以及可集成性。

图 3 DevSecOps 安全工具在不同阶段的自动化程度

在软件供应链中每个阶段都在面临不同的安全风险，为了更好的对软件供应链进行风险治理，在 DevSecOps 模式 下，安全开发工具链需要尽量覆盖软件生命周期中的所有阶段（如图 4 所示）。

图 4DevSecOps 模式下软件生命周期

除了以上所提到的工具之外，在 DevSecOps 的应用实践过程中，还有一些更为前瞻性的安全工具，具体可参考 DevSecOps 敏捷安全技术金字塔（如图 5所示）。该金字塔在《2020 DevSecOps 行业洞察报告》中首次被提出， 目前已发展到 2.0 版本。其描述了一组层次结构，金字塔底部是基础性技术，越上层的技术对 DevSecOps 实践成 熟度的要求越高。

图 5 DevSecOps 敏捷安全技术金字塔 V2.0 版

DevSecOps 敏捷安全技术金字塔的不断升级，是为了给业界更好的预测和参考，关于 DevSecOps 敏捷安全技术 未来演进方向的预测是开放且持续性的，随着 DevSecOps 实践的不断发展，其中的安全工具会进行调整和更新。

2、设计阶段

软件供应商风险管理流程

软件供应商风险是指与第三方供应商相关的任何可能影响企业利益或资产的固有风险。在选择第三方软件供应商 时，为了避免因引入第三方供应商而带来众多潜在的安全风险，需要稳健的流程来识别和管理日益增加的软件供 应商风险。因此，企业亟需构建有效且稳健的软件供应商风险管理流程。

构建完整的软件供应商风险管理流程可以提高软件供应链的透明度，同时帮助企业实现降低采购成本、识别和减 轻供应商相关风险以及对软件供应商风险管理系统的持续优化改进。以下是针对软件供应商基本风险管理流程（如 图 6所示）。

图 6 软件供应商风险管理流程

标准确立：结合企业的实际情况，构建软件供应商评估模型，制定软件供应商考核的评估标准及安全框架；

资格评估：根据制定的软件供应商评估模型和相关标准，对初步符合要求的软件供应商进行多维度的综合性资格评估，选出匹配度最高的供应商；

风险评估：对通过资格评估的软件供应商进行安全风险评估，针对软件供应商面临的潜在的安全风险、存在的弱点 以及有可能造成的影响综合分析其可能带来的安全风险进行评估；

风险监控：对软件供应商实施长期性的安全风险监控，持续识别和管理软件供应商的安全风险，根据监测结果实施更新软件供应商的风险管理策略。

软件供应商评估模型

为了确保企业可以拥有较为稳定的供应链，提高企业的综合竞争力，经过多方面的综合考察分析，以下构建了一 个系统化、结构化的软件供应商评估模型以供参考。软件供应商评估模型的关键意义在于从不同的维度对软件供 应商进行评估，通过考察软件供应商的综合实力，以选择最合适的合作伙伴。以下是通过十二种不同维度对软件 供应商评估的全过程（如图 7所示）。

图 7 软件供应商评估模型

财务实力：评估软件供应商的财务能力以及稳定性，确保供应商具有稳定性和可靠性来提供业务所需要的服务；

质量承诺：评估软件供应商的相关软件产品是否符合国家及行业标准要求，信息安全和数据保护控制流程必须遵 守法律、监管或合同义务以及任何行业标准的信息安全要求；

企业资质：评估软件供应链上的第三方供应商是否能够提供软件安全开发能力的企业级资质，是否具备国际、国家或行业的安全开发资质，在软件安全开发的过程管理、质量管理、配置管理、人员能力等方面是否具备一定的经验，具有把安全融入软件开发过程的能力；

技术储备：评估软件供应商是否拥有自主研发能力以及自主技术知识产权，对科技知识是否有进行不断的积累和及时更新，对企业提高技术水平、促进软件生产发展是否有开展一系列的技术研究；

合作能力：评估软件供应商是否拥有高效的沟通渠道以及全面的解决方案，拥有共同的价值观和工作理念有助于建立长期的合作关系；

软件交付能力：评估软件供应商在整个软件及信息服务交付的过程中，是否能满足软件持续性交付的要求；

应急响应能力：评估软件供应商从软件开发到运营阶段是否持续实行实时监控机制，是否有利用适当的网络和基 于端点的控制来收集用户活动、异常、故障和事件的安全日志，是否具有适当的业务连续性和恢复能力，以防止或减轻业务中断和相关影响；

服务能力：评估软件供应商的售前服务能力、培训服务能力以及售后维护服务能力是否满足企业的要求，在合作 期间内是否可以始终如一的提供高水平的质量和服务；

创新能力：评估软件供应商的综合创新能力，包括技术创新能力、研究开发能力、产品创新能力以及生产创造力等；

内部管理能力：评估软件供应商是否拥有完善的内部管理制度流程、有效的风险防范机制以及是否对员工定期进行安全培训等，对供应商内部安全开发标准和规范进行审查，要求其能够对开发软件的不同应用场景、不同架构设计、不同开发语言进行规范约束，审查软件供应商对其自身信息安全保密程度；

软件成本：评估软件供应商所提供的软件成本是否存在虚报等现象，审查产品及相关服务是否可以按照合理的价格交付；

软件适用性：评估软件在开发部署以及动态运行时的适用性，是否可以持续满足新的需求。

软件供应商风险管理的作用

通过对软件供应商风险管理有助于企业更加高效准确地控制软件供应商带来的新的安全风险，以下是软件供应商 风险管理的具体作用。

降低风险：通过对软件供应商进行彻底的审查可以识别其可能对业务构成的安全威胁的任何潜在弱点，根据软件供应商对企业业务的影响确定漏洞的重要性；

降低成本：通过对软件供应商风险进行充分的评估，可以以主动而非被动的方式应对安全威胁，减少潜在的安全风险，避免网络安全攻击或其他数据泄露等问题给企业造成的财务损失；

提高效率：通过对软件供应商进行实时风险监控，可以提前预知风险并及时做出响应，提高企业处理安全风险的 效率；

培养长期合作关系：通过对供应商风险的管理、评估和跟踪监控，加强对供应商健康状况的监督，有助于培养可靠的长期合作关系。

3、编码阶段

构建详细的软件物料清单

软件供应链安全始于对关键环节的可见性，企业需要为每个应用程序持续构建详细的 SBOM（Software Bill of Material，软件物料清单）（如表 2 所示），从而全面洞察每个应用软件的组件情况。SBOM 是描述软件包依赖树 的一系列元数据，包括供应商、版本号和组件名称等多项关键信息，这些信息在分析软件安全漏洞时发挥着重要作用。

表 1 软件物料清单示例

上表是一份软件物料清单示例，其中 SPDX 和 SWID 是两种国际通用的 SBOM 字段标准。SPDX（The Software Package Data Exchange，软件包数据交换）是 Linux 基金会下的开放性标准，其用于交流软件物料清单信息，包括组件、许可证、版权等信息。SPDX 通过为公司和社区共享重要数据提供通用格式来减少冗余工作，从而简化 流程并提高合规性。SWID（Software Identification，软件标识）标签旨在为组织提供一种透明的方式来跟踪在他们的托管设备商安装的软件，它于 2012 年由 ISO 提出，并于 2015 年更新为 ISO/IEC 19770-2:2015。

SWID 标 签文件包含有关软件产品特定版本详尽的描述性信息。除表格中的两种应用最为广泛的 SBOM 字段标准外，还有 CycloneDX、CoSWID、CPE、Grafeas 等其他较为常见的标准，各标准的应用场景存在一定的区别。

SBOM 的概念源自制造业，其中物料清单是详细说明产品中包含的所有项目的清单。例如：在汽车行业，制造商会 为每辆车维护一份详细的材料清单。此 BOM 列出了原始设备制造商自己制造的零件和第三方供应商的零件。当发现有缺陷的部件时，汽车制造商可以准确地知道哪些车辆受到影响，并可以通知车主维修或更换。

同样，构建软件的企业也需要维护准确、最新的 SBOM，其中包括第三方和开源组件的清单，以确保其代码质量高、合规且安全。企业通过要求软件供应商提供 SBOM，以发现潜在的安全和许可证问题，或者应用程序是否使用过 时的库版本。

当发现此类问题时，管理员可以要求供应商使用较新版本重建应用程序，在等待更新的软件期间，安全人员有机会采取临时缓解措施来保护应用程序免受攻击者利用该漏洞进行攻击，还可以帮助安全人员在漏洞 被披露或核心库发布新版本时 , 对应用程序和代码进行抽查以避免出现安全问题。

举个例子：如果安全人员手中有一份在其环境中运行的每个应用程序的物料清单，那么早在 2014 年 4 月，当 Heartbleed 漏洞最初被披露时，安全人员就无需测试每个应用程序中是否包含 OpenSSL，而是可以通过检查列表 就立即知道哪些应用程序依赖于易受攻击的版本和需要采取的措施。

SBOM 生产流程

在成熟的体系下，SBOM 的生产可以通过软件生命周期每个阶段所使用的工具和任务流程化地完成，这些工具和 任务包括知识产权审计、采购管理、许可证管理、代码扫描、版本控制系统、编译器、构建工具、CI/CD 工具、包 管理器和版本库管理工具等（如图 8 所示）。

图8 SBOM 生产流程

SBOM 中应该包含软件组件与此组件所依赖的任何其他基础软件组件之间的关系。软件产品在发布任何版本时， SBOM 都应作为产品文档的一部分被提供，在 CI/CD 的标准实践中，SBOM 中包含的信息将不断更新。它从在需求中集成安全性需求开始，或者是 SBOM 中的一些元素已经在需求阶段被添加到用例中，这样安全性和 SBOM 就可以成为 DevOps 过程的标准和结构化的一部分。

为了确保持续一致性，应在测试工作中将 SBOM 作为测试用例的一部分，同时 SBOM 信息应随着使用工具和组 件的更新而更新，使 SBOM 信息自动更新成为 CI/CD 管道中每个构建周期标准的一部分。在发布运营阶段使用 SBOM 可以在使用的库或组件存在漏洞时，以更快的时间检测出有哪些应用程序中存在这些漏洞，并及时进行修复工作。

SBOM 可提高软件供应链的透明度

尽管 SBOM 对许多人来说依然很陌生，但其需求却不断呈现增长态势。Gartner 在其 2020 年的“应用程序安全测 试魔力象限”中预测到：“到 2024 年，至少一半的企业软件买家要求软件供应商必须提供详细的、定期更新的软 件物料清单，同时 60% 的企业将为他们创建的所有应用程序和服务自动构建软件材料清单，而这两组数据在 2019 年都还不到 5%。”

现代软件是使用第三方组件组装而成的，它们以复杂而独特的方式粘合在一起，并与原始代码集成以实现企业所 需要的功能。在现代多层供应链中，单个软件可能有成百上千的供应商，从原材料来源到最终组装系统的全套供 应商中找出某一组件的来源需要花费大量的时间和精力。因此，为所有组件构建详细准确的 SBOM，帮助企业跟 踪当前运行的程序、源代码、构建依赖项、子组件等所依赖组件的使用情况，检测软件组件是否带有已知的安全 漏洞或功能漏洞。

图 9 SBOM 的作用

SBOM 有助于揭示整个软件供应链中的漏洞与弱点，提高软件供应链的透明度，减轻软件供应链攻击的威胁。通过 使用 SBOM 可以帮助企业进行漏洞管理、应急响应、资产管理、许可证和授权管理、知识产权管理、合规性管理、 基线建立和配置管理等（如图9所示）。

通过自动化创建 SBOM 可以在漏洞披露时及时地进行响应排查以及快速的安全修复，最小化软件供应链的安全风 险；在开源组件和版本快速迭代的情况下，从风险管理的角度跟踪和持续监测闭源组件和开源组件的安全态势；

同时 SBOM 列举了管理开源组件的许可证，可以保护企业免受不当使用相关的法律或知识产权的风险，保护应用 程序在软件供应链中的合规性，避免将已知缺陷传递到软件供应链的下游。

SBOM 为漏洞风险治理节省大量时间

SBOM 的使用可以为软件供应链的漏洞治理节省大量时间。及时性对于企业在漏洞修复时是非常重要的。以往， 企业在修复已部署系统的漏洞缺陷时往往需要几个月甚至是数年的时间，其重要原因之一是企业无法在漏洞出现 的第一时间知晓该信息。

软件供应链下游的企业需要等待上游软件供应商完成软件补丁，才可以进行漏洞修复， 在等待的时间内，下游企业往往会面临无法预知的安全风险。而构建详细准确的 SBOM 则可以避免这一现象的发生， 允许所有利益相关者在漏洞发现时立即开始评估漏洞，并开始制定相关的补救措施。以下通过一张对比图来说明 SBOM 对漏洞风险治理时间的影响（如图 10 所示）。

图 10 SBOM 对漏洞风险治理时间的影响

受感染的开源组件在软件中未被修复的每一分钟都会增加潜在被利用的风险，SBOM 有助于企业在漏洞披露的早期 对漏洞进行识别，通过 SBOM 提供受感染开源组件和依赖项的准确位置，采取适当的步骤进行修改，为企业在风 险分析、漏洞管理和补救过程中节省数百小时至数月的时间。

使用基于 SCA 技术的工具

企业需要谨慎、合理地选择、获取和使用第三方闭源组件和开源组件。软件安全团队或研发团队通过必要的技术 手段确保所使用的第三方组件的安全性，及时获取所使用第三方组件和开源组件的漏洞情报，并适时做出响应。

软件成分分析（Software Composition Analysis ，SCA）是一种对二进制软件的组成部分进行识别、分析和追踪 的技术。SCA 可以生成完整的 SBOM，分析开发人员所使用的各种源码、模块、框架和库，以识别和清点开源软 件（OSS）的组件及其构成和依赖关系，并精准识别系统中存在的已知安全漏洞或者潜在的许可证授权问题，把 这些安全风险排除在软件的发布上线之前，也适用于软件运行中的诊断分析。

软件成分分析分为两种模式，静态和动态。静态模式是使用工具对目标工程文件进行解压，识别和分析各个组件 的关系；动态模式则是依赖于执行过程，在程序执行的同时收集必要的活动元数据信息，通过数据流跟踪的方式对目标组件的各个部分之间的关系进行标定。 通过使用基于多源 SCA 开源应用安全缺陷检测技术的安全审查工具，可以精准识别应用开发过程中，软件开发人 员有意或违规引用的开源第三方组件，并通过对应用组成进行分析，多维度提取开源组件特征，计算组件指纹信息， 深度挖掘组件中潜藏的各类安全漏洞及开源协议风险。

某金融企业的业务团队无法接受速度的迟滞，在研发效率和编码速度的考量下，大量的软件应用都基于第三 方的组件、开源代码、通用函数库实现，随之而来是绝大多数应用程序都包含开源组件的安全风险，为企业 带来了许多未知的安全隐患。 为了更好地进行开源组件治理工作，该企业引入基于 SCA 技术的工具，与 DevOps 流程无缝结合，在流水线 的测试阶段自动发现应用程序中的开源组件，提供关键版本控制和使用信息，并在 DevOps 的任何阶段检测 到漏洞风险和策略风险时触发安全警报。所有信息都通过安全和开发团队所使用的平台工具实时发送，实现 及时的反馈循环和快速行动。

在不改变该企业现有开发测试流程的前提下，将 SCA 工具与代码版本管理系统、构建工具、持续集成系统、 缺陷跟踪系统等无缝对接，将源代码缺陷检测和源代码合规检测融入到企业开发测试流程中，帮助企业以最 小代价落地源代码安全保障体系，降低软件安全问题的修复成本，提升软件质量。

4、发布运营阶段

建立成熟的应急响应机制

在软件的发布运营阶段，企业需要具备安全应急响应能力（如图 11所示），能在软件发布后对发生在软件和软件 补丁获取渠道的软件供应链安全事件、软件安全漏洞披露事件进行快速的安全响应，控制和消除安全事件所带来的 安全威胁和不良影响，进而追溯和解决造成安全事件的根源所在。

发布运营阶段包括监测告警、应急响应、事件处置、持续跟进等关键活动。在日常的运营管理中，企业可以通过采 用自动化分析技术对数据进行实时统计分析，发现潜在的安全风险，并自动发送警报信息。在有突发事件出现时， 通过监测预警，安全人员可以迅速地进行安全响应，在最短的时间内确定相关解决方案并进行事件处置，在解决之后进行经验总结并改进。通过监测预警技术对软件系统进行实时自动监测，当发现安全问题时，立即发出警告， 同时实现信息快速发布和安全人员的快速响应。

图 11 安全风险监测分析及响应

在发布运营阶段发生突发事件之后的应急响应与对安全事件进行处理的管理能力相关，因此，企业需要加强检测预 警能力、提高应急响应速度、加快应急处置效率，从事后被动救火转化为主动应急管理。充分预估突发事件的场景， 通过管理活动与技术手段避免突发事件的发生，在突发事件发生时能够及时监测预警，并有序进行处理行为。

由于在应用程序发布很久之后，仍有可能在其中发现新的安全漏洞，这些漏洞可能存在于构成应用程序的底层开源 组件中，导致“零日”漏洞的数量不断增加。因此，企业需要制定事件响应和漏洞处理策略，与领先的漏洞研究机 构进行合作，积极监控大量漏洞信息来源。同时，进行持续性的安全检查，定期的安全检查可以保护应用程序免受 新发现的安全漏洞的影响。

构建完善的运营保障工具链

BAS

2017 年，Gartner《面向威胁技术的成熟度曲线》中首次提及入侵与攻击模拟（ Breach and Attack Simulation， BAS）工具（如图 12 所示），并将其归到新兴技术行列。在 2021 年，Gartner 将 BAS 纳入“2021 年顶级安全和 风险管理趋势”。

图 12 BAS 技术原理

BAS 通过模拟对端点的恶意软件攻击、数据泄露和复杂的 APT 攻击，测试组织的网络安全基础设施是否安全可靠， 在执行结束时，系统将生成关于组织安全风险的详细报告，并提供相关解决方案。同时结合红队和蓝队的技术使 其实现自动化和持续化，实时洞察组织的安全态势。

BAS 可以确定漏洞的覆盖范围并对检测出的漏洞提供补救意见，防止攻击者对漏洞加以利用。除了自动化和持续 监控之外，BAS 还使安全团队改变了他们的防御方式，采取更为主动积极的策略，维护组织各个方面的安全。

WAF

早在 2007 年，国家计算机网络应急技术处理协调中心检测到中国大陆被篡改网站总数累积达 61228 个，比 2006 年增加了 1.5 倍。其中，中国大陆政府网站被篡改各月累计达 4234 个。为了更好的应对网络攻击，Web 应用防护 系统也被称为网站应用级入侵防御系统（Web Application Firewall, WAF）应运而生，WAF 可以对来自 Web 应用 程序客户端的各类请求进行内容检测和验证，确保其安全性和合法性，对非法的请求予以实时阻断，从而对各类 网站站点进行有效的安全防护（如图 13 所示）。

图 13 WAF 技术原理

WAF 通过增强输入验证，可以在运营阶段有效防止网页篡改、信息泄露、木马植入等恶意网络入侵行为，从而减 小 Web 服务器被攻击的可能性。同时，WAF 还可以判断用户是否是第一次访问，将请求重定向到默认登录页面并 且记录时间，通过检测用户的整个操作行为可以更容易识别攻击。

RASP

作为第一道防线，WAF 能够阻止基本攻击，但难以检测到 APT 等高级威胁，不仅如此，企业需要持续“调整”WAF 以适应不断变化的应用程序，这一过程消耗了安全管理人员大量的精力。此时，运行时应用程序自我保护技术 （Runtime Application Self-protection，RASP）（如图 14所示）作为新一代运行时保护技术被引入，RASP 可以 提供更深入的保护能力，更广泛的覆盖范围，并且可以花费更少的时间。

RASP 将保护代码像一剂疫苗注入到应用程序中，与应用程序融为一体，使应用程序具备自我保护能力。RASP 结 合应用的逻辑及上下文，对访问应用系统的每一段堆栈进行检测，当应用程序遭受到实际攻击和伤害时，RASP 可 以实时检测和阻断安全攻击，无需人工干预，最终实现软件应用的自我保护，确保软件应用的安全运行。

图 14 RASP 技术原理

RASP 在运营阶段可以应对无处不在的应用漏洞与网络威胁，为应用程序提供全生命周期的动态安全保护，可以精 准识别应用运行时暴露出的各种安全漏洞，进行深度且更加有效的威胁分析，快速定位应用漏洞，大大提升修复 效率，保障应用程序的安全性。

威胁情报平台

通过建立威胁情报平台（Threat Intelligence Platform，TIP）（如图 27 所示），可以帮助安全人员明确企业的在 线资产和安全状况，根据企业自身资产的重要程度和影响面，进行相关的漏洞修补和风险管理；同时可以帮助安 全人员了解企业自身正在遭受或未来面临的安全威胁，提供解决建议。

图 15 威胁情报平台原理

威胁情报平台与各类网络安全设备和软件系统协同工作，为威胁分析和防护决策提供数据支撑，通过对全球网络 威胁态势进行长期监测，以大数据为基础发布威胁态势预警，实时洞悉风险信息，进而快速处置风险。

容器安全工具

在发布运营阶段，通过使用容器安全工具（Container Security）（如图 28 所示），可以自动化构建容器资产相关 信息，提供容器环境中各类资产的状态监控，包括容器、镜像、镜像仓库和主机等基础资产信息，使资产拥有较 强的可扩展能力；通过建立智能应用补丁扫描工具，为安全人员提供镜像管理、镜像检测以及自动化补丁修复建议。

图 16某容器安全工具架构

为了更好地应对未知和迅速变化的攻击，容器安全工具可以对数据进行持续监控和分析，通过结合系统规则、基 线和行为建模等要素，自适应识别运行时容器环境中的安全威胁；建立一键自动化检测机制，给安全人员提供可 视化基线检查结果，同时将企业现有的安全技术与持续运营的安全模型相结合，实现持续化的动态安全检测。

可信研发运营安全能力成熟度模型

中国信息通信研究院云计算与大数据研究所自 2019 年起，联合业界众多头部厂商专家制定《可信研发运营安全能 力成熟度模型》标准，提出可信研发运营安全能力体系框架（如图 17 所示）。可信研发运营安全能力体系框架的 构建继承 SDL 与 DevSecOps 的核心理念，安全前置，汲取 SDL 与 DevSecOps 体系的优点，优化具体安全实践要素，是一种贯穿研发运营全生命周期的安全理念。

图 17 可信研发运营安全能力体系框架

可信研发运营安全能力体系框架强调安全左移，分为管理制度以及涉及软件应用服务全生命周期的需求阶段、安 全需求分析阶段、设计阶段、开发阶段、验证阶段、发布阶段、运营阶段和停用下线阶段八大部分，每个部分提 取了关键安全要素，规范了企业研发运营安全能力的成熟度水平。根据各阶段安全要素达标情况，可信研发运营 安全能力成熟度模型共分为 3 个级别，自低向高依次为基础级、增强级和先进级。

云安全共享责任模型

在云计算环境下，云服务提供商与云租户需要进行软件供应链安全共治，但云服务普遍存在安全责任划分不清晰 与治理措施不明确等问题，为了解决这些问题，2019 年，微软在《Shared Responsibility in the Cloud》中提到 云安全共享责任模型（如图 18 所示）。云安全共享责任模型指出，在基础设施即服务（IaaS）、平台即服务（PaaS） 和软件即服务（SaaS）三种不同的云服务模式下，云服务提供商（Cloud Service Provider，CSP）和客户之间需 要分担的安全责任不同。CSP 需要承担客户在使用云服务时保障物理安全的责任，客户需要负责确保其解决方案 及其数据被安全地识别、标记和正确的分类，以满足任何合规义务的责任，其余的责任则由 CSP 和客户共同承担。

图 18 云安全共享责任模型

在构建以混合云作为运行环境的软件程序时，应仔细评估应用程序的依赖性和安全影响，通过使用成熟的 DevSecOps 模型可以帮助组织评估整个软件供应链，并确定需要严格控制的安全关键点。 为了提高可见性和支持混合云体系结构，许多云服务商显示或允许应用程序接口（API）与安全进程的交互。不成 熟的 CSP 可能不知道如何以及在多大程度上向客户提供 API。例如，通过检索日志或权限控制的 API，云租户可以 获得敏感性较高的信息。然而这些 API 可以帮助云租户检测到未经授权的访问行为，因此 API 的开放是必要的。

Grafeas 开源计划

Grafeas（希腊语中的“scribe”）是由 Google 发起，联合包括 Redhat、IBM 在内的多家企业共同发布的开源计 划。Grafeas 是一个开源工件元数据 API（如图19 所示），它提供了一种统一的方式来审计和管理软件供应链。 Grafeas 定义了一个 API 规范，用于管理软件资源，例如容器镜像、虚拟机镜像、JAR 文件和脚本。组织可以使用 Grafeas 来定义和聚合有关项目组件的信息。Grafeas 为组织提供了一个中央事实来源，用于在不断增长的软件开 发团队和管道中跟踪和执行策略。构建工具、审计工具和合规性工具都可以使用 Grafeas API 来存储和检索有关各 种软件组件的综合数据。

图 19 Grafeas 开源计划原理

同时，作为 Grafeas 的一部分，Google 推出了 Kritis，其是一种 Kubernetes 策略引擎，通过在部署前对容器镜像 进行签名验证，可以确保只部署经过可信授权方进行过签名的容器镜像，降低在环境中运行意外或恶意代码的风险。

Grafeas 为组织成功管理其软件供应链所需的关键元数据提供了一个集中的、结构化的知识库。它反映了 Google 在数百万个版本和数十亿个容器中构建内部安全和治理解决方案所积累的最佳实践，包括：

• 使用不可变的基础设施来建立针对持续性高级威胁的预防性安全态势；
• 基于全面的组件元数据和安全证明，在软件供应链中建立安全控制，以保护生产部署；
• 保持系统的灵活性，并确保围绕通用规范和开源软件的开发人员工具的互操作性。

Grafeas 旨在帮助组织在现代软件开发环境中应用上述提到的最佳实践，实现以下功能和设计要点：

• 全面覆盖：Grafeas 根据软件组件的唯一标识符存储结构化元数据，因此组织无需将其与组件的注册表放在一起， 它可以存储来自不同储存库组件的元数据；
• 混合云适配性：组织可以使用 Grafeas API 作为中央通用元数据存储；
• 可插入：Grafeas 可轻松添加新的元数据；
• 结构化：针对常见的元数据类型的结构化元数据模式，让组织可以添加新的元数据类型，并且依赖于 Grafeas 工 具可以管理这些新数据；
• 访问控制：Grafeas 允许组织控制多个元数据的访问；
• 查询能力：使用 Grafeas 的组织可以轻松查询所有组件的元数据，不必解析每个组件的单一报告。

在软件供应链的每个阶段，不同的工具会生成有关各种软件组件的元数据，示例包括开发人员的身份、代码、何时 签入和构建、检测到哪些漏洞、哪些测试通过或失败等，然后 Grafeas 会捕获此元数据。  

报告下载地址：https://www.dsocon.cn/#/down