16、软件供应链供应商安全控制全解析

软件供应链供应商安全控制全解析

在软件供应链中，供应商的安全控制至关重要。它直接关系到软件产品和服务的安全性、可靠性以及企业的整体运营风险。以下将详细介绍一系列供应商安全控制措施。

1. 供应商选择与评估中的网络安全考量

在选择和评估供应商时，应将网络安全纳入其中。这包括两个关键控制：
- Control SP - 01 ：将网络安全融入供应商选择和评估流程。确保在整个选择过程中，网络安全是重要的评估指标。
- Control SP - 02 ：研究供应商的网络安全态势，评估风险和透明度。了解供应商在网络安全方面的表现，识别潜在风险。

2. IT 安全与环境安全评估

进行软件供应链安全评估时，必须考虑 IT 安全要素。评估应涵盖开发系统、实验室环境、构建管理系统、测试环境、生产环境以及适用时的制造环境的控制。即使是采用云优先策略的组织和基于云的开发基础设施，也需维持适当的 IT 控制，如访问管理、基于角色的访问控制、日志记录和监控、备份、灾难恢复和业务连续性等。多因素认证、VPN 等 IT 控制对于保护供应商产品和应用的机密性、真实性和完整性至关重要。根据产品、应用或数据的风险，可要求提供软件开发生命周期中 IT 基础设施的渗透测试结果。
- Control SP - 03 ：要求供应商提供其 IT 安全控制的证据，特别是针对软件开发系统、环境和基础设施的防御措施。

3. 产品/应用安全组织评估

供应商在回答网络安全组织相关问题时，通常从 IT 安全角度出发。有时评估可能由销售组织人员使用预先批准的答案完成，但这些答案可能未解决产品或服务的软件供应链风险。进行供应商评估时，应在问卷中询问响应者的组织、身份和角色，并将其纳入评估。评估还应询问供应商的产品或应用安全组织（如产品安全办公室或安全工程部门），以及是否有负责安全开发流程、控制和合规性的应用安全领导者。可要求提供显示应用安全领导者、安全架构师和安全测试人员的组织结构图。若供应商没有产品或应用安全组织，应证明其 IT 安全或开发团队中有负责安全开发实践、安全测试能力和正式网络安全审查检查点的资源。建议在评估过程中和之后，与供应商组织中的网络安全领导者建立并保持直接关系。
- Control SP - 04 ：评估供应商的技术领导力，要求提供供应商应用安全组织结构和问责制的证据，并与关键供应商的网络安全领导者建立关系。

4. 产品安全流程与安全开发生命周期

供应商的产品和应用安全流程应记录在政策、程序、报告和仪表板中。这包括安全开发、安全编码规则、安全测试要求、安全功能和要求、渗透测试要求、发布管理标准以及漏洞和补丁管理政策和服务级别协议（SLA）。安全开发生命周期（SDL）过程可以遵循特定框架，如 ISA/IEC 62443 - 4 - 1、NIST SSDF、ISO/IEC 27034 或 Microsoft SDL。无论采用何种流程，公司都应有记录的政策，说明发布所需的基线和网络标准。软件安全流程还应有衡量和监控应用或产品安全态势的标准。需要注意的是，供应商尤其是小型公司或初创公司可能采用混合的安全开发实践，而不是遵循特定的流程框架。当供应商以 SOC 2 报告和 ISO 27001 认证作为安全开发证据时需谨慎，因为这些报告和认证不能评估安全开发实践。
- Control SP - 05 ：要求供应商提供其安全开发实践、框架和控制的证据。

5. 培训要求

在软件供应链安全评估中，除了询问员工是否接受网络安全意识培训（通常涵盖网络钓鱼和社会工程风险），还应询问供应商如何培训其各个团队，如 IT、开发、云运营等。这些培训应具体针对安全开发生命周期过程以及基于角色的安全编码和安全测试等主题。小型公司和初创公司应与大型公司遵循相同的培训要求。同时，应询问应用安全团队是否在项目开始前完成培训。
- Control SP - 06 ：要求供应商提供其网络安全意识、安全开发生命周期流程、安全编码和安全测试的培训计划证据，以及开发前强制培训的政策。

