美国政府发布软件供应链供方实践建议指南

 聚焦源代码安全，网罗国内外最新资讯！

专栏·供应链安全

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

美国国家安全局 (NSA)、美国网络基础设施安全局 (CISA) 和国家情报总监办公室（ODNI）联合发布《软件供应链供方实践建议指南》。指南报告提到，由于保护软件供应链安全基于组织机构在供应链中扮演的角色，因此三部门所发指南将分为三个系列，分别针对开发人员、供方和客户。目前已发布针对开发人员的软件供应链安全实践建议指南，此为第二份指南，第三份针对客户的指南将于后续发布。这一系列软件供应链安全实践建议指南将有助于这三个不同角色之间以及网络安全专业人员之间的沟通，以提高软件供应链流程中的弹性和安全性。
如下是奇安信代码安全团队对该指南主要内容的编译。

1、 引言

本指南报告提到，之前软件供应链攻陷主要针对的是组织机构未修复的常见已知漏洞。虽然威胁行动者仍然在借此攻陷未修复系统，但目前他们不再等待公开的漏洞披露，而是主动将恶意代码注入将通过全球供应链被分发给下游的产品中。过去几年来，这些下一代软件供应链攻陷活动对于开源和商业软件产品而言都急剧增加。

技术客户通常会将软件下载与更广泛更传统的软件供应链活动分开管理。同时考虑软件作为供应链风险管理组件的上游和下游阶段，有助于发现问题并提供更好的系统化安全方法。然而，在软件产品方面，二者还是存在一些区别。传统的软件供应链周期是从起始点到消费点，通常可使客户退回无法正常运行的产品并限制任何影响。相反，如果软件包中被注入恶意代码且被分发给多个客户，则这种影响范围更难以控制且可能造成指数级影响。

常见的软件供应链攻陷方法包括：利用软件设计缺陷、将易受攻击的第三方组件集成到软件产品中、在最终软件产品交付前通过恶意代码渗透供应链网络，客户部署后注入恶意软件。

利益相关者必须缓解各自责任范围内的安全问题。然而，其它安全问题可能要求这样一种缓解方法：规定对另外利益相关者的依赖，或者多个利益相关者共享的责任。沟通或解决不当的依赖关系可能会导致漏洞和攻陷发生。

这类漏洞可能存在的地方包括：

• 未记录的特性或高风险功能

• 未知修改和/或对评估和部署之间的合同、功能或安全假设的修改

• 供方所有权和/或地理位置的变更，以及

• 不良的供方企业或开发清理

本文编译的是报告的第二部分，即提供针对供方（厂商）的最佳实践和标准，确保从生产到交付整个过程中软件的完整性和安全性。每个部分都包括威胁场景示例和推荐的缓解措施。威胁场景解释的是组成软件开发生命周期 (SDLC) 既定周期的流程如何关联可被利用的常见漏洞。所建议的缓解措施展示的是可减少威胁影响的控制和缓解措施。

2、 供方

供方充当开发人员和客户的接口人或中介，因此主要担负如下责任：
1、 维护安全交付软件的完整性

2、 验证软件包和更新

3、 保持关注未知漏洞

4、 接收客户报告的问题或新发现的漏洞并通知开发人员修复

软件安全开发和交付系统的目标是帮助保护软件代码、证明和完整性的安全，从而创建对软件供应链攻陷的弹性或完全禁止攻陷。

本章提到的威胁场景与《NIST SP800-218：采用软件安全开发框架 (SSDF)，缓解软件漏洞风险》一致。这些场景的目的是提供关于开发人员、供方和客户之间应当存在的高级沟通机制指南。虽然本章关注的是通过传统的、本地化方法交付的软件，但也会讨论适用情况下的软件即服务 (SaaS) 交付。

2.1 组织机构做好准备

2.1.1 定义软件安全检查标准

