在传统意义上，软件的提供商已经实施了软件开发生命周期(Software Development Lifecycle，以下简称SDLC)管理程序，以确保软件开发实践中采取结构化和统一的方法，确保SDLC流程的所有阶段（规划、设计、构建、发布、维护、支持和退役）都将以可控的方式执行。虽然实施这些程序是为了实现高质量的功能性产品，但它们并不一定会涉及到安全因素。

“确保产品安全”的步骤通常是SDLC流程的附加步骤，在许多组织中，安全性被视为“可有可无”的检查或产品验证流程的最后一步。不过，这种对安全的不重视不会继续下去。安全设计实践和产品内置的安全功能正越来越频繁地成为大型企业客户对软件产品的必需要求。这是由于第三方软件漏洞激增，以及过去几年经历的物化供应链攻击（例如SolarWinds、Log4j、3CX、MOVEit）的高度影响。

因此，企业客户，特别是那些具有高购买力和议价能力的客户，不仅对新的、革命性的软件产品感兴趣，而且对安全、易用的产品同样感兴趣。对于软件制造商和供应商来说，这意味着安全不再是一种选择，而是一种“必须拥有”，当有疑问时，我们应该问自己一个非常简单的问题：如果我们的客户将他们最重要的资产（数据）委托给我们，我们难道不应该向客户提供同等水平的安全、可信和透明的软件产品吗？

开发具有设计安全性的优秀软件

但实现安全的软件开发生命周期(Secure Software Development Lifecycle ，以下简称SSDLC)过程并不那么简单。第一步是询问我们的组织是否准备好了这样的流程；不仅要开发优秀的软件，而且要牢记安全设计原则。领导层对安全的承诺在这里变得至关重要。当有来自高层的参与时，安全性就不再是可有可无，而成为一种管理声明、公司原则、共同的团队价值观、切实的目标、细化和规划期间的优先事项、跨SDLC的强制性步骤和检查集、管理报告中的KPI/KRI（译者注：KRI，关键风险指标，详细内容可阅读CRISC）等等。当这种情况发生时，安全性不再是一个单独的“待办事项”，而是嵌入到我们团队的DNA中，我们开始按照我们做出的承诺交付产品，从证明我们的健壮性、可靠性、可持续性和透明度转向展示我们的健壮性、可靠性、可持续性和透明度。

2022年2月，NIST发布了安全软件开发框架(Secure Software Development Framework ，以下简称SSDF)1.1版，描述了在SDLC过程的所有阶段均嵌入了安全性的建议。在这个框架中，NIST提出了四组实践：

1. 准备组织(PO)：组织应确保其人员、流程和技术均做好了在组织一级执行安全软件开发的准备。

2. 保护软件(PS)：组织应保护其软件的所有组件免受篡改和未经授权的访问。

3. 生产安全良好的软件(PW)：组织应生产安全良好的软件，并将其发布时的安全漏洞降至最低。

4. 响应漏洞(RV)：组织应识别其软件版本中的残余漏洞，并做出适当的响应。

所有四组实践都提供了高级原则和基础概念示例，以满足安全软件产品应该是什么的标准。在每一项实践中，NIST还涉及到我们应该如何管理第三方软件组件引入的安全风险（大约占整个框架的20%）。

随着软件开发社区认识到面向组件的开发可以节省时间并提高定制软件的质量，第三方组件的使用持续增长，无论是自动售货软件还是开放源代码软件(Open-Source Software ，以下简称OSS)。研究表明，总代码库使用中76%通常是OSS代码，这意味着OSS在我们的软件组合中的权重是相当大的。但总体来说，OSS和第三方组件仍然被忽视，或者我们只是继续假设，如果它们被广泛分发和使用，那么它们必须是安全的。因此，当涉及到第三方组件风险时，一直存在一种错误的安全感。ISACA的《2022年供应链安全研究》显示，对于受访公司：

● 近五分之一的第三方评估不包括网络安全和隐私评估

● 39%的受访者尚未与供应商一起制定应对网络安全事件的事件响应计划

● 49%的受访者表示，他们不会对供应链进行漏洞扫描和渗透测试

● 61%的受访者表示，他们的风险评估不包括专门针对使用人工智能(AI)设备的供应链风险评估

然而，由于最近的软件供应链攻击，公司正试图深入地了解他们的供应链依赖关系，并了解这些攻击给其环境带来的风险。接下来，我想对NIST框架进行扩展，并阐明软件制造商、供应商和客户可以应用哪些实践来有效地管理第三方组件风险，作为SSDLC流程的一部分：

1. 在引入第三方组件之前进行目的、可行性和可维护性研究：

