标准解读（三）|金融科技软件供应链供需安全管理指南

2024年5月22日，联盟发布了《金融科技软件供应链供需安全管理指南》（T/ZFIDA 0001—2024）。该标准由工银科技有限公司牵头，中国电子科技集团公司第十五研究所、龙盈智达（北京）科技有限公司、中关村互联网金融研究院、北京比瓴科技有限公司共同发起。 

该标准明确了金融科技软件供应链的安全保护目标，分析了金融科技软件供应链各安全保护目标面临的安全风险，并提出了安全视角下管理金融科技软件供应链的实践框架。标准详细阐述了供需双方再管理过程中需考虑的安全因素，并为金融机构和科技企业在软件供应链安全管理方面提供了切实可行的建议。

为了帮助成员单位更好地理解团体标准内容，联盟推出标准系列解读，本文章是系列解读的第三篇。上一篇，我们主要介绍了软件供应链现状、相关监管规范及其所面临的风险。（点击跳转）本篇解读主要围绕团标中关于金融科技软件供应链风险的相关对策和业内最佳实践展开。

一、软件供应链解决思路

在全球化和数字化的浪潮下，软件供应链风险成为企业面临的重要挑战。随着软件组件的复杂性和依赖性的增加，供应链的每一个环节都可能成为潜在的漏洞。

 

 

国际知名信息技术咨询机构Gartner在《缓解企业软件供应链安全风险》报告中提及了其在企业软件供应链活动中观察到的三大发现：

• 缺乏安全评估：尽管软件供应链攻击增加，但供应商风险管理中仍缺乏充分的安全评估，使得需方组织易受攻击。

• 应对漏洞困难：由于软件组件不透明，安全团队难以确定受影响的部分，进而增加了识别和缓解风险的工作量。

• 缺乏正式测试：需方很少对商业软件进行正式的安全测试，即便是涉及关键任务的系统，这增加了恶意代码攻击的风险。

团体标准指南的内容涵盖了解决这三类问题的三大思路，以帮助企业防范软件供应链风险。

• 加强供应商风险管理：将软件供应链风险纳入供应商风险管理体系，以消除或减少对应用安全实践不足的供应商的依赖。
• 软件供应链内容透明化：要求供应商披露其应用软件的组成部分，这有助于简化对漏洞的响应和缓解措施。
• 实施专门的测试和安全评估：应对涉及高价值或敏感内容的软件进行专门的测试和安全评估。测试范围应包括传统的软件漏洞检查和恶意代码识别等。

 

二、加强供应商风险管理

供应商管理工作主要由软件供应链中的需方进行实施。团体标准中提及供应商管理的重要内容如下。

1. 需方宜对供应商进行评估，包括但不限于背景、能力、资质审查以及持续安全提供产品或服务等内容。
2. 需方宜制定供应商选择策略和规章制度标准规范综合体。
3. 需方宜建立合格的供应目录，并定期对该目录进行更新维护，优先从供应目录中选取满足条件的供应商。
4. 在供应关系发生变更时，需方宜对变更带来的安全风险进行评估，并采取相应的风险控制措施。
5. 对于测试评估等内容，涉及第三方机构的，需方宜明确第三方机构的能力、资质等要求。
6. 对于重要组织或场景，例如关键信息基础设施运营者等，需方宜建立供应商替代方案，以防范软件供应链中断风险。

传统的供应商评估通常不会对供方的应用程序或软件供应链风险措施进行深入审查，无法对这些流程中的安全性或风险进行知情评估。虽然这些信息可以提供对供方供应链中潜在安全问题的高维度见解，但它们仍不够全面，无法充分评估供应商可能带来的风险。

更合理的风险管理方法是要求供应商提供并评估其安全软件开发实践的证明，可参考以下相关资质、标准、实践和安全框架。

• 相关资质

我国现有的权威认证包括中国网络安全审查认证和市场监管大数据中心（CCRC）提供的软件安全开发服务资质认证。

• 最佳实践