应当设立并执行确保安全交付软件的具体检查策略。所有SDLC中的角色均应当能够访问并知晓这些策略，而且应当包括将漏洞、将使用的缓解机制以及生命周期 (EOL) 支持告知客户。

威胁场景：本地

如下示例场景可制造可利用的漏洞：

1、 策略不存在或者未明确定义。

2、 团队未意识到或者在整个SDLC过程中未执行策略要求。

3、策略要求未非包容性（例如，不存在通知客户漏洞的明确机制），或者未在产品的EOL中提供客户支持。

缓解建议

如下缓解措施有助于降低与部署流程相关联的威胁和风险：

1、验证所交付的软件和所收到的软件一致。

2、创建完全签名的镜像和二进制。

3、确保用于验证该二进制的哈希是安全的。

4、确保通信信道是安全的。

5、设立和执行安全的更新/补丁流程。

6、验证可执行文档的修订层级：

（a） 应当执行版本控制

（b） 确保变更时间戳

（c）应当执行版本控制系统，在必要时恢复。

7、利用国际认可的标准如NIST SSDF，验证已开展组织机构检查；该标准有助于确保在软件发布前以及整个软件生命周期中，满足软件功能和安全要求。

2.2 保护软件

2.2.1 保护所有格式的代码不受越权访问

应当保护所有格式的代码不受越权访问和篡改，应当在整个SDLC中应用最低权限原则。这对于确保交付给客户的代码中包括所有所需安全特性且这些特性按设计运作至关重要。包括代码中不包括额外的且可能隐藏的、将降低安全性功能（如后门或硬编码密码）。

威胁场景：本地化

如下情境展示了对软件代码完整性的威胁：

• 具有未授权访问权限和能力的人员清晰地查看了未加密的、未混淆的设计或源代码；

• 构建和交付流程中的代码或程序包遭越权修改或删除；

• 在将软件交付给客户前，对文档、代码或程序包实施了越权修改或删除。

• 存在后门或硬编码密码，可导致后续的越权访问。

缓解建议

• 执行基于角色的访问控制 (RBAC)，职责分离，践行最小权限

• 识别并审查可信任架构师、开发人员、测试人员和文档人员完成该项目的必须技能。

• 根据个体能力和兴趣，为不同人员分配一个或多个涉及、编程和质量保证 (QA) 任务，并基于他们在安全访问控制系统中的相应项目角色注册权限。

• 验证为每个个体分配的企业发布的开发系统符合所有的公司安全标准，包括全磁盘加密、最低密码复杂度、补丁管理；反病毒和入侵检测系统，基于AI的端点防护平台和端点检测和响应、数据丢失预防 (DLP) 等。

• 确保代码仓库、构建和测试环境的安全防护措施至少和关键网络能力如网络分段、防火墙、监控、自动化加密和远程备份的防护措施一样。

• 确保仅有企业发布的或批准的开发系统才能访问使用多因素认证或基于行为分析的持续认证的开发、构建和测试环境，且仅通过具有物理安全性的办公网络或通过VPNs访问。确保检测、报告和调查失败的访问尝试情况。对于移动或远程工作的员工而言尤为重要。

• 审计第三方软件（如使用二进制软件成分分析）并确保所含模块的安全性。

• 使用代码签名系统，交付经过数字签名的代码和相关联的支持文件。该代码签名系统保护敏感的签名密钥，且使用硬编码防护如FIPS 140-2/-3 硬编码安全模块 (HSM)。

• 在开发和运维支持团队中建立强大的安全文化。

• 审计人员、任务、系统和策略，确保它们是适当的、必要的和完整的。同时采用计划式样和事件触发式审计。

威胁场景：SaaS

如下说明了可被利用的云原生软件开发场景示例：

• 承诺更快上市、更好扩展性和管理性、低成本，同时维护同等开发安全性和完整性的软件开发流程，

• 采用要求变更本地开发和分发流程以及安全和安全管理的新方法，