6. 安全开发与安全测试

开发过程中，供应商应利用威胁建模、安全编码技术（如同行评审）和安全编码分析（SCA）工具评估代码。评估时，应要求提供开发团队进行威胁建模和安全编码实践的证据，以及使用的 SCA 工具信息和工具在构建过程中使用的证据。评估证据应包括证明在构建和部署或发布前进行安全测试的实践、工具和报告。安全测试实践应包括对安全功能要求的验证，类似于对其他要求的功能测试。除了针对安全功能、要求和风险进行测试，供应商还应提供其他类型测试的证据。SAST 和 DAST 工具可有效用于安全测试，但不应是产品或应用的唯一安全测试手段。
- Control SP - 07 ：要求供应商提供或演示其包括威胁建模、安全编码实践、静态代码分析和安全测试在内的安全开发实践。

7. 构建管理、DevSecOps 和发布管理

构建管理实践对软件供应链安全至关重要，如 2020 年 SolarWinds 黑客事件所示。使用构建完整性框架（如 Google SLSA）可提供特定控制和适当的构建管理实践。评估时，应要求提供使用的构建工具、允许进行构建的人员和地点、在集成到构建或 DevSecOps 流程前确认代码提交有效性的方法，以及与各种级别的变更（从小的调整到重大架构调整）相关的发布管理和批准实践的证据。DevSecOps 和发布管理证据应包括代码管理和变更管理实践、软件物料清单（SBOMs）、配置变更以及对构建和发布流程所做的更改。还应证明工具和 SIEM/SOAR 系统的日志有保留政策，日志连接到异地日志存储库，并且 SIEM/SOAR 系统日志会检查异常行为和事件。
- Control SP - 08 ：要求供应商提供或演示其构建管理、DevSecOps 和发布管理实践，包括工具、报告、流程、访问控制、批准以及工具和事件管理系统的日志。

以下是部分控制措施的总结表格：
| 控制编号 | 控制内容 |
| ---- | ---- |
| Control SP - 01 | 将网络安全融入供应商选择和评估流程 |
| Control SP - 02 | 研究供应商的网络安全态势，评估风险和透明度 |
| Control SP - 03 | 要求供应商提供其 IT 安全控制的证据，特别是针对软件开发系统、环境和基础设施的防御措施 |
| Control SP - 04 | 评估供应商的技术领导力，要求提供供应商应用安全组织结构和问责制的证据，并与关键供应商的网络安全领导者建立关系 |
| Control SP - 05 | 要求供应商提供其安全开发实践、框架和控制的证据 |

下面是一个简单的 mermaid 流程图，展示供应商评估流程：

graph LR
    A[开始评估] --> B[选择与评估供应商]
    B --> C{考虑网络安全?}
    C -- 是 --> D[评估 IT 安全]
    C -- 否 --> B
    D --> E[评估产品/应用安全组织]
    E --> F[评估安全流程与生命周期]
    F --> G[评估培训情况]
    G --> H[评估安全开发与测试]
    H --> I[评估构建与发布管理]
    I --> J[结束评估]

8. 扫描、漏洞管理、补丁和 SLA

第三方供应商评估应始终包含关于扫描、漏洞管理和补丁的问题，并要求提供相关证据。必须对源代码、系统、环境和网络进行频繁扫描，并提供相关政策、实践、报告和扫描日志。证据中应包含漏洞披露政策和漏洞管理程序，说明供应商如何接收漏洞报告、及时管理漏洞以及向客户和当局披露漏洞。系统、环境和应用必须进行补丁修复以解决已知漏洞，应制定关于关键和高风险漏洞补丁的 SLA 和政策，并要求供应商提供内部 SLA 或要求的证据。
- Control SP - 09 ：要求供应商提供其扫描、漏洞管理和补丁流程的证据，包括政策、程序、报告、日志和补丁服务级别协议。

9. 云应用和环境管理