就像采购工具或专业服务供应商一样，不应低估第三方软件组件采购流程的重要性。因此，重要的是要制定一些基本规则来选择和实施适当的组件：

定义目的：评估多个组件以确定哪个组件最能满足所需的功能。记录至少三个首选组件的优缺点。

确定可行性：评估开发自己的功能与使用第三方组件的短期和长期成本。评估整合工作的可行性和成本，以及维持这一目标的资源。

分析可维护性：由于短期交付产品的时间紧迫，组件的可维护性经常被忽视，因此组件的可维护性应该是决定是否应该使用它的决定性因素。要解决的简单问题包括：该组件是否有足够的文档和支持？有产品路线图吗？组件是否定期更新？我们能跟上所有更新吗？我们能够阻止遗留组件吗？

2. 第三方软件组件也应接受第三方风险评估：

业务影响评估(BIA)和第三方风险评估(TPRA)已被广泛采用为了解供应商风险的首选方法，并根据供应商是否符合我们的风险偏好来拒绝或接受供应商。工具和服务的供应商最常受到这些演习的影响，而我们自己的软件产品的第三方组件通常不受影响。无论是发送电子邮件的应用程序、翻译解决方案还是人工智能驱动的聊天机器人，所有类似应用程序的组件都应该根据供应商的安全和隐私相关标准进行评估。这些标准可以包括我们的加密要求、第三方的补丁管理和漏洞披露计划、产品安全事件响应能力、SOC 2报告审查、ISO 27001适用性声明(SOA)和数据保护政策审查，以及组织认为重要的其他关键要素。应使用导致风险或发现的 TPRA 来决定是否批准使用某个组件，并定期审查和跟进。

3. 使用软件组成分析(SCA)和SBOM来加强安全性：

就像我们对所消费的食品的成分感兴趣一样，对构成我们的软件产品的成分感兴趣可以为我们提供关于这些成分的安全性、合规性和可维护性的有意义的信息。利用软件组成分析(Software Composition Analysis，以下简称SCA)等自动化解决方案来分析软件物料清单(Software Bill of Materials，以下简称SBOM)可以成为更好地控制我们的软件产品和主动管理供应链风险的良好开端。根据格式的不同，无论是SPDX、CycloneDX还是SWID，SBOM都可以向我们提供产品组件的数据来源，例如制造商名称、软件包版本、许可信息、漏洞、软件包关系、服务、依赖关系等。此类来源信息可以帮助我们识别许可证冲突和合规性问题、安全漏洞、VEX(Vulnerability Exploitability Exchange，漏洞可利用性交换)、文件完整性，并潜在地识别“高风险”组件，例如废弃软件（两年或更长时间内未更新）、空包（无源文件）和本机二进制代码（通常与包的类型无关的可执行代码，可用作攻击向量）。根据此类分析的结果，我们可以决定哪些组件必须被制裁（被列入黑名单），哪些其他组件被批准（被列入白名单）。

在我们的第三方风险管理程序中使用SBOM，并将其作为SSDLC流程的基本元素，可以提高开发人员社区、软件制造商、供应商和客户之间的透明度。它使我们在零日威胁和供应链攻击方面领先一步，同时帮助我们交付质量更高的可持续软件。

其他重要考虑因素

在保护我们的产品免受供应链攻击的过程中，如果没有正式任命产品负责人(Product Owners，POs)，仅实施SSDLC政策和第三方风险管理程序是不够的。无论所有权是在聚合产品级别还是在组件基础上，组织内必须有人拥有对产品及其组件的安全端到端生命周期管理的所有权。

此外，应维护所有产品和基础组件的最新清单，并指定风险分类（例如，高、中、低风险）。盘点我们拥有的东西，特别是我们批准或不批准的东西，对于了解我们的产品风险状况、其复杂性以及出现问题时的业务影响至关重要。

最后，正如俗语所说，“信任，但要验证”。如果我们不进行独立审查来验证流程是否按预期工作并且风险得到识别和控制，那么流程永远不会被标记为有效。至少，应对照预期的安全开发生命周期实践对高风险产品进行审计，并应注意其第三方组成和依赖关系。

了解表面之下的内容

学习将安全性视为我们软件产品设计、构建和实施的关键要素需要我们培养意识和作出承诺，但了解第三方组件在实现所需产品安全级别方面所起的影响则是更进一步的要求，并不是每个人都做好了准备。如果您真的关心所提供的产品的质量，那么检查并挑战表面之下的内容，多层级的关系和相互依赖性。说到底，最终产品将始终是其生命周期中涉及的所有组件、工作方式、检查和程序的集合，只有当我们全面了解所有这些部分的弱点和改进机会时，我们才能确保它的安全。