• 关键变更，如采用容器化和微服务架构。

缓解措施建议

如下缓解措施有助于降低与开发流程相关联的威胁和风险：

• 使用强大的应用认证、授权、代码扫描、漏洞分析和数字化签名，

• 这些实践应当按需扩充，以解决与端点和运营云安全相关联的其它认证问题。

2.2.2 验证软件发布完整性的机制

供方应当提供软件发布完整性验证机制，在整个软件生命周期中对代码进行数字化签名。经过数字化签名的代码可使接收者积极地验证并信任代码的证明和完整性。

威胁场景：本地化

缺乏可验证的证明和完整性，将使如下场景更容易发生：

• 对软件支持活动具有访问权限的攻击者可用恶意软件替换合法组件；

• 对软件支持活动具有访问权限的攻击者可将恶意代码插入合法组件中；

• 恶意代码插入可能发生在交付之前的供方一方，或者发生在使用前的接收者一方。

缓解建议

如下缓解措施有助于降低威胁和相关风险：

1、数字化签名代码，以便接收人员能够验证并信任代码的证明和完整性

（a） 由于代码签名仅在代码签名后提供防护益处，因此要缓解代码签名前发生的代码篡改和恶意代码注入风险，建议组织机构考虑执行可验证的构建流程，作为签名代码之前的节点。

（b） 该可验证的构建系统应当由逻辑上隔离的生产构建环境的次镜组成，该环境独立地编译和封装代码，与生产构建环境编译和封装例程并行。

（c） 可对比这两个平行操作的哈希结果，而且如果验证结果匹配，则可签名生产构建工件。

（d） 应当使用由受信任证书机构发布的代码签名证书来签名最终修订的二进制代码，应当提供验证这些签名的机制。

2、 设立和执行关键管理程序，包括：

（a）应当在HSM上安全地存储用于代码签名操作的私钥，缓解代码签名密钥被盗的风险，

（b）应当通过正确的基础设施安全控制，保护访问存储在HSM或代码签名基础设施上的关键材料和流程的系统，

（c）应当通过正确的基础设施安全控制保护代码签名操作，缓解代码签名密钥错用和滥用风险。

3、在安全检查清单中包括签名验证，且确保正确执行：

(a) 记录官方安全配置指南或同等文档中的签名验证机制或流程，

(b) 如第三方供方签名验证机制不适用于允许第三方供方的架构，则应开发并提供定制化的编程方法，

(c) 第三方软件的供方应当在收到软件包时以及在将其继承到任何内部构建流程前，设立对软件包真实性和完整的验证检查，

(d) 签名验证机制应当包括证书撤销清单检查和信任链验证，

(e) 在签名中包括由时间戳机构发放的时间戳。

2.2.3 归档并保护每个软件发布

组织机构应当设立归档策略，允许组织机构指定主要发布和次要发布。 某些组织机构受特定标准如支付卡行业数据安全标准、HIPAA等的制约。这些标准对供方提出了频率和留存要求。然而，每个软件供方判断如何应当归档软件、在覆写或破坏前应当留存多久以及应当存储在何处。归档的软件发布可用于灾难恢复，也可用于网络事件取证调查。

威胁场景：本地化

缺少或不恰当地在企业范围内设立用于判断哪些文件和元数据应当存储在一起的策略，增加了如下威胁策略发生的可能性：

• 会用不安全、不易访问或不可用的不恰当存储媒介类型；

• 不经常审计文档，或审计与组织机构留存策略不符。

缓解建议

通过将所发布软件迁移到已归档状态（通常是成本更低的存储区域），组织机构可节约成本并为更关键的软件项目分配更快的存储速度。这一流程通过减少员工打开正在开发的文件和访问相关联元数据的时间，提高生产力。如下缓解措施有助于降低相关风险和威胁：

1、建立具有正确访问控制的仓库

2、确保代码和编译的可执行文档在永久文档中维护。

