前情回顾
美政府发布《面向开发者的软件供应链安全指引》，为关基设施提供安全指导
近日，美国国家安全局（NSA），NSA、网络安全和基础设施安全局 （CISA） 和国家情报总监办公室 （ODNI）联合发布《供应商软件供应链指南》，以解决国家关键基础设施面临的威胁。NSA认为网络攻击的目标是企业利用网络空间来侵入、禁用、或恶意控制计算环境或基础设施，破坏数据的完整性或窃取受控信息。NSA在通告中指出：软件供应链周期容易受到攻击，并面临潜在损害的风险。软件供应商可以在本次指南中获得指导，通过软件安全检查、保护软件、生产安全良好的软件等措施保护组织免遭损失。NSA在通告中指出，该指南是对SolarWinds攻击事件调查结果的反馈。据悉，NSA、CISA、ODNI联合组建的持久安全框架工作组（ESF）对该事件的调查结果表明，需要创建一套行业和政府评估的方法，重点关注软件供应商的需求。
软件供应链中未得到缓解的漏洞给企业带来了巨大的风险。本系列文章对软件供应链的开发、生产和分销以及管理流程提出了可操作的建议，以提高这些流程的抗风险能力。所有组织都有责任建立软件供应链安全实践，以降低风险，但组织在软件供应链生命周期中的角色决定了这种责任的形式和范围。
供应商
供应商作为开发商和客户之间的联络人或中间人，因此，对以下方面负有主要责任。
1.保持安全交付的软件的完整性；
2.验证软件包和更新；
3.保持对已知漏洞的认识；
4.接受客户对问题或新发现的漏洞的报告，并通知开发人员进行补救；
安全的软件开发和交付系统的目标是帮助保护软件代码、出处和完整性，从而为软件供应链的破坏创造弹性或完全防止其破坏。本节描述的威胁情景与NISTSP800-218一致；通过采用安全软件开发框架（SSDF）来减轻软件漏洞的风险。本节情景的目的是为开发人员、供应商和客户之间应该存在的沟通机制提供高级指导。
01 准备
1.1 确定软件安全检查的标准
应建立并实施政策，规定安全交付软件所需的检查。这些政策应该是每个在软件开发生命周期（SDLC）中发挥作用的人都可以访问和了解的，并且应该包括通知客户漏洞、用于缓解的机制以及寿命终止（EOL）支持。
威胁场景：企业内部
以下是可能产生可利用漏洞的示例场景。
1.政策不存在或没有明确定义。
2.团队不知道或没有在整个SDLC中实施政策要求。
3.政策要求不具有包容性，或者没有在产品的生命周期结束时提供客户支持。
建议措施
以下缓解措施可以帮助减少与部署过程相关的威胁和风险
1.验证运送的软件与收到的软件是一样的；
2.创建完全签名的图像和二进制代码；
3.确保一个安全的哈希值来验证二进制；
4.确保通信渠道是安全的；
5.建立和实施安全的更新/补丁程序；
6.验证可执行文件的修订级别；
a)应实施版本控制；
b)更改应该有时间戳；
c)应实施版本控制系统（VCS），以便在需要时进行恢复；
7.通过利用国际公认的标准（如NISTSSDF）来验证组织检查，这有助于确保在软件发布前和整个软件生命周期内满足软件功能和安全要求；
02 保护软件
2.1 保护所有形式的代码免受未经授权的访问
所有形式的代码都应受到保护，以防止未经授权的访问和篡改，并且在整个SDLC中都应采用最小特权原则。这是确保交付给客户的代码包括所有需要的安全功能，以及这些功能按设计运行的关键。这包括代码中没有额外的、可能会降低安全性的功能，如后门或硬编码的密码。
威胁场景：企业内部
以下情况对软件代码的完整性构成威胁：
未授权访问并能清楚地查看未加密、未混淆的设计或源代码的人。
未经授权修改或删除用于构建和交付过程的代码或包。
在交付给客户之前，未经授权修改或删除文件、代码或软件包。
存在后门或硬编码的密码，以便将来能够进行未经授权的访问；
建议措施
执行基于角色的访问控制(RBAC)，进行职责划分和最小权限；
识别和审查受信任的架构师、开发人员、测试人员和具有完成项目所需技能的文档人员；
根据个人的能力和兴趣，将其分配到一个或多个设计、编码和质量保证（QA）任务，并在安全访问控制系统中为其相应的项目角色注册权限；
验证每个被分配的个人的公司发行的开发系统是否符合所有公司的安全标准，包括全盘加密、最低密码复杂性、补丁管理；防病毒和入侵检测系统、基于Al的端点保护平台和端点检测和响应、数据丢失预防（DLP）等；
确保代码库、构建和测试环境至少具有与其他关键网络功能相同的安全保护措施，如网络分割、防火墙、监控、自动加密和远程备；。
确保只有企业发放的或批准的开发系统才能使用多因素认证（MFA）或基于行为分析的连续认证来访问开发、构建和测试环境，并且只能通过具有物理安全性的办公网络或通过安全的虚拟专用网络（VPN）。确保检测、报告和调查失败的访问尝试。这对移动或远程工作的员工尤为重要；
对第三方软件进行审查，并保证这些包含的模块的安全性；
使用保护敏感签名密钥的代码签名系统交付数字签名的代码和相关支持文件，并使用硬件保护，如联邦信息处理标准（FIPS）140-2/-3硬件安全模块（HSM）。这要求至少有两个人激活签名密钥并批准软件发布包（即代码、支持文件和元数据）；
在开发和运营支持团队中建立一种强大的安全文化；
审查人员、任务、系统和政策，以确保它们继续保持适当、必要和完整。按计划和在事件触发时进行审查；
威胁场景：SaaS
可能被利用的云原生软件开发场景示例：
承诺更快上市、更好的可扩展性和管理以及更低的成本的软件开发过程，同时保持相同的开发安全和完整性水平；
采用新方法，改变企业内部的开发和发布流程以及安全和安全管理制度；
包括采用容器化和微服务架构的关键变化；
建议措施
以下缓解措施可以帮助减少与开发过程相关的威胁和风险：
使用强认证、授权、代码扫描、漏洞分析和应用程序的数字签名。
应根据需要扩大这些做法，以解决与端点和操作云安全相关的任何其他认证挑战。
2.2 验证软件发布完整性的机制
供应商应提供一种机制，通过在整个软件生命周期内对代码进行数字签名来验证软件发布的完整性。
威胁场景：企业内部
缺乏可验证的来源和完整性会发生以下情况：
能够进入软件支持活动的可以用恶意软件代替合法组件；
能够进入软件支持活动的攻击者可以将恶意代码插入到合法组件中；
恶意代码的插入可能发生在交付前的供应商一方，或使用前的接受者一方；
建议措施
以下的缓解措施可以帮助减少威胁和与威胁相关的风险：
1.对代码进行数字签名，以便接收者能够验证和信任代码的来源和完整性。
由于代码签名只在代码签署后提供保护，为了减少签署前的代码篡改和恶意代码注入风险，建议企业考虑实施可验证构建过程，作为签署代码前的检查点；
b)可验证的构建系统应该由生产构建环境的一个逻辑隔离的二级镜像组成，该镜像与生产构建环境的编译和打包程序同时进行，独立编译和打包代码；
c)两个并行操作的哈希结果可以进行比较，如果验证为匹配，则可以对生产构建工件进行签名；
d)最终修订的二进制代码应使用由受信任的证书机构颁发的代码签名证书进行签名，并提供一个机制来验证这些签名；
2.建立并实施密钥管理程序
用于代码签名操作的私钥应安全地存储在HSM上，以降低代码签名密钥被盗的风险。
b）访问存储在HSM或代码签署基础设施上的密钥材料和程序的系统应受到适当的基础设施安全控制的保护。
c)应通过适当的基础设施安全控制措施来保护代码签署业务，以减少代码签署密钥误用和滥用的风险。
3.安全检查清单中囊括签名验证，并确保其得到适当的执行。
a)在官方安全配置指南或同等文件中记录签名验证机制或过程。
b)如果在允许第三方供应商的架构中没有第三方供应商的签名验证机制，则应开发并提供一种定制的程序化方法。
c)第三方软件的供应商应建立检查机制，以验证软件包的真实性和完整性。
d)签名验证机制应包括证书撤销列表检查和信任链验证。
e)在签名中，包含时间戳。
2.3 归档和保护各软件版本
组织应制定归档策略，允许组织指定主次版本。
威胁场景：企业内部
缺少或未充分建立企业范围内的政策，会增加出现以下威胁情况的可能性：
使用不适当的存储介质类型，这些介质不安全，不容易访问或可用；
不经常审查档案或不符合组织的保留政策的审查；
建议措施
通过将已发布的软件转移到归档状态，这通常是一个成本较低的存储区域，组织可以节省资金，并为更关键的软件项目分配快速的存储。这个过程也可以通过减少员工打开正在开发的文件和访问相关元数据的时间来加快生产力。以下的缓解措施可以帮助减少相关的风险和威胁。
1.建立具有适当访问控制的档案库；
2.确保代码和编译后的可执行文件存储在永久档案中；
3.档案库应具有有限访问权限，并以只读模式存储，在只读模式下创建档案，以保持其完整性。
4.用于存储档案的媒体由组织决定，决定通常取决于其方便性、可靠性和可用性；
5.归档数据的过程通常是使用软件自动完成的。归档软件所提供的特点和功能取决于供应商，但大多数在每个平台上都有标准功能；
系统管理员配置要归档的软件的时间、地点和频率。创建一个归档策略来确定移动数据背后的规则；
与其他归档规则相结合，保留策略。保留策略决定了在数据被覆盖或销毁之前，存档的可用时间。典型的备份保留政策是30天，但归档数据在被销毁前可能会保留更长时间。归档和合规标准可能有保留政策的要求，所以组织应确保配置不违反监管标准；
03 生产高安全性软件
3.1 设计软件以满足安全要求
为了实现这一目标，安全要求必须是准确和完整的，代码必须满足这些要求，并应解决任何可利用的漏洞。
威胁场景：企业内部
示例场景：
开发人员在整个SDLC中没有采用安全开发实践；
开发人员或相关安全团队在进行威胁或风险评估方面的培训不足；
设计或操作要求没有被充分理解或实施；
建议缓解措施
以下的缓解措施可以帮助减少与该过程相关的威胁和风险：
展示安全开发生命周期实践和流程，包括定义预期环境的设计规范；
执行威胁建模以实现安全目标；
获得尽可能多的关于软件来源和操作环境的信息；
使用熟练的软件架构师和安全专业人员进行威胁和风险评估，以了解不同的部署场景、事件和操作错误如何影响软件满足其要求的能力；
记录设计和操作假设，以便更容易评估需求和其他变化对安全的影响。在整个开发周期中重新审视设计假设和决定；
威胁场景：SaaS
软件开发人员利用持续交付或持续部署方法，为其SaaS产品整合安全。以下是可能被利用的示例场景：
攻击者或不知情的员工可能会将有漏洞的代码引入资源库，从而触发自动构建和部署；
触发自动构建和部署编译的代码；
SaaS产品的客户可能容易被已经驻留在其系统上的脆弱代码所利用；
单个SaaS解决方案中不同模块之间的安全要求差异，可能导致所有组件的验证不足。
攻击者或恶意内部人员可能会破坏由第三方供应商提供的未经供应商或第三方供应商验证的模块。
建议措施：SaaS
示例：
在SaaS供应商和所有相关的分包商和第三方供应商之间建立、执行和验证共同的安全要求；
定义用于执行软件产品安全评估的通用工具，负责代码开发的所有各方都必须使用这些工具；
在最低权限的执行环境中执行任何未从安全角度完全审查的代码，直到该代码能够被完全评估；
3.2 验证第三方供应商的软件是否符合安全要求
供应商必须确保本地开发的软件和由第三方供应商获得的组件都符合安全要求。
威胁场景：企业内部
以下是可能被利用的示例场景。
供应商、第三方供应商和客户之间的合同协议可能会 "连带"；第三方软件是额外漏洞的潜在来源；
供应商在做出使用第三方提供的软件组件的风险决策时，排除了某些常见的因素；
在软件工程质量、最小加密密钥长度、确定批准的加密算法、确定批准的库或编译器选项方面未能成功地表达安全要求；
建议措施
1．验证第三方软件是否符合安全要求；这可以减少与使用获得的软件模块和服务有关的风险；
2.评估第三方提供的软件是否符合适用的安全要求；
定义安全要求；
如果适用，通过合同协议向第三方供应商传达安全要求。合同协议还应包括漏洞披露/缓解要求，或事件报告；
定义表明符合安全要求的测试；
定义一个重新评估安全要求和测试的过程；
确定受修改或额外安全要求和测试影响的第三方软件；
定义一个满足适用安全要求的第三方软件的缓解过程；
3.确保合同协议解决潜在的第三方软件问题；
如果可能的话，应签订合同协议。该协议应详细说明安全要求，并要求诸如及时披露漏洞和SDLC实践；
只有在第三方软件符合安全要求[NIST SSDF P0.2]的情况下，才可提供其副本，并应说明符合的具体安全要求。副本只能从组织维护的只读位置获得；
4.审查第三方软件，将其作为额外漏洞的潜在来源；
维护一个只读的位置，上面有经批准的第三方软件，并标明符合 [NIST SSDF PS.1] 的安全要求；
拒绝使用不是从只读位置获得的第三方软件；
在已批准的第三方软件的安全要求符合所开发软件的安全要求时才允许使用；
建立并在必要时更新企业政策，强制使用最合适或最新版本的第三方软件；
3.3 配置编译和构建过程
构建过程是"完全"还是"增量"，决定了它是使用"从未见过"还是"最后一次构建状态"来执行。全面构建检查依赖关系，编译所有的源文件，按顺序构建所有的部分，并将其组装成一个构建工件。在增量构建的实例中，构建会检查和比较源文件和其他依赖目标的文件，以确定自上次构建以来的修改情况。如果有修改存在，目标将被重新构建。否则，上次构建的文件将被重新使用。
威胁场景：企业内部和SaaS
示例场景：
能够接触到生产构建环境中的软件流程和工具的攻击者可能会在组件中插入恶意软件；
不适当地配置编译和构建过程可能会损害可执行文件的安全性；
不适当地保护生产构建过程和它所产生的二进制工件的完整性；
建议措施
用于编译和构建软件组件的过程必须被正确配置为默认安全，以确保所有二进制生产代码工件的完整性。应实施以下控制措施来强化软件编译和构建过程。
组织应该为参与软件编译和构建的所有工具建立和维护一个可信的工具链；这些工具应该被配置为已知的安全基线状态，通过维护在配置管理数据库中的清单进行记录和跟踪，持续监测新出现的安全漏洞，并按照规定的修复时间线，接受适当的安全更新；
所有的构建过程应该是自动化的，所产生的脚本和元数据应该安全地存储在一个版本控制系统中，访问权限仅限于负责构建组件的个人；
应使用非交互式服务账户来调用自动构建流程，以确保构建输出是由服务生成的，且不可伪造；
执行自动编译和打包流程的服务账户的认证凭证应使用经批准的方法进行验证，以验证该流程是可信的；
自动构建过程应在逻辑上隔离且不受外部影响的短暂环境中执行。
自动构建过程应该生成并维护一个构建清单，识别构建者、源、入口点和参数，以确保构建的可重复性
应启用安全编译器设置，以帮助防止或限制某些类型的安全问题的有效性，最明显的是缓冲区溢出。
组织应该考虑实施可验证的构建过程，包括一个逻辑上隔离的生产构建环境的二级镜像，它与生产构建环境同时独立编译和构建软件组件。然后可以比较这两个平行操作的哈希结果，以验证构建过程的完整性。
3.4 审查或分析可读代码
软件应该包括操作和安全功能，在进行信息安全评估时，应该考虑这两方面。这对采购、管理和部署过程尤其重要。组织利用具有强大安全功能的软件包，可以减少信息安全风险暴露，并减少进一步问题的可能性。在计算总拥有成本、风险缓解和控制、运营成本以及计算整体商业价值时，软件技术的基础软件质量和安全性应该是一个考虑因素。
威胁场景：企业内部
可被利用的示例情景：
无法方便地审查或分析代码，以帮助识别漏洞和验证合规性；
安全功能不充分或不适当，无法满足采购、管理或部署要求；
管理或部署要求的安全功能不足或不适当。建议的缓解措施；
示例：
1.建立一个安全保证计划，要求如下：
已经进行了安全风险评估；
已为正在开发和/或维护的软件和数据制定了安全要求；
已为开发和维护过程制定了安全要求；
每个软件审查和审计包括对安全要求的评估了；
配置管理和纠正措施过程为现有软件提供安全保障，变更评估过程防止违反安全要求；
软件和数据的物理安全是充分的；
安全保证包括SDLC和CI/CD的需求、设计、实施、测试、发布和维护阶段的活动）代码覆盖率，衡量单元测试覆盖率；
2.审查和/或分析人类可读的代码，以确保其符合既定的安全保障计划，识别漏洞并验证是否符合既定要求。
a)产品定义和市场要求文件；
b)产品章程、愿景和范围文件；
c)需求和用户故事；
d)设计文件；
e)产品规格；
f)验证计划；
g)测试和验证计划和测试案例；
3.5 测试可执行代码
供应商必须设法提供允许客户访问其授权的信息和资源的软件，同时防止客户访问其未授权的信息。为了实现这一目标，供应商和开发人员应协同工作，帮助确保所有已知的漏洞得到缓解。
威胁场景：企业内部
可能被利用的示例场景：
放弃实施或使用特权概念；
缺少或不充分地测试和扫描漏洞；
对安全要求的误解、缺乏或不适当的实施；
建议措施
缓解示例：
获得一套清晰和完整的安全要求，并让安全主题专家小组审查和验证；
了解对美国政府销售的管理和合规性要求；
应为所有关键软件组件以及构建管道中的所有系统开发威胁模型；
每个威胁模型都应该由团队中至少两个独立的工程师来审查和批准；
所有的代码和系统都应根据相关的威胁模型进行持续审查，并根据需要进行修改，以确保代码和系统不存在结构性漏洞；
威胁模型应在重大发布时或至少每年更新；
威胁模型应提供给其他内部团队；
4.制定测试计划，以覆盖每个需求；
5.根据员工的经验和资格为安全测试团队配备人员；
6.提供充足测试资源和时间来执行测试计划；
7.安全测试应该是每个软件组件的质量保证计划的一部分，应该包括以下内容（见NISTSSDF）：
发布前，使用标准的公司认可的工具对所有代码进行静态（提示）和动态源代码分析。测试结果应被记录下来，所有发现的漏洞都应被分析和缓解；
对所有的软件组件进行模糊测试，以确保所有的输入上表现出预期的行为。
根据潜在的风险，渗透测试应该每6-24个月进行一次；
所有安全测试的结果都应该被记录下来，包括任何常见的漏洞评分系统（CVSS）的分数，安全缺陷应得到缓解和验证；
8.如有必要，在做出改变后，重复步骤1-7；
9.验证并记录安全要求是否满足；
3.6 将软件配置为默认的安全设置
客户有时急于快速安装软件，并可能偶尔在未完成适当配置或未完全理解配置选项的情况下在运行环境中使用软件。为了防止这些行为导致破坏，软件在安装时应要求最低限度的访问，允许客户在需要时明确启用额外的访问。
威胁情景
可能被利用的示例场景：
在完成或正确配置之前就安装和使用软件；
软件安装时默认允许完全操作访问；
没有限制对管理程序的访问和/或执行的软件；
管理和一般用户的操作都没有被记录下来；
建议措施
缓解威胁示例：
1.要求所有管理/配置的改变通过本地或强加密的远程连接进行；
2.默认情况下，在本地记录所有管理操作，并将日志至少保留30天；
3.只提供一个默认管理账户，不提供任何默认用户账户或访问；
4.要求客户在首次登录后立即更改默认的管理认证凭证；如果可能，建议建立MFA；
5.要求所有管理账户凭证足够复杂（密码）或具有足够的加密强度（证书）。如果可能，任何账户的访问尝试都应涉及MFA，通过具有物理安全和/或安全VPN的办公网络，和/或基于行为分析的连续认证（见NISTSP 800-207）；
6.禁用那些不需要认证的服务和功能，直到明确启用；
7.密码恢复程序必须要求控制台或物理访问。密码重置程序应该恢复到初始状态。
04 应对措施
4.1 持续识别、分析和修复漏洞
供应商应尽力确保提供给客户的任何软件中没有公开的或容易识别的漏洞。此外，采购软件的客户非常希望获得有关所购软件的来源和安全性的透明信息。以下的控制措施旨在使组织的安全软件开发过程透明化。如果不执行这些步骤并保持遵守的证据，可能会降低对软件质量足以在客户的网络中运行的信心。
威胁场景：企业内部
可能被利用的示例场景：
软件包含已知和/或未披露的漏洞；
测试或消除已知漏洞的尝试是不完整或不充分的；
软件或组件的来源不明；
建议措施
缓解威胁示例：
1.建立由架构师、开发人员、测试人员、密码学家等人员组成的漏洞评估小组，其目标是识别软件中得可利用缺陷。
2.对于软件能力，定义一个流程，使用已知环境分析，监测与软件能力相关的漏洞，并对组合系统中的各个单元进行未知环境的模糊测试；
3.对于软件组件，定义一个流程，使用已知的环境分析，使用源码或二进制组成分析工具来监测与确定的软件组件相关的漏洞，并对组合系统中的各个单元进行未知环境模糊测试；
4.投资最先进的静态和动态评估工具；
5.建立全公司范围内的产品安全事件响应（PSIRT）的中央团队。面向公众的PSIRT信息应便于外部研究人员报告组织产品的漏洞；
6.所有已知的安全问题和/或漏洞都应在组织的缺陷跟踪工具中作为产品缺陷进行跟踪。跟踪的项目应包括CVSS评分、对组件的具体影响以及任何其他相关的支持数据；
7.根据可能构成软件组件或软件包的多种因素和复杂性，提供足够的人力和资源、软件测试以及测试时间。因素可能包括负载、分支、竞赛条件等；
8.审查并消除或记录发现的漏洞；
9.参考与第三方软件和与软件相关的开放源码组件相关的SBOM（或类似机制）。在问题公布后，建立并遵循企业对嵌入式组件升级的指导；
10.当软件组件被修改时，对该单元和系统重复建议过程；
威胁场景：SaaS
可能被利用的示例场景：
以牺牲安全为代价的SaaS应用的部署和实施；
被提供给增强、改善和优化其整体工作流程的组织；
快速采用和获取SaaS工具和产品可能有内在的风险，并可能最终影响组织的整体安全态势。
声明：本文来自天极智库，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