1. 软件安全保障规范：《信息技术 软件安全保障规范》（GB/T 30998—2014）提供了详细的最佳实践，包括安全需求、安全设计、安全实现和安全测试的系列保障分析，明确了相关安全措施和方法，确保在软件开发的每个阶段都考虑到安全性，从而减少漏洞和提高软件的整体安全性。
2. 安全软件开发框架：安全软件开发框架（SSDF）是一个全面的框架，由美国国家标准与技术研究所（NIST）作为特别出版物NIST 800-218发布。
3. 应用安全验证标准：应用安全验证标准（ASVS）由开放Web应用程序安全项目（OWASP）开发，提供了详细的应用程序安全验证标准，以帮助开发人员和安全专业人员创建和测试安全的Web应用程序。
4. 安全编码规范快速参考指南：安全编码规范快速参考指南（SCP）也由OWASP发布，涵盖了各种编程语言和技术环境下的安全编码建议，帮助开发人员在设计和编码时考虑和实施安全措施，以减少常见的安全漏洞和攻击风险。
    

• 安全框架

除了以上提到的标准和最佳实践，各个行业联盟和安全社区也制定了框架和指南，旨在保护开发环境和制品的完整性。以下是一些具备代表性的例子。

1.软件供应链安全指南

互联网安全中心（CIS）的软件供应链安全指南（Software Supply Chain Security Guide）是一个详细的指导文件，按照软件开发生命周期的阶段进行分步操作。指南包含173个控制措施，详细描述了每个控制措施的理由、审计指导和纠正步骤，分为五个主要类别：

1）源代码：对组织开发的任何应用进行适当的源代码管理的安全建议。

2）构建流水线：关于构建流水线的管理和安全的安全建议。

3）依赖：对软件构建和发布过程中引入的各种依赖关系的管理的安全建议。

4）制品：管理由构建流水线产生的制品，以及应用在构建过程中使用的制品的安全建议。

5）部署：管理应用部署过程、配置以及相关文件的安全建议。

表：CIS提供的五类技术控制措施

 

 

类别	控制措施
源代码	代码更改存储库管理 贡献访问权限 第三方 代码风险
构建管道	构建管道 构建工具 管道指令 管道完整性
依赖项	第三方软件包 验证软件包
制品	制品验证 访问验证 软件包注册 来源追溯
部署	部署配置 部署环境

2.软件制品供应链级别

软件制品供应链级别（Supply-chain Levels for Software Artifacts，SLSA）是由开源安全基金会（Open SSF）维护的安全框架。Open SSF在2023年4月发布SLSA 1.0版本，这也是SLSA的第一个稳定版本。SLSA基于谷歌公司（Google）的实践并结合开源社区的共识，提供了一套软件供应链安全标准和控制措施，旨在确保制品（如代码和配置文件）的完整性，并构建一个更具弹性的构建系统。

 

图：软件制品供应链级别识别的软件供应链威胁

SLSA是一套可逐步采用的供应链安全准则，对软件的供方和需方都适用：供方可以遵循SLSA的指导方针，使他们的软件供应链更加安全，而需方可以利用SLSA来决定是否信任一个软件包。

3.软件供应链最佳实践白皮书

软件供应链最佳实践白皮书（Software Supply Chain Best Practices，SSCP）由云原生计算基金会（CNCF）制作，提供了全面的供应链安全方法，强调分层防御实践的重要性，旨在保障软件供应链安全的各个方面。

 

 

• SSCP提出了四个关键原则：

• 建立可信状态：供应链的每一步都应该通过密码学认证（Cryptographic Attestation）和验证（Verification）来建立“可信任”状态。任何步骤都不应依赖于对前一步骤或输出的信任假设，信任关系必须明确定义。

• 自动化供应链安全：供应链安全的关键是自动化。尽可能地自动化软件供应链的各个环节，可以显著减少人为错误和配置漂移（Configuration Drift）的可能性。

• 构建环境限定及最小权限原则：供应链中的构建环境应该有明确的定义且范围有限。在这些环境中操作的人和机器等实体身份应被授予完成任务所需的最小权限。

• 强化认证机制：所有在供应链环境中操作的实体必须使用加固的认证机制（多因素认证等）进行双向认证，并定期轮换密钥。

4. 供应链完整性、透明性和信任

供应链完整性、透明性和信任（Supply Chain Integrity, Transparency, and Trust，SCITT）由互联网工程任务组（IETF）主导，基于微软早期的供应链完整性模型工作，专注于在软件和数字供应链环境中的供应链安全和信任问题。SCITT计划旨在通过建立一套标准，确保供应链中各个环节的合规性和安全性，特别是通过验证和保证各实体和操作的真实性和透明性。