3、应当限制文档权限，并将软件存储为只读模式以防遭修改。以只读模式创建文档，以便在紧急、调查或数据泄露的情况下保证其完整性。这一方法同时确保客户可在软件遭攻陷的情况下仍可访问软件。

4、存储文档的媒介由组织机构判断，而决策通常取决于媒介的便利性、可靠性和可用性。组织机构一般使用网络存储和其它媒介如磁带设备。

(a)  磁带媒介对于需要低成本在较小空间存储大量数据的一些组织机构而言是标准做法。然而，该媒体的检索和恢复可能是个问题；

(b)  附加网络驱动也很常见，但这种媒介更为昂贵。网络存储的托管需要房地产进行托管以及昂贵的硬件来确保安全性并进行维护。然而，不像多数磁带系统，网络驱动提供的归档数据在组织机构或调查人员需要访问时是现成可用的，

(c)  云储存的优势是可用性和低成本，但速度取决于组织机构的带宽和网络速度。很多组织机构为获得便利性和低成本而迁移到云储存。然而，确保数据安全仍然是组织机构的责任。

(d)  其它存储类型如下：

• 块存储服务，它所暴露的软件定义块设备可展示到在云中运行的虚拟主机中，

• 对象存储服务，可映射到主机、应用甚至是其它云服务，可解决ID或元数据的离散、非结构化数据元素，

• 可扩展共享文件系统，可使可扩展主机集告诉访问相同的文件系统。

5、数据一般是通过软件自动归档的。归档软件所提供的特性和能力取决于供方，但多数供方在每种平台上都具有标准的特性：

(a)  系统管理员配置将被归档软件的时间、位置和频率。创建归档策略，判断迁移数据背后的规则。管理员通过归档策略确保，转移到存储位置的数据遵循适当的规定标准和要求，

(b)  同时也有必要使用与其它归档规则联合的留存策略。留存策略判断在覆写或毁坏数据前归档可停留的时长。备份的一般留存策略约为30天，但所归档数据可能在被毁坏前会留存更久的时间。某些组织机构在替换媒介或删除文档前，持有归档数据的时间为数年之久。对于最敏感的数据而言，归档永远不会被覆写或毁坏。归档和合规标准可能存在留存的策略要求，因此组织机构应当确保配置不会违反任何规定标准。

2.3 生产安全的软件

2.3.1 涉及满足安全要求的软件

生产安全的软件并缓解安全风险是交付软件的关键目标，允许客户仅访问获得授权的信息和资源，禁止访问未获授权的信息和资源。为此，安全要求必须是准确完整的、代码必须符合这些要求，以及必须修复任何可利用的漏洞。

威胁场景：本地化

如下是可利用的示例场景：

• 开发人员未在SDLC中应用安全开发实践，

• 开发人员或相关安全团队未得到正确的威胁或风险评估培训

• 设计或运营要求未得到完全理解或执行

缓解建议

如下缓解措施有利于减少与该流程相关联的威胁和风险：

• 演示安全开发生命周期实践和流程，包括定义预期环境的设计标准，

• 执行威胁建模，实现安全目标；

• 获得尽可能多的软件来源和运维环境信息；

• 使用技能较高的软件架构师和安全专业人员，开展威胁和风险评估，了解不同的部署场景、事件和运维错误如何影响软件达到要求的能力；

• 记录设计和运营假设，以便更加容易地评估要求所产生的影响和其它安全变化。重新访问开发周期中的设计假设和决策。

威胁场景：SaaS

软件开发人员在SaaS解决方案中使用可持续交付或可持续部署方法论，集成安全性。如下是可利用的示例场景：

• 攻击者或不知情的员工可能将易受攻击的代码引入仓库，触发自动构建和部署编译代码，

• SaaS解决方案客户可能易遭系统上易受攻击代码的利用，

• 单个SaaS解决方案中不同模块之间的安全要求差异可能导致对所有组件的验证不充分，