对于软件供应链中使用的所有云应用和环境，供应商应提供管理和维护的证据。证据应包括与云环境相关的人员、流程和技术信息，而非仅基础设施本身。例如，供应商必须定期审查管理员权限和实践以及私钥管理程序。对于技术方面，应监控云提供商并进行频繁检查，确保环境配置正确且默认安全。云供应商经常引入新工具或配置选项，可能改变云应用和服务的安全态势。应由经验丰富的渗透测试人员每年对云应用、配置和基础设施进行测试。可要求提供 AICPA SOC 2 Type 2 报告或 ISO 27001 认证，尽管这些对于安全开发流程不够充分，但适用于云基础设施。
- Control SP - 10 ：要求供应商提供其云基础设施、访问控制、密钥、配置、测试、责任和服务级别协议的管理实践和报告的证据。

10. 开发服务评估

若供应商提供软件开发或固件开发服务，除了前面提到的安全开发实践，评估还应涉及代码质量相关问题。评估将揭示是否需要对服务或网络协议进行调整。应明确界定持续开发、测试、缺陷纠正和漏洞修复的责任。根据软件的使用或销售地点，还可询问开发人员的位置以及是否对人员进行了背景调查（前提是所在国家允许）。证据应包括访问控制政策、强制多因素认证、SBOMs 和其他安全开发实践。
- Control SP - 11 ：要求供应商提供其开发服务的证据，包括代码质量报告、测试报告和漏洞情况。适用时，要求提供开发人员信息，如位置和背景调查证据。

11. 制造过程安全评估

部分供应商可能提供第三方服务，如闪存固件或组装产品。对直接访问产品的制造供应商，应评估其在运输、制造或分销过程中软件或固件被破坏的风险。例如，若向第三方供应商提供最终固件，该供应商应验证产品未被破坏。制造过程应在交付客户前进行最终完整性检查，该过程的验证和测试至少每年进行一次，并在评估过程中提供测试证据。
- Control SP - 12 ：要求供应商提供对任何有权访问软件或固件的人员或流程的访问控制和完整性检查的证据。

12. 网络协议、合同和附录

评估有助于了解供应商的安全态势，而网络协议则使供应商对其持续的安全态势负责。网络协议应关注评估过程中重要的主题。若没有网络协议模板，可让法律团队协助为组织定制，或参考特定行业模板。创建网络协议时，需确定愿意接受的最低要求和风险。理想情况下，所有类型的供应商应使用一个网络协议。供应商协议应在主合同或附录中包含网络条件，主服务协议（MSA）或网络协议应包括以下一般网络安全项目：
- IT 安全和管理
- 数据保护
- 数据驻留要求（数据的物理或地理位置）
- SLAs，包括业务连续性和弹性要求
- 违规和事件的定义
- 事件管理和通知
- 审计和评估权，通常每年进行或在发生数据泄露、关键事件或关键漏洞时触发
- 安全和许可义务，包括违规语言
- 网络安全保险，用于应对违规和其他网络事件
- 赔偿（对损失或损害的补偿或免除责任）

对于软件供应链安全，协议还应要求供应商具备以下要素：
- 安全开发生命周期
- 威胁模型
- 代码分析
- 安全测试
- 渗透测试
- 软件物料清单（SBOMs）
- 漏洞和补丁管理，包括 SLAs
- 漏洞披露和通知
- 特定角色的网络安全和应用培训

