2022年8月
写在前面：CISA和其他两个部门一起编制了这个系列文档，分布针对开发人员、供应商和客户。本文是系列第一部分，针对开发人员。原文分为三节，只翻译了前两节，附录没有翻译。
本文需要和SSDF对照阅读，关于SSDF，本公众号也做了介绍，请参考采用安全软件开发框架，降低软件漏洞风险。
单纯从内容来看，本文和CIS 软件供应链安全指南各有侧重点，大家可以根据需要互相参照。
目录
网络攻击是通过网络空间实现的，针对企业使用的网络空间，实现中断、摧毁、恶意控制计算环境或基础设施，及破坏数据的完整性或窃取受控信息的目标。
例如最近SolarWinds及其客户遭受的网络攻击，正是利用Log4j等漏洞，突显了软件供应链中的弱点，这个问题涉及到商业和开源软件，影响了私营和政府企业。因此，担心民族国家对手使用类似的战术、技术和程序(TTP)，把软件供应链武器化，对软件供应链安全意识的需求和认识也随之增加。
作为响应，白宫发布了一项关于改善国家网络安全的行政命令(EO 14028)。EO 14028规定了新的要求，保护联邦政府软件安全的供应链。这些要求涉及软件供应商和开发人员，以及为联邦政府购买软件的客户的系统性评审、流程改进和安全标准。
同样地，持久安全框架(Enduring Security Framework，ESF)软件供应链工作小组编制了这个系列指南，作为开发人员、供应商和客户利益相关者实践的纲要，来帮助确保更安全的软件供应链。系列指南被分成三个部分：第1部分针对软件开发人员；第2部分针对软件供应商；第3部分主要针对软件客户。
客户(购买方)可以使用此指南作为软件生命周期相关的描述、评估和度量安全实践的基础。此外，本文所列的建议实践可以应用于软件供应链的购买、部署和运营阶段。
软件供应商(厂商)负责客户和软件开发人员之间的联系。因此，供应商的责任包括通过合同协议确保软件完整性和安全性、软件发布和更新、软件漏洞通知和缓解。本指南包含帮助供应商完成这些任务所推荐的最佳实践和标准。
本文件将根据行业最佳实践和原则提供指导，强烈鼓励软件开发人员参考。这些原则包括安全需求规划，从安全角度设计软件架构，添加安全特性，以及维护软件和底层基础设施的安全性(例如，环境，源代码审查，测试)。
软件供应链中未被缓解的漏洞对组织构成了重大风险。本文为软件供应链的发展、生产和分发、及管理过程提出了可行的建议，以增加这些过程面对入侵的弹性。
所有组织都有责任建立软件供应链安全实践缓解风险，但是组织在软件供应链生命周期中的角色决定了这一责任的形式和范围。
因为保护软件供应链的注意事项根据组织在供应链中发挥作用的角色的不同而不同，本系列针对其中重要的角色，即开发人员、供应商和客户(购买软件产品的阻止)提出建议。
指南分为三部分，将与软件供应链生命周期保持同步。这是本系列的第1部分，主要关注软件开发人员。第二部分主要讨论软件供应商，第三部分针对软件客户。本系列将有助于促进网络安全专业人员和这三个不同角色之间的沟通，可能有助于增加软件供应链过程弹性和安全。
在本系列中，风险、威胁、漏洞利用和漏洞等术语是基于国家安全系统词汇委员会(CNSSI 4009) 所定义的描述。
从历史上看，软件供应链入侵主要针对没有修复常见漏洞的组织。虽然威胁行为者仍然使用这种手法来入侵未打补丁的系统，一种新的、不太明显的入侵方法也威胁到软件供应链和破坏了对能够抵御传统入侵的补丁系统本身的信任。不再等待公开的漏洞披露，威胁行动者主动地将恶意代码注入到产品中，然后通过全球供应链合法地分发到下游。过去的几年里，在开源软件和商业软件中，这种下一代软件供应链入侵都显著增加。
技术消费者通常分开管理软件下载和更广泛、更传统的软件供应链活动。把软件上游和下游两个阶段，作为供应链风险管理组成部分，可能有助于发现问题和集成各项活动以实现系统性安全方面提供更好的前进路径。然而，具体到软件产品，也有一些不同之处。传统的软件供应链周期是从原点到消费点，通常客户能够退回故障产品并限制任何影响。相比之下，如果软件包被注入恶意代码，并向多个消费者扩散；规模也许更难以限制，并可能造成指数级更大的影响。
常见的针对软件供应链的入侵方法包括利用软件设计缺陷，在软件产品中加入易受攻击的第三方组件；在最终软件产品发布之前，使用恶意代码渗透进供应商的网络，并注入恶意软件，然后借助客户去部署。
利益相关方必须设法减轻其负责领域独有的安全顾虑。但是，其他的顾虑可能需要一种缓解方法，要求依赖其他利益相关者、或多个利益相关者共同承担责任。沟通或处理不当的依赖关系可能导致漏洞和潜在的入侵。
-
-
评估和部署之间，对合同、功能或安全假设的未知和/或修订，
-
-
第2节开发人员保护软件开发生命周期(SDLC)可以使用的原则，SDLC是用于保护软件供应管道的重要过程。
附录A：NIST SP800-218【采用安全软件开发框架(SSDF)降低软件漏洞的风险】和本文内容之间的对应。
附录B：依赖关系
附录C：软件制品供应链水平(SLSA)
附录D：推荐制品和检查表
附录E：参考资料
附录F：缩略语
每一节都包含威胁场景示例和建议的缓解措施。威胁场景解释组成软件开发生命周期(SDLC)给定阶段的流程如何与可能被利用的常见漏洞相关。建议缓解措施中的控制和措施能够减少威胁影响。
安全软件开发生命周期(Secure SDLC)是用于保护软件供应链的一个重要流程。单个小组活动内容，客户、开发人员和供应商之间的关系如下图所示：
![保护软件供应链:开发人员实践指南（上）]( "保护软件供应链:开发人员实践指南（上）")
图1：软件供应链各组之间关系和活动
当供应商的项目管理团队收集来自客户的用户、技术团队和营销团队的功能请求时，流程就开始了。这些功能包括对产品的操作和安全增强，生成用例然后制定出优先级需求。供应商和开发人员管理团队共同定义需求，然后开发团队用来生成产品的架构和高层设计。此外，合作的管理团队定义生产产品时所使用的产品开发安全策略和实践。该过程定义了如何组织开发活动以及将收集哪些制品进行验证和验证。以下是安全SDLC过程和实践的常用方法论清单：
-
-
-
-
-
-
新思（Synopsys）“安全软件开发生命周期阶段
-
-
除了生成高水平开发文档之外，管理团队还定义用于安全软件开发的安全实践和过程，例如：
一旦发布，通过支持渠道对产品进行缺陷监控，开发人员可以安全地提供更新和升级，以解决反馈的问题。对于安全SDLC中的每个操作，生成符合所需要过程的制品。这些制品总结在“附录D：制品和检查表”中。
如第2.2节开发安全代码到2.5节交付代码所述，开发人员用例依赖于安全SDLC过程中定义的步骤和策略。开发团队经理和成员调整并定制此过程以满足他们的具体需求。安全SDLC确定了确切过程和策略，用于保证实现安全开发实践，遵守所采用关于产品实施和分发的安全SDLC计划，生成符合要求的制品。
开发团队由开发、质量保证(QA)、构建工程和安全方面的专家组成。产品管理团队由拥有产品领导经验的人员组成，包括产品和开发经理、安全架构师和公司级别的质量控制评估员，所有人都为监督产品发布做出贡献。
组织高层管理团队必须确保安全的开发策略和程序在预算和进度内得到支持，并由指定的开发团队推进。下图概述了安全开发过程和生命周期。
![保护软件供应链:开发人员实践指南（上）]( "保护软件供应链:开发人员实践指南（上）")
图2：安全软件开发过程(国防部首席信息官，2021年)
上面举例说明的过程确保开发出安全、有弹性的产品。它还说明了开发流程可以使用定义良好的、有形的制品来度量，可以利用这些收集、评估和记录的制品来验证产品管理团队总结并记录的指南和安全原则的使用情况。
在开发和交付产品时，在软件开发生命周期中，可能会发生以下常见威胁：
-
对手故意注入恶意代码或开发人员在产品中包含有漏洞代码。
-
在产品中有意或无意地包含易受攻击的第三方源代码或二进制文件。
-
利用构建过程中的弱点，将恶意软件注入到产品的组件。
-
修改产品内部的交付机制，导致恶意注入客户部署的软件原始包、更新包或升级包。
有关每个威胁场景的更多信息，请参见2.2节开发安全代码到第2.5节交付代码。这些部分包含威胁场景的更多细节，针对产品开发和发布过程中可能发生的每种事件或入侵都定义了战略。
供应商和开发人员管理团队应该制定策略，确保开发的组织制定了以安全为重点的原则和指导方针，以便：
-
-
-
-
-
-
-
评估开发人员的能力和对安全开发流程的理解并安排培训，
-
体系架构和设计文档应该基于已经被收集、关联和优先排序的客户和市场需求。与安全有关的具体评估和源自运营客户环境的可靠性标准及已知的产品风险评估应包括在需求中。应该考虑到特定行业的安全标准，如NIAP、FedRAMP、HIPAA或FIPS-140和那些基于零信任原则。架构和设计文档应该解决所有问题定义并描述组件、使用的接口和根据开发团队的需求，在不同的细节层次上实施产品。
开发团队的成员应该经过培训并具有执行安全开发任务的资格，这些都总结在架构和高级设计文档中。
公正的高级安全架构师和开发人员应该创建正在开发中产品的威胁模型。这些人员应该熟悉识别信任边界、关系、以及数据或系统可能受到损害的拐点。应该为所有关键的软件组件、以及构建管道中的重要系统做威胁建模。
参考有关的威胁模型，构建管道中涉及的所有代码和系统都应该持续进行评审。应根据需要进行调整，以确保代码和系统都不存在结构上的漏洞。威胁模型还应包括：
-
对于主要版本，随着功能的变化而更新，或最少每年更新一次，
-
管理策略还应该指定，被分配创建威胁模型的开发人员使用组件级设计实现完整性。模型至少应该被团队中有两名独立的工程师评审和批准，随着架构和设计更改的变化而变化。当组织的策略和过程发生变化时，威胁模型流程也要随之调整。
公正的质量保证(QA)人、团队或具有QA专业知识的公正实体制定并实施安全测试计划。
QA团队由自动化和构建专家组成，利用所需的现代技术，为架构和高级设计文档中定义的组件，实施安全测试战略。
开发人员应该执行由QA验证过的单元级和系统级安全测试。这允许QA执行进一步的安全测试，以更少的重复工作覆盖更广泛、更深入的测试集。测试计划中定义的策略应该包括：
-
代码覆盖，集成到每个构建中，并作为实施测试和开发计划的一部分进行跟踪，
-
理想情况下，代码覆盖率的基线水平应该保证，提交新代码之前，所有代码都执行签入检查，
-
应该定义策略，以最大化代码覆盖率，并完成SSDF在PO.2.1, PW.5.2和PW .8.2中定义的任务，参见美国国家标准与技术研究院NIST SP 800-218，
-
测试覆盖率应该确定测试计划覆盖的代码路径的百分比以及使用的测试工具的类型。
当定义发布准备标准时，它们可能包括以下类型测试的需求：
-
在代码签入之前，应该对所有应用程序执行静态和动态应用程序安全测试(SAST和DAST)，每次发布都使用公司批准的标准工具集。应该记录测试结果，并且应该分析和解决所有发现的漏洞，
-
应对所有第三方软件进行软件成分分析，包括根据MITRE CVE和NIST软件安全漏洞公告( NIST SSDF PW.3.2) 进行审查，
-
在开发过程中应对所有软件组件进行模糊测试，以确保它们在不同的输入下表现出预期的行为。应该记录结果，解决任何异常或漏洞，
-
在可能的情况下，计划使用内存安全的编程语言来减少大量最常见的可利用漏洞，
-
适用于多种类型的软件产品，包括安全软件和通用软件操作系统，根据国家信息保障伙伴关系(NIAP)保护概要(NIAP CCEVS), 许多政府客户可能需要独立的实验室测试，
-
应进行验证，根据软件运行的平台，在开发中使用合适的防攻击功能。这些功能阻止许多种不可预见漏洞被利用。应用软件保护概要v1.4，在FPT AEX Ext1部分，包含了一些防漏洞利用功能，请访问niap-ccevs.org的“NIAP-Approved pps”，
-
根据潜在风险(例如，云产品应该更频繁地进行测试)，渗透测试应尽可能定期进行，但不少于每年一次，
-
不要使用只考虑产品外部可见行为不了解代码的测试方法，也不要使用了解软件的内部工作，就确保修复的漏洞能抵御所有可能入侵的测试方法。
所有安全测试的结果都应该被记录下来，安全缺陷应该被修复，测试结果的概要应提供给客户。这个概要应该包括通用漏洞评分系统(CVSS)评分。QA结果应该被用作产品准备发布的衡量标准。
管理团队应该建立、管理和应用发布标准，并评估是否该产品符合标准。这些标准应包括：
-
在执行所有所需的威胁建模时，没有发现不可接受的安全漏洞，测试用作最后兜底，
-
如第2节开发人员部分所述，保证开发环境的网络安全健康，收集并妥善储存相关制品，以备将来参考，
-
遵循安全软件开发实践和组织设置的任务来进行产品开发，收集相关制品并安全存储以备将来使用。制品的例子是设计和架构文档(例如，系统以及软件组件数据流、UML模型)、威胁模型、验证与测试结果、软件设计的修订历史、所有组件、以及开放问题和已知漏洞列表,
-
生成、关联和验证软件物料清单(SBOM)。SBOM的内容在2.3.5节威胁场景：软件物料清单(SBOM)，及国家电信和信息管理局(NTIA)的软件物料清单(SBOM)的最小要素部分做了描述，
-
产品管理团队确保所有发布的二进制文件都使用来自受信任证书颁发机构的根证书相关联的密钥发出的数字签名，
-
所有发布的软件都符合公司范围的加密标准。这些标准应基于相关行业最佳实践或(对于联邦机构)适用政府标准，如NIST SP 800-175B；使用联邦政府加密标准指南:密码机制，并使用适当定义的负责、问责、咨询和知情(RACI)矩阵进行加强，
-
所有的开源软件提供都符合公司范围的标准，包括对来源的漏洞评估和这些信息将提供给开发小组。提供最新的开源稳定版本，删除已经不再开发的开源软件或提供支持计划，如果有的话，确保软件许可，完全理解并遵循开源使用策略。
管理团队定义产品支持和漏洞处理策略及过程，因为它们处理产品从概念到生命结束(EOL)的整个生命周期。
-
使用漏洞提交系统，所有已知的安全问题和漏洞应在组织的缺陷跟踪工具中作为产品缺陷进行收集和跟踪。这包括通用弱点枚举(CWE)和CVSS评分、组件的具体影响，以及任何其他相关的支持数据。漏洞信息应只存储在缺陷跟踪系统设置访问控制的页面中，具有潜在的敏感性,
-
组织应该在全公司范围内设立一个集中的产品安全事件响应小组(PSIRT)，支持面向公众的报告工具(例如web页面)，这使得外部研究人员可以很容易地报告组织产品的漏洞。PSIRT团队应该与外部研究人员合作确认和收集任何报告的漏洞信息，并确保任何报告的漏洞已修复。组织应该对所有漏洞实行负责任的信息披露,
-
所有现场软件的更新，包括补丁和产品更新使用HTTPS/TLS等安全协议交付。现场软件产品应该对所有交付的文件进行完整性或签名检查，以确保文件是有效的。这适用于向本地和云端软件产品提供更新。
管理团队定义用于评估开发人员能力和对安全开发过程的理解。这些政策应涉及：
理想情况下，开发团队的安全培训应该由一个统一、专家的安全团队进行，可以帮助产品团队提高他们在安全开发方面的专业知识。当工程师有特定的安全问题时，他们会成为联络点。
开发人员应该定期接受相关的安全培训，包括公开课和个人特别需要的内容。所有工程师都应该跟踪完成情况。组织应确保个人完成与其从事工作相称的安全培训。
开发团队内的工程师也应该被要求接受组织批准的年度网络安全最佳实践培训。这种培训的例子包括如何发现可疑电子邮件和报告可疑入侵的联络人。这个培训课程结束时应包括测试，以确保对材料的理解。参见NISTSP 800-50，“建立信息技术安全意识和培训计划”，发现关于应该如何进行和衡量培训的更多信息。
开发团队中的个人应该定期进行评估，至少每年进行一次。根据产品安全目标衡量他们的知识和合规性。至少，这是应该做的有代表性的调查，展示一个团队或个人对所要求的公司培训的意识，以及证明符合政策的任何制品。应检查差距确定并解决根本原因，例如，是否缺乏可用的工具来实现组织安全的期望。
管理团队记录安全程序和过程。这些文件应该进行审查、更新，每次软件发布尽可能地公开。这必须在不泄露有关产品的敏感安全信息的情况下进行。这些都是活生生的文档，当在开发过程中出现问题时、产品发布后在正式的“结项”报告、参与安全开发过程的所有成员一起召开的“经验分享”会议时，审查这些文档。
本节提供的缓解措施与NIST SP 800-218“安全软件开发框架(SSDF)版本1.1：降低软件漏洞风险”中的活动保持一致。下表列出了与SSDF建议一致的实体开发活动：
|
缓解
|
|
SSDF V.1 活动
|
|
架构和设计文档
|
|
PO.1.1,PO.4.1,PO.4.2,PW.4.3, PW.3.1
|
|
开发团队培训安全开发
|
|
PO.2.2,PW.1.1,PS.1.1,PS.3.1,PW.4.2,PW.4.3,PW.5.1,PW.5.2, PW.6.1,PW.6.2,PW.7.1, PW.7.2
|
|
威胁建模
|
|
PW.1.1
|
|
安全测试计划
|
|
PO.3.1, PO.3.2, PO.3.3, PO.4.1, PO.4.2,PW.4.3, PW.5.1,PW.5.2, PW.6.1,PW.6.2,PW.7.1, PW.7.2, PW.7.2,PW.8.1,PW.8.2, PW.9.1, PW.9.2, RV.1.1, RV.1.2, RV.3.3, RV.3.4
|
|
记录CVSS打分结果，验证安全缺陷并修复
|
RV.3.2, RV.3.4, PS.2.1, PS.2.2
|
|
产品发布
|
交付测试和威胁建模文档，漏洞报告和SBOM
|
PS.2.1, PS.2.2, PW.2.1, RV.1.2
|
|
报告缺陷的支持渠道
|
RV.1.1
|
|
发布数字签名的二进制，可信根证书
|
PS.2.1
|
|
产品支持
|
跟踪已知问题/漏洞
|
RV.1.1, RV.1.2, RV.1.3
|
|
事件响应的公开报告工具，修复报告问题和暴露
|
RV.1.3, RV.2.1, RV.2.2, RV3.1, RV.3.3
|
|
更新场内产品
|
PS.3.2
|
|
评估和培训开发人员
|
|
RV.3.4
|
|
每次发布的安全流程和步骤
|
|
RV.2.2
|
|
加密和第三方软件集成标准
|
|
PW.3.2, PW.4.1
|
说明：SSDF活动代码：PO-准备组织；PW-生产安全可靠软件；PS-保护软件；RV-漏洞响应
（完）
原文始发于微信公众号（安全行者老霍）：保护软件供应链:开发人员实践指南（上）
图1：软件供应链各组之间关系和活动
评论