• 威胁行动者或恶意内部人员可能攻陷由第三方供应商提供但并未由供方或第三方供方验证的模块。

缓解建议: SaaS

如下是威胁缓解示例：

• 在SaaS 供方和所有相关联子承包商和第三方供方之间设立、执行和验证常见的安全要求；

• 定义软件产品的安全评估常用工具，这些软件产品必须由负责代码开发的所有方适用；

• 在最低权限执行环境中，执行安全性未被完全审计的任何代码，直至代码得到完全评估。

2.3.2 按照安全要求，评估第三方供方软件

组织机构中通常存在由第三方提供的软件，它们或存在于组织机构中或包含于其它产品中。供方必须确保原生开发的软件和由第三方获取的任何组件符合安全要求规定。

威胁场景：本地化

如下是可被利用的场景示例：

• 供方、第三方供方和客户之间的合同协议可能是“级联的”；第三方软件是额外漏洞的潜在来源，

• 供方在做出是否使用由电放提供的软件组件的风险决策时，排除常见因素（如地理位置、供方所有权/控制和历史表现），

• 未在软件工程质量（如圈复杂度）、最小加密密钥长度、识别获批加密算法、识别获批库或编译器选项中表达安全要求。

缓解建议

如下是缓解措施示例：

1、验证第三方软件是否符合安全要求；从而降低与使用所购买软件模块和服务相关联的风险。

2、评估第三方提供的软件是否符合可用的安全要求：

(a)   定义安全要求（如最小密钥长度、使用FIPS 140-2密码算法）

(b)  如适用，通过合同协议与第三方供方沟通安全要求。合同协议中还应当包括漏洞披露/缓解要求或事件报告，

(c)   定义表示符合安全要求的测试（如源代码分析、源代码增量分析或二进制代码分析）

(d)  定义重新评估安全要求和测试的流程。

(e)  识别受已修改或额外安全要求和测试影响的第三方软件。

(f)    定义缓解满足可用安全要求的第三方软件的流程。

3、确保合同协议解决潜在的第三方安全问题：

(a)   在可能的情况下，准备合同协议。协议应当详述安全要求内容，并要求及时披露漏洞和SDLC实践等。

(b)  如第三方软件满足安全要求 [NIST SSDF PO.2]，则仅拷贝可用的第三方软件，应当提示具体的安全要求。应当仅从由组织机构维护的只读位置获取拷贝。

4、审计第三方软件，将其作为额外漏洞的潜在来源：

(a)   维护含有获批第三方软件的只读位置，识别符合 [NIST SSDF PS.1] 的安全要求，

(b)  拒绝使用从非只读位置获取的第三方软件，

(c)   仅允许使用安全要求符合所开发软件安全要求的获批的第三方软件

• 如（新的）测试表明违反（新的）安全要求，则不批准第三方软件

• 如判断认为第三方软件不符合（新的）安全要求，则记录所采取措施

(d)  设立并在必要时更新企业策略，该策略要求仅使用最适合的或最新的第三方软件版本：

• 企业策略中的示例用例可提出更新第三方软件的要求：当新版本可用时、新版本修复了一个严重漏洞时，第三方软件每X次的次要发布以及第三方软件的每个主要发布。

2.3.3 配置编译和构建流程

不管构建流程是“全部”还是“增量”，规定它是否是通过“从未见过”还是“最后构建状态”执行的。对依赖进行完整的构建检查、编译所有来源文件、按顺序构建所有部分以及将其汇编到构建工件中。

在增量构建实例中，构建检查并对比上次构建以来依赖于目标进行修改的来源和其它文件。如存在修改，则目标将被重建，否则将会复用上次构建的文件。

威胁场景：本地化和SaaS

如下是可被利用的示例场景：

• 能够访问生产构建环境中软件流程和工具的攻击者，可能将恶意软件插入组件中，