可在协议中规定应遵循的安全开发生命周期框架，也可要求第三方进行年度独立和第三方评估，如 SOC 2 和产品全范围的渗透测试。若在供应商评估过程中发现缺陷，应将其添加到网络协议中。网络协议中关键的一部分是漏洞和补丁管理以及相关的 SLA。通常 MSA 会提及软件更新，但漏洞管理以及与漏洞修复相关的保修和责任问题往往未得到解决。对于本地软件、物联网设备或运营技术（OT）设备，制造商应提供已知漏洞的软件更新和增强功能。若通过增值经销商（VAR）购买产品，可能无法在经销商合同中要求原始制造商提供漏洞或补丁通知，此时应遵循组织的补丁管理政策来监控制造商。网络协议通常包括关键和高风险漏洞通知和修复的 SLA。对于无法在约定时间内修复的问题，合同应规定在相同 SLA 时间内提供通知。行业标准是关键漏洞 30 天、高风险漏洞 90 天，中低漏洞通常不在协议中提及，因为很少可被利用，通常在未来软件更新中修复。云应用和移动应用的修复可能较快，但物联网和 OT 设备需要进行广泛测试以确保硬件兼容性、向后兼容性、互操作性和安全性。在某些情况下，由于硬件依赖或生命周期结束的组件，补丁可能不可行，设备制造商只能推荐缓解措施和补偿控制。SLA 还应考虑供应商第三方组件中存在漏洞时的较长时间线。协议中常被忽略的主题是软件终止过程以及供应商在终止时的网络责任。若在协议到期或终止后继续使用产品或服务，安全漏洞仍可能使组织面临风险。若购买商业代码库且协议不允许终止后使用，可能需要从产品或应用中移除代码，替换选项有限。在协议中，需定义若任何一方无法或不愿继续合作将发生的情况。终止条款可能包括继续支持或更新的费用，也可能要求供应商在关闭业务时将代码存于托管账户。终止条款应考虑业务连续性、业务弹性和生命周期管理的所有方面。若供应商无法同意协议中的条件，可能其网络安全实践不成熟，需投资补偿控制甚至选择其他供应商。
- Control SP - 13 ：在供应商签约过程中纳入网络协议，根据采购组织的政策包括网络风险和最低安全标准。

13. 持续供应商管理

供应商的安全态势可能随时间变化，虽希望其不断改善，但也可能因组织调整等原因下降。为保持竞争力和创新，供应商管理应包括对其他供应商的评估。

以下是剩余控制措施的总结表格：
| 控制编号 | 控制内容 |
| ---- | ---- |
| Control SP - 09 | 要求供应商提供其扫描、漏洞管理和补丁流程的证据，包括政策、程序、报告、日志和补丁服务级别协议 |
| Control SP - 10 | 要求供应商提供其云基础设施、访问控制、密钥、配置、测试、责任和服务级别协议的管理实践和报告的证据 |
| Control SP - 11 | 要求供应商提供其开发服务的证据，包括代码质量报告、测试报告和漏洞情况。适用时，要求提供开发人员信息，如位置和背景调查证据 |
| Control SP - 12 | 要求供应商提供对任何有权访问软件或固件的人员或流程的访问控制和完整性检查的证据 |
| Control SP - 13 | 在供应商签约过程中纳入网络协议，根据采购组织的政策包括网络风险和最低安全标准 |

下面是另一个 mermaid 流程图，展示持续供应商管理流程：

graph LR
    A[开始管理] --> B[定期评估供应商]
    B --> C{安全态势变化?}
    C -- 是 --> D[分析原因]
    C -- 否 --> B
    D --> E{是否下降?}
    E -- 是 --> F[采取补偿措施]
    E -- 否 --> B
    F --> G[考虑更换供应商]
    G --> B

通过全面实施这些供应商安全控制措施，企业可以有效降低软件供应链中的安全风险，保障自身业务的稳定运行和数据安全。在实际操作中，应根据具体情况灵活应用这些控制措施，并不断优化和完善供应商管理策略。

软件供应链供应商安全控制全解析

在软件供应链安全管理中，上述各项供应商安全控制措施相互关联、缺一不可。接下来，我们将进一步探讨这些控制措施在实际应用中的要点和注意事项，以及如何构建一个全面、有效的供应商安全管理体系。

13. 持续供应商管理要点