SCITT提供制品（Artifact）信息，使各子系统能了解依赖关系，其信息格式多样，包括结构化和非结构化数据。结构化数据表示为声明（Statement）。声明是由一个可以验证身份的实体（Identity如开发者或组织）做出的结构良好的陈述，这个陈述可能包含支持证据。证据被记录为声明（Statement）的有效载荷(Payload）。

 

图：SCITT处理过程（图源：SCITT）
 

三、软件供应链内容透明化

软件供应链内容透明化指的是在软件开发和采购过程中，通过详细记录和公开软件组件及其依赖关系的信息，使整个供应链的结构和组成变得清晰和可见。这种透明化有助于识别和管理潜在的安全和合规风险，确保从供应商获取的软件或服务的安全性、可靠性和合法性。

在过去的开发实践中，代码中依赖关系的梳理通常是被动的。换言之，往往是在开发人员已经将开源依赖项添加到其应用程序后才考虑。在软件供应链攻击与日剧增的今天，在开发过程中还是在采购决策中，组织需要采取更为主动的方法。软件构件清单（SBOM）的出现为开发和安全团队奠定了基础，使其能够在选择过程中提前识别有风险或不可接受代码。

SBOM是指一份清单，列出了软件产品中所包含的所有组件和其版本信息，以及组件之间的层次关系。类似于硬件产品的物料清单（BOM），旨在提供软件开发人员和终端用户对软件组件的透明度和可追溯性，是一种助力软件供应链管理的有效实践。

据Gartner预测，到2026年，至少60%的组织在采购关键任务的软件解决方案时，将要求供应商在其许可和支持协议中披露SBOM，而这一比例在2022年仅不到5%。各国和地区已经颁布多项法规和建议，旨在加强软件供应链的安全性，特别是涉及SBOM的规定。

 

 

• 美国国家电信和信息管理局《软件物料清单的最小元素》：于2021年7月发布，规定了SBOM的最小元素要求。

• 日本《经济安全保障法》（ESPA）：于2022年5月通过，包含保护关键基础设施（包括某些类型的软件）安全的多项条款。日本经济产业省（METI）发布了《软件管理软件物料清单引入指南》，提供了关于实施和采用这些制品的指导。

• 欧盟《网络弹性法案》：于2022年9月首次提出，包含多项旨在改善网络安全和保护需方及企业免受安全事件影响的措施。该法案特别关注数字供应链的安全问题，如提供SBOM。

• 英国国家网络安全中心（NCSC）：于2022年10月发布了关于供应链安全的指导，帮助组织实施NCSC的供应链安全原则，包括针对软件供应链安全的多项措施。

• 德国联邦信息安全局（BSI）：于2023年8月发布了SBOM创建的要求，旨在增强需方更好地理解和管理他们使用的软件的潜在风险的能力。

• 澳大利亚信号局的《软件开发指南》：于2023年9月发布，包含多个关于安全软件开发的规定。其中一项建议是要求创建和分发SBOM给软件需方。

• 中国国家市场监督管理总局《网络安全技术 软件供应链安全要求》：于2024年4月正式发布，在SBOM的基础上进行延伸，提出了软件供应链安全图谱的概念，要求组织依据软件供应链安全图谱等建立组织管理、供应活动管理等方面的供应链安全信息采集和跟踪机制。

• 中国国家市场监督管理总局《网络安全技术 软件物料清单数据格式》：于2024年5月发布征求意见稿，给出了我国标准化的软件物料清单数据格式，供其他组织参考。团体标准中提及内容透明化的重要内容如下。

• 供方宜构建软件物料清单，软件物料清单至少能追溯至其第一级供应商，并在采购阶段提供至需方。

• 供方宜配合需方对来源于开放源代码社区和第三方的代码、组件和软件，进行完整性验证、安全性测试和依赖关系分析，保障开源或第三方组件来源可靠、安全风险可消除或控制，构建形成软件物料清单和软件清单台账。

• 供方宜配合需方持续跟踪所使用开源和第三方组件的使用状态、安全状态，对于存在安全风险的，及时通报，并及时采取更新、修复等措施，完善软件物料清单信息。

• 供方宜向需方提供软件相关技术资料，包括中文版运行维护、二次开发、软件使用的场景和条件、权限和授权机制、软件使用说明书及测试报告（包括但不限于源代码、二进制代码、组件、软件物料清单等）等。需方宜掌握此类技术资料。

①SBOM的三类基本要求

软件物料清单可以包括开源软件、第三方软件、商业软件和自主开发的代码。它可以被视为一个关键的组成部分，用于识别软件产品中的漏洞和其他安全问题，并对软件产品的安全性进行评估。为了更好的进行软件供应链的安全管理，团标给出了对软件物料清单的三类基本要求，分别是：数据字段、自动化支持、实践与流程

1）数据字段

SBOM的主要元素要求包括以下七个字段：

1. 组件供应商：开发组件的个人或组织名称
2. 组件名称：供应商给出的组件名称
3. 组件版本：供应商给出的组件版本
4. 组件标识符：标识符，如SWID、PURL、CPE等
5. 依赖关系：与其他组件的组合关系
6. 构建人：生成SBOM的个人或组织名称
7. 时间戳：生成SBOM的日期与时间

通过这些字段，可以把特定组件与漏洞库、许可证库关联。

2）自动化支持

软件物料清单应该是机器可读的格式，同时也是人类可读的格式，常见的软件物料清单格式有三种：

1. Software Identification（SWID）

• NIST主推的格式
• 已经完成标准化工作，标准号：ISO/IEC 19770

2. Software Package Data Exchange（SPDX）

• Linux基金会主推的格式
• 已经完成标准化工作，标准号：ISO/IEC 5962

3. CycloneDX

• OWASP基金会主推的格式
• 尚未完成标准化工作

三种格式中间存在通用的元素，可以在一定程度上相互转换。

3）实践和流程

软件物料清单不仅是一组结构化数据，还需要满足实践和流程等六方面的要求：

1. 频率：软件物料清单应该及时更新，以便反应最新情况
2. 深度：软件物料清单应该包括完整的依赖关系
3. 已知的未知：如果软件物料清单没有给出依赖关系，需要明确标记出是没有依赖关系，还是不清楚是否存在依赖关系
4. 分发与交付：应该及时的把软件物料清单分发给需求方
5. 访问控制：根据需要约束可以访问软件物料清单的对象
6. 容错：软件物料清单相关要求还比较早期，使用方应该容忍过程中的无心之失

满足这六方面要求可以更好的把软件物料清单融入管理工作。

②SBOM的来源

• 供应商提供：可在采购合同中进行约束，要求商业软件的供应商提供。
• 自行创建：

供应商可能无法或不愿提供SBOM，但在某些场景（例如，该软件已在使用中且组织高度依赖它，或是相关可替代的供应商稀少甚至不存在）下，组织可能仍需与此类供应商合作。另外，对安全性要求较高的组织也有可能需要验证供应商提供SBOM的准确性。在这些情况下，组织可以自行创建SBOM。

例如，需方可使用工具（如软件成分分析工具）对二进制可执行文件进行反编译和分析，或在有源代码的情况下，直接对源代码分析生成SBOM。

如果使用的是开源软件，也可采取开源安全基金会（Open Source Security Foundation，OSSF）评分卡（Scorecard）。它是一个旨在评估开源项目安全性的工具和数据库。它通过一系列预定义的属性和标准，对开源项目进行评估和打分，通过提供详尽的元数据和评估标准，帮助用户和组织更好地管理和评估开源项目的安全风险。

这些工具不仅可以帮助分析安全和操作风险，还能确认供应商提供的文档的准确性。

③SBOM与VEX的结合使用

VEX（漏洞可利用性交换）是一种用于评估漏洞利用可能性的框架。它帮助组织评估已知漏洞的实际威胁和影响，确定漏洞修复优先级，即哪些漏洞是紧急需要修复的，哪些则可以暂时忽略。通过这种漏洞优先级管理，企业可以更有效地分配资源，集中精力解决最紧迫的安全问题。

SBOM与VEX结合使用，可以帮助组织建立一个全面的安全管理体系，既能了解和追踪软件供应链中的所有组件，又能根据实际风险情况进行及时的漏洞管理。这种双管齐下的方法将极大地提升软件供应链的安全性，确保业务连续性和安全。

四、结语

面对金融科技软件供应链的挑战和风险，本文从供应商供应链风险管理、供应链内容透明化两个关键方面给出了应对策略。由于篇幅原因，我们将在下一篇中进一步探讨软件供应链中安全检测评估的有效实践。