• 编译和构建流程配置不当，可能攻陷可执行文件的安全性，

• 对生产构建流程和所生成的二进制工件完整性的安全保护不当。

缓解建议

必须将用于编译和构建软件组件的流程配置为默认安全，以便确保所有二进制生产代码工件的完整性。应当执行如下控制，加固软件编译和构建流程：

1、组织机构应当为软件编译和构建中涉及的所有工具建立并维护受信任的工具链；应当将这些工具配置为已知的安全基线状态、记录，并通过在配置管理数据库中维护的清单进行追踪，持续监控新出现的安全漏洞，并根据所定义的修复时间线接受正确的安全更新。

2、应当将所有的构建流程自动化，应当将所得脚本和元数据安全地存储在版本控制系统中，将权限限制到构建组件的个体。

3、应当使用非互动性服务账号来调用自动的构建流程，确保构建输出是服务生成的且非可证伪的。

4、应当使用已经获得批准的方法，将服务账户认证凭据执行自动化编译和封装的流程是可信任的。

5、 应当在逻辑隔离且不受外部影响的实证环境中执行自动化的构建流程。

6、 自动化国建流程应当生成并维护构建表示，找到确保构建可复现性的构建器、来源、入口点和参数。

7、 启用安全的编译器设置，帮助阻止或限制某些安全问题类型的有效性，尤其是缓冲区溢出漏洞（基于堆和基于栈）。安全编译器设置的示例可能包括但不仅限于：

(a)  启用二进制输出的符号剥离

(b)  启用数据执行防御

(c)  启用安全的结构化异常处理

(d)  运行时安全检查

(e)  启用地址空间分布随机化

(f)   如可在编译时间判断数组索引超出边界，则清除错误

(g)  检测到对地址指针的可疑使用时，清除提醒

8、组织机构应当考虑执行由逻辑隔离的生产构建环境次镜组成的可验证构建流程。该环境独立编译并构建安全组件，与生产构建环境并行。可对比这两个平行操作的哈希结果，验证构建流程的完整性。

2.3.4 审计或分析人类可读代码

软件应当包括运营和安全功能，在做出信息安全评估时应当同时考虑这两种功能。对于采购、管理和部署流程而言，尤为重要。使用安全特性强大的软件包的组织机构可降低信息安全风险暴露和其它问题。

在计算所有权、风险缓解和控制、运营成本和整体业务价值时，应当考虑底层的软件质量和软件技术的安全性。它有助于确保软件包安全性、功能性和价值的信心水平。质量措施应当包括对将被审计的人类可读代码的限制，识别漏洞并验证是否符合所有要求。

威胁场景：本地化

如下是可被利用的示例场景：

• 无法轻易审计或分析代码，无法帮助识别漏洞和验证合规性

• 安全功能不当，无法满足采购、管理或部署要求

缓解建议

如下是缓解措施示例：

1、设立安全保证计划，要求：

(a)   已执行安全风险评估

(b)  已为正在开发和/或维护的软件和数据设立安全要求

(c)   每个软件评审和审计包括对安全要求的评估

(d)  配置管理和修正操作流程为现有的软件提供安全性，变更评估流程阻止安全违规

(e)  软件和数据的物理安全性是恰当的

(f)    安全保证包括SDLC和CI/CD的要求、设计、实现、测试、发布和维护阶段

(g)  代码覆盖衡量单元测试覆盖。

2、审计和/或分析人类可读代码，确保符合已有安全保证计划的要求，识别漏洞并验证与已有要求的合规性：

(a)   产品定义和市场要求文档

(b)  产品章程、愿景和范围文档

(c)   要求和用户故事

(d)  设计文档

(e)  产品标准

(f)    验证规划

(g)  测试和验证规划和测试用例

2.3.5 测试可执行代码