持续供应商管理是保障软件供应链安全的长期任务。供应商的安全态势并非一成不变，可能会受到多种因素的影响而发生变化。以下是持续供应商管理的一些关键要点：
- 定期评估 ：建立定期评估机制，按照一定的时间间隔（如每季度或每年）对供应商进行全面评估。评估内容应涵盖前面提到的各个控制方面，确保供应商始终保持良好的安全态势。
- 数据监控 ：利用数据分析工具，对供应商的安全相关数据进行实时监控。例如，监控系统日志、漏洞报告、安全测试结果等，及时发现潜在的安全问题。
- 沟通与协作 ：与供应商保持密切的沟通与协作，及时了解其组织架构、业务流程、技术更新等方面的变化。通过建立良好的合作关系，共同应对安全挑战。
- 应急响应 ：制定应急预案，当供应商的安全态势出现严重下降或发生重大安全事件时，能够迅速采取措施，如启动补偿控制、更换供应商等，减少对企业业务的影响。

14. 各项控制措施的协同作用

各项供应商安全控制措施之间存在着紧密的协同关系，共同构成了一个完整的安全防护体系。例如：
- 选择与评估阶段 ：Control SP - 01 和 Control SP - 02 将网络安全纳入供应商选择和评估流程，为后续的安全管理奠定基础。通过对供应商网络安全态势的评估，可以筛选出具有良好安全基础的合作伙伴。
- 安全流程与开发阶段 ：Control SP - 05、Control SP - 06、Control SP - 07 等控制措施确保供应商在安全开发流程、培训、测试等方面具备完善的机制。这些措施相互配合，从代码编写到产品发布的整个过程中保障软件的安全性。
- 运营与维护阶段 ：Control SP - 08、Control SP - 09、Control SP - 10 等控制措施关注软件的构建管理、漏洞修复、云环境安全等方面。它们共同保障软件在运营过程中的稳定性和安全性，及时发现并解决潜在的安全隐患。

为了更清晰地展示各项控制措施的协同作用，以下是一个表格：
| 阶段 | 相关控制措施 | 协同作用 |
| ---- | ---- | ---- |
| 选择与评估 | Control SP - 01、Control SP - 02 | 筛选安全可靠的供应商 |
| 安全流程与开发 | Control SP - 05、Control SP - 06、Control SP - 07 | 确保安全开发流程和实践 |
| 运营与维护 | Control SP - 08、Control SP - 09、Control SP - 10 | 保障软件运营安全和漏洞修复 |
| 合同与管理 | Control SP - 13 | 规范供应商责任和义务，保障长期安全 |

15. 构建全面的供应商安全管理体系

为了有效实施各项供应商安全控制措施，企业需要构建一个全面的供应商安全管理体系。以下是构建该体系的步骤：
1. 制定政策与标准 ：根据企业的业务需求和安全策略，制定明确的供应商安全政策和标准。政策应涵盖供应商选择、评估、管理等各个环节的要求。
2. 建立评估机制 ：设计科学合理的评估指标和方法，对供应商进行定期评估。评估结果应作为供应商合作的重要依据。
3. 加强培训与教育 ：对企业内部员工和供应商相关人员进行安全培训和教育，提高安全意识和技能。培训内容应包括网络安全知识、安全开发实践、应急响应等方面。
4. 建立沟通渠道 ：与供应商建立有效的沟通渠道，及时传递安全要求和信息。通过定期会议、报告等方式，保持双方的信息共享。
5. 持续改进 ：定期对供应商安全管理体系进行审查和评估，根据实际情况进行调整和改进。不断优化管理流程和控制措施，提高体系的有效性。

下面是一个 mermaid 流程图，展示构建供应商安全管理体系的流程：

graph LR
    A[制定政策与标准] --> B[建立评估机制]
    B --> C[加强培训与教育]
    C --> D[建立沟通渠道]
    D --> E[持续改进]
    E --> A

16. 实际应用案例分析