应当测试可执行代码，发现漏洞并验证与安全要求的合规性。供方必须交付这样的软件：允许客户访问获得授权的信息和资源，同时阻止他们访问未授权信息。为此，供方和开发人员应当协力确保已缓解所有已知漏洞。

威胁场景：本地化

如下是可被利用的示例场景：

• 放弃实现或使用特权概念

• 缺乏或对漏洞的测试和扫描不当

• 误解、缺乏安全要求的实现或实现不当

缓解建议

如下是示例缓解：

1、获得清晰且完整的安全要求。请安全主题专家审计和验证这些要求，确保要求是明确的、适当的、全面的。

2、了解向美国政府售卖的治理和合规要求。

3、应当为所有的关键软件组件以及位于构建管道中的系统，开发威胁模型：

(a)   每种威胁模型应当由至少两个独立工程师审计并批准，

(b)  应当审计代码和系统中的关联威胁模型，应当按需做出变化，确保代码和系统中不存在结构性漏洞；

(c)   应当为主要发布或至少每年更新这些威胁模型。

(d)  应当向其它内部工程团队开放威胁模型，这些团队包括使用或操作任何关联软件组件或系统的团队。

4、开发测试计划，覆盖每种安全要求。代码覆盖应当是每个组件测试计划的关键元素且应当集成到每个构建中并作为实现测试计划的一部分。在理想情况下，应当在所有登记的代码上以及在新代码提交前，实现基准代码覆盖水平。

5、根据员工经验和资质组建安全测试团队。

6、提供充足测试资源（如硬件和软件）和执行测试规划的时间。

7、安全测试应当是每个软件组件QA计划的组成部分，且应当包括如下方面（参见 NIST SSDF）：

(a)   应当使用经公司批准的标准工具集，在每次发布前，在所有代码上执行静态和动态代码分析。应当记录测试结构，分析和缓解发现的所有漏洞。

(b)  在所有软件组件上执行模糊测试，确保它们在所有输入上展现预期行为。应当记录结果，缓解任何异常或漏洞。

(c)   根据潜在风险情况，应当每隔6到24个月，在所有软件组件上执行模糊测试（如应当更频繁开展对云产品的渗透测试）。应当记录结果，应当缓解任何异常或漏洞。

(d)  应当记录所有的安全测试结果，包括任何CVSS评分并缓解和验证安全缺陷。

8、作出变更后，在必要情况下，重复1-7步骤。

9、验证和记录所有安全要求均已得到满足。

2.3.6 将软件配置为拥有默认安全设置

有时，客户急于快速安装软件，偶尔可能在未完成适当配置的情况下或在未完全理解配置选项的情况下将其用于运营环境中。为阻止这类操作导致的攻陷，应当在安装时要求最小访问权限，允许客户在必要时明确启用额外的访问权限。

威胁场景

如下是可被利用的示例场景：

• 在配置全面或恰当执行前，安装并使用软件，

• 默认允许完全运营访问权限的软件安装，

• 不限制访问和/或执行管理员流程的软件，

• 未记录管理员或通用用户操作。

缓解建议

如下是示例缓解措施：

1、要求在本地或强加密的远程连接上，所有管理员/配置进行变更。

2、默认本地记录所有的管理员操作（包括尝试的和成功的认证和配置变更），且日志至少保存30天。

3、仅提供一个默认管理员账户，不提供任何默认的用户账户或访问权限。

4、要求客户首次登录后立即修改默认的管理员认证凭据，建议在可能的情况下使用MFA。

5、要求所有管理员账户凭据是充分复杂的（密码）或者具有充分的密码强度（证书）。在可能的情况下，任何账户的访问尝试都应当涉及MFA，经由具有物理安全性的办公网络和/或安全的VPN，以及/或基于行为分析的持续认证（可见NIST SP 800-207）。

6、禁用无需认证的服务和功能，直至明确启用。

7、密码恢复程序必须要求控制台或物理访问。密码重置程序应当恢复到初始状态。可参照NSIT指南，获得关于密码特征（如长度、复杂度、时间等）的更多信息。

2.4 漏洞响应

2.4.1 持续识别、分析和缓解漏洞

供方应当竭力确保公开已知的或轻易识别出的漏洞不存在于向客户提供的任何软件中。测试、了解和删除软件漏洞，帮助阻止提供在软件交付给客户前可被现成攻陷的代码。

此外，采购软件的客户对获取关于所购买软件证明和安全性的透明信息兴趣很大。下列控制旨在允许组织机构软件安全开发流程的透明度。未能执行这些步骤并维护一致性证据，可削弱对客户网络中运营的软件质量的信心。

威胁场景：本地化

如下是可利用的示例场景：

• 软件中包含已知和/或未披露漏洞，

• 测试或尝试删除已知漏洞的努力不完整或不恰当。

• 软件或组件的证明是未知的。

缓解建议：本地化

如下是缓解示例：

1、  创立由架构师、开发人员、测试人员、密码人员和人类因素工程师组成的漏洞评估团队，他们的目标是识别软件中的可利用弱点。

2、  对于软件能力而言，定义这样一种流程：使用已知环境分析、监控与软件能力相关联漏洞、以及对组合系统中个体单元进行未知的环境模糊测试。

3、  对于软件组件而言，定义这样一种流程：使用已知的环境分析、使用源或二进制成分分析工具监控与所识别软件组件相关联的漏洞、以及对组合系统中个体单元进行未知的环境模糊测试。

4、  投资最新的静态和动态评估工具。根据供方文档确保其为当前版本并执行它们。

5、  创立企业范围内的产品安全事件响应 (PSIRT)中心团队。外部研究人员应当能够轻松访问面向公众的PSIRT信息，以便报告组织机构产品中的漏洞。PSIRT应当和外部研究人员协作，证实并收集关于任何所报告漏洞的信息，并确保所报告漏洞均已修复。组织机构应当负责任地披露所有漏洞。

6、  应当在组织机构的缺陷追踪工具中将所有已知的安全问题和/或漏洞追踪为产品缺陷。所追踪项目应当博阿凯CVSS评分、对组件的特定影响以及任何其它相关支持数据。应当仅在追踪系统的访问受控页面中且基于潜在敏感性存储漏洞信息。

7、  提供充足的人类和计算资源、软件测试和时间，基于组成软件组件或包的多种因素和复杂性，进行测试。这些因素可包括加载、分支、条件竞争等。

8、  审计和或清除或记录所发现的任何弱点。

9、  参见与软件关联的第三方软件和开源组件有关的SBOM（或类似机制）。问题宣布后，建立并遵循关于嵌入式组件升级的企业指南。

10、       修改软件组件时，重复此处提到的单元和系统推荐流程。

威胁场景：SaaS

如下是可被利用的示例场景：

• 以安全为代价，部署和执行SaaS 应用程序

• 组织机构获得增强、改进和优化整体工作流的能力

• 快速采用和购买SaaS 工具和产品（尤其是为了满足快速的疫情后在家办公需求）可能存在一种或多种内在风险，且可能最终影响组织机构的整体安全态势。

缓解建议：SaaS

如下是缓解示例：

1、执行严格的针对SaaS应用安全的安全策略。

2、涉及监控和扫描第三方应用的机制，这些应用与云环境直接连接。

3、开发全面且可靠的备份解决方案。

4、执行身份和访问控制机制。

5、开发成熟的安全评估（可能包括利用云访问安全经纪能力）机制，缩小云服务客户和云服务提供商之间的安全差距。

6、执行行业标准加密算法。

---

代码卫士试用地址：https://codesafe.qianxin.com

开源卫士试用地址：https://oss.qianxin.com

推荐阅读

原文链接：

https://www.cisa.gov/uscert/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF

题图：网络

转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

    觉得不错，就点个 “在看” 或 "赞” 吧~