为了更好地理解供应商安全控制措施的实际应用，我们来看一个实际案例。某大型企业在采购软件服务时，严格按照上述控制措施对供应商进行管理。
- 选择与评估阶段 ：在选择供应商时，该企业将网络安全作为重要的评估指标，对多家供应商进行了详细的评估。最终选择了一家在网络安全方面表现出色的供应商。
- 开发与测试阶段 ：要求供应商提供安全开发实践、培训计划、安全测试报告等证据。在开发过程中，对代码进行了严格的审查和测试，确保软件的安全性。
- 运营与维护阶段 ：定期对供应商的系统进行漏洞扫描和安全评估，及时发现并修复潜在的安全问题。同时，与供应商保持密切沟通，共同应对安全挑战。
- 合同管理阶段 ：在合同中明确了双方的安全责任和义务，包括漏洞修复的 SLA、数据保护要求等。通过合同约束，保障了企业的合法权益。

通过实施这些控制措施，该企业有效降低了软件供应链中的安全风险，保障了业务的稳定运行。

17. 未来趋势与挑战

随着信息技术的不断发展，软件供应链安全面临着新的趋势和挑战。以下是一些值得关注的方面：
- 新技术的应用 ：人工智能、物联网、区块链等新技术的广泛应用，给软件供应链安全带来了新的风险和机遇。企业需要不断学习和适应这些新技术，加强对其安全管理。
- 供应链全球化 ：软件供应链的全球化使得供应商分布更加广泛，增加了管理的难度。企业需要建立更加完善的全球供应链安全管理体系，应对跨国供应商的安全挑战。
- 法规与合规要求 ：各国政府对数据安全和隐私保护的法规要求越来越严格。企业需要确保供应商符合相关法规要求，避免因合规问题带来的法律风险。

面对这些未来趋势与挑战，企业需要不断创新和改进供应商安全管理策略，加强技术研发和人才培养，提高自身的安全防护能力。

18. 总结

软件供应链供应商安全控制是保障企业软件安全和业务稳定运行的关键。通过实施上述各项控制措施，企业可以有效降低安全风险，提高软件质量。在实际应用中，应根据企业的具体情况，灵活运用这些控制措施，并不断优化和完善供应商安全管理体系。同时，关注未来趋势与挑战，提前做好应对准备，确保企业在不断变化的安全环境中保持竞争力。

以下是对所有控制措施的总结表格：
| 控制编号 | 控制内容 |
| ---- | ---- |
| Control SP - 01 | 将网络安全融入供应商选择和评估流程 |
| Control SP - 02 | 研究供应商的网络安全态势，评估风险和透明度 |
| Control SP - 03 | 要求供应商提供其 IT 安全控制的证据，特别是针对软件开发系统、环境和基础设施的防御措施 |
| Control SP - 04 | 评估供应商的技术领导力，要求提供供应商应用安全组织结构和问责制的证据，并与关键供应商的网络安全领导者建立关系 |
| Control SP - 05 | 要求供应商提供其安全开发实践、框架和控制的证据 |
| Control SP - 06 | 要求供应商提供其网络安全意识、安全开发生命周期流程、安全编码和安全测试的培训计划证据，以及开发前强制培训的政策 |
| Control SP - 07 | 要求供应商提供或演示其包括威胁建模、安全编码实践、静态代码分析和安全测试在内的安全开发实践 |
| Control SP - 08 | 要求供应商提供或演示其构建管理、DevSecOps 和发布管理实践，包括工具、报告、流程、访问控制、批准以及工具和事件管理系统的日志 |
| Control SP - 09 | 要求供应商提供其扫描、漏洞管理和补丁流程的证据，包括政策、程序、报告、日志和补丁服务级别协议 |
| Control SP - 10 | 要求供应商提供其云基础设施、访问控制、密钥、配置、测试、责任和服务级别协议的管理实践和报告的证据 |
| Control SP - 11 | 要求供应商提供其开发服务的证据，包括代码质量报告、测试报告和漏洞情况。适用时，要求提供开发人员信息，如位置和背景调查证据 |
| Control SP - 12 | 要求供应商提供对任何有权访问软件或固件的人员或流程的访问控制和完整性检查的证据 |
| Control SP - 13 | 在供应商签约过程中纳入网络协议，根据采购组织的政策包括网络风险和最低安全标准 |

通过对这些控制措施的深入理解和有效实施，企业可以构建一个安全可靠的软件供应链，为业务的发展提供有力保障。