您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。[未知机构]:软件供应链安全之开发者最佳实践指南(英) - 发现报告
当前位置:首页/行业研究/报告详情/

软件供应链安全之开发者最佳实践指南(英)

信息技术2022-09-17-未知机构笑***
软件供应链安全之开发者最佳实践指南(英)

持久的安全框架 2022年8月 执行概要 网络攻击是通过网络空间进行的,目标是企业对网络空间的使用,以达到以下目的扰乱、禁用、破坏或恶意控制计算机环境或的目的 基础设施;或破坏数据的完整性或窃取受控信息。1 最近的网络攻击,如那些针对SolarWinds及其客户的网络攻击,以及利用利用Log4j等漏洞,突出软件供应中的弱点。 这个问题跨越了商业和开放源码软件,并影响到私营企业的发展。和政府企业。相应地,对软件供应链的需求也在增加。 安全意识,并认识到软件供应链的潜在风险。 民族国家的对手使用类似的战术、技术和程序(TTPs)将其武器化。 作为回应,白宫发布了一项关于改善国家网络安全的行政命令。 (EO14028)。第14028号行政命令规定了新的要求,以确保联邦政府的软件安全供应链。这些要求涉及系统审查、流程改进和安全 除了为获得软件供应商和开发商的客户提供标准外,还为他们提供了一个新的标准。软件为联邦政府。 同样地,持久的安全框架2(养)软件供应链工作小组制定本指南的目的是作为开发商的建议做法的汇编。这将有助于确保一个更安全的软件供应链。这 指南分为三个系列。该系列的第一部分侧重于软件开发人员。第二部分重点介绍软件供应商;第三部分重点介绍软件客户。 客户(收购组织)可将本指南作为描述、评估和使用的基础。衡量與軟體生命週期相關的安全實務。此外,建议的实践 本文所列举的内容可以应用于整个采购、部署和运营阶段。软件供应链。 软件供应商(厂商)负责在客户和软件之间进行联络。 开发商。因此,供应商的责任包括确保以下内容的完整性和安全性 通过合同协议、软件发布和更新、通知和缓解措施等方式对软件进行管理。漏洞的问题。本指南包含推荐的最佳实践和标准,以帮助 供应商在这些任务。 本文件将提供符合行业最佳实践和原则的指导,这些原则包括我们强烈鼓励软件开发人员参考这些原则。这些原则包括安全需求规划,从安全角度设计软件架构,增加 安全功能,并维护软件和底层基础设施的安全(如:。环境中,源代码审查、测试)。 1国家安全委员会系统(CNSS) 2ESF是一个跨行业的工作组,在关键基础设施伙伴关系的主持下运作。 咨询委员会(CIPAC),以解决对美国国家安全系统的安全和稳定的威胁和风险。它由来自美国政府的专家以及信息技术部门的代表组成。 通信和国防工业基地部门。ESF负责将 来自私营和公共部门的代表,在情报驱动下,共同应对网络安全挑战。 免责声明 免责声明的支持 本文件的编写仅用于一般信息目的。它旨在适用于一个各种事实情况和行业利益相关者,这里提供的信息是 属于咨询性质。本文件中的指导意见是"按现状"提供的。一旦公布,其中的信息可能不构成最新的指导或技术信息。 因此,本文件不构成,也不打算构成合规或法律建议。读者应与他们各自的顾问和主题专家协商,以获得建议。 根据他们的个人情况。在任何情况下,美国政府都不承担任何责任。对于因使用或依赖本指南而引起的任何损害,我们不承担任何责任。 在此提及任何具体的商业产品、工艺或服务的商品名称、商标。厂家或其他方面,并不构成或暗示其认可、推荐或 美国政府的青睐,本指导意见不得用于广告或其他用途。产品代言的目的。所有商标都是其各自所有者的财产。 目的 国家安全局、ODNI和CISA为促进各自的网络安全,制定了本文件。职责,包括制定和发布网络安全建议和方案。 缓解措施。这种信息可以广泛分享,以达到所有适当的利益相关者。联系 客户需求/查询:持久的安全框架nsaesf@cyber.nsa.gov媒体调查/按桌子: 国家安全局媒体关系部,443-634-0721,MediaRelations@nsa.gov。 CISA媒体关系部,703-235-2010,CISAMedia@cisa.dhs.gov。 dni-media@dni.govODNI媒体关系 表的内容 执行Summary.2 1介绍1 1.1Background1 1.2文档overview2 2开发者3 2.1安全产品标准和管理4 2.2开发安全代码11 修改或剥削的源代码通过内部人士12 开放源管理实践19 安全发展Practices20 代码集成22 缺陷或漏洞客户报道问题22 外部发展扩展23 2.3验证第三方组件24 第三方二进制文件24 选择和集成25 获得组件从一个已知的和受信任的供应商25 组件维护26 软件比尔的材料(SBOM)26 2.4变硬的构建环境27 构建链利用28 利用签署服务器33 2.5交付代码34 最后包验证34 潜在的战术来妥协的软件包和更新35 妥协的的分布系统35 3附录37 3.1附录答:人行横道之间的场景和SSDF37 3.2附录B:依赖性39 3.3附录C:供应链水平为软件工件(SLSA)40 3.4附录D:工件和检查表42 3.5附录艾凡:信息丰富的参考文献55 3.6附录F:首字母缩略词使用在这文档59 1介绍 软件供应链中未得到缓解的漏洞给企业带来了巨大的风险。本文为软件供应链的发展提出了可操作的建议。 在生产和分配以及管理过程中,以提高这些机构的弹性。流程与妥协。 所有组织都有责任建立软件供应链安全实践,以 缓解风险,但组织在软件供应链生命周期中的角色决定了它的价值。形状和这一责任的范围。 因为确保软件供应链安全的考虑因素根据不同的角色而有所不同。 本丛书提出了针对这些问题的建议,以帮助组织在供应链中发挥作用。重要的角色,即开发者、供应商和客户(或获取一个组织)。 软件产品)。 该指南分为三部分,并将在软件发布的同时发布。 供应链生命周期。这是该系列的第一部分,主要针对软件开发人员。第2部分的该系列的第三部分侧重于软件供应商,而该系列的第三部分则着重于软件。 客户。这个系列将有助于促进这三个不同角色之间的沟通和网络安全专业人员之间的合作,可能会促进增加弹性和安全。软件供应链过程。 在这个系列中,诸如风险、威胁、利用和脆弱性等术语是基于定义的描述在国家安全系统委员会词汇表(CNSSI4009)中。3 1.1背景 从历史上看,软件供应链的破坏主要针对常见的漏洞。 威胁者仍在使用这种策略来破坏那些没有打补丁的组织。虽然威胁者仍然使用这种战术来破坏在未打补丁的系统中,一种新的、不那么明显的破坏方法也威胁着软件供应。 链条,并破坏了对修补系统本身的信任,而修补系统对保护人们的安全至关重要。对付遗留的损害。威胁者不是在等待公开的漏洞披露,而是 主动向产品中注入恶意代码,然后在下游合法地分发。 通过全球供应链。在过去的几年里,这些新一代的软件供应开源软件和商业软件的链式纰漏都大大增加了 产品。 技术消费者通常管理软件下载和更广泛、更传统的 软件供应链的活动是分开的。同时考虑到上游和下游的阶段 软件作为供应链风险管理的一个组成部分,可能有助于发现问题和解决困难。在整合活动以实现系统安全方面,提供了一个更好的前进方式。 然而,就软件产品而言,也有一些差异需要说明。A 传统的软件供应链周期是从原产地到消费地,一般来说 使客户能够退回故障产品并限制任何影响。相反,如果一个 3cnssi-4009.-pdf 软件包被注入了恶意代码,并扩散到多个消费者手中。规模可能更难限制,并可能造成成倍的影响。 针对软件供应链的常见破坏方法包括利用 软件设计缺陷,将易受攻击的第三方组件纳入软件产品。 在最终的软件产品上市之前,用恶意代码渗透到供应商的网络中。输送,并注入恶意软件,然后由客户部署。 利益相关者必须设法减轻其责任范围内的具体安全问题。 然而,其他问题可能需要一个缓解方法,决定了对另一个人的依赖性。利益相关者或多个利益相关者的共同责任。依赖性是指 沟通不足或处理不当可能导致漏洞和潜在的妥协。 可能存在这些类型的漏洞的领域包括。 无证功能或有风险的功能, 之间的合同、功能或安全假设的未知和/或修订。评估和部署, 供应商的所有权和/或地理位置的改变,以及 供应商企业或发育不良的卫生习惯。 1.2文档概述 本文件包含以下补充章节和附录。 第二节推荐原则开发人员可以用来帮助确保软件开发的安全。寿命周期(SDLC),一个用于保护软件供应管道的重要过程。 第三节是补充前面章节的附录集。 附录A间:人行横道NISTsp800-218;减少软件的风险 通过采用安全的软件开发框架来消除漏洞(SSDF)4和用例在此描述。 附录B:依赖关系 附录C:软件工件的供应链水平(SLSA)。5附录D:建议的工件和清单 每一节都包含威胁情况的例子和建议的缓解措施.威胁的场景解释构成软件开发生命周期(SDLC)某一阶段的过程。 与可能被利用的常见漏洞有关。建议的缓解措施提出可以减少威胁影响的控制和缓解措施。 附录E:信息的引用附录F:首字母缩略词 4NISTSP800-218草案,安全软件开发框架(SSDF)1.1版。建议 减轻软件漏洞的风险 5GitHub-slsa-framework/slsa:软件工件的供应链级别 2开发人员 安全软件开发生命周期(SecureSDLC)是一个重要的过程,用于确保软件供应链。个人小组活动和关系的例子 客户、开发商和供应商之间的关系如下图所示。 图1:软件供应链集团的关系和活动 这个过程始于供应商的项目管理团队从以下方面收集功能请求他们客户的用户群、技术基础和营销团队。这些功能包括 对产品进行操作和安全方面的改进,并用于生成用例。然后形成优先的需求。供应商和开发商管理团队 一起工作来定义需求,这些需求被用来产生架构和高级别的需求。开发团队用来生产产品的设计。此外,综合 管理团队定义了产品开发的安全政策和实践。 生产产品时。该过程定义了开发活动将如何结构化 以及将收集哪些工件进行核查和验证。以下是一个简短的清单安全SDLC过程和实践的例子。 NIST“安全软件开发框架”,6 卡内基梅隆大学"安全的软件开发生命周期过程"。7 ACM"计算机系统中的信息保护"。8 OWASP“安全开发生命周期”,9 6NIST安全软件开发框架 7卡内基梅隆大学安全软件开发生命周期流程 8https://web.mit.edu/Saltzer/www/publications/protection/ 9OWASP安全软件开发生命周期(SSDLC) “思科安全开发生命周期”,10 Synopsys的"安全软件开发生命周期阶段"。11 US-Cert"安全的软件开发生命周期流程"。12 OpenSSF"安全软件开发基础课程"。13 除了制作的高级开发文件外,管理团队还定义了用于安全软件开发的安全实践和程序,如:。 安全的编码实践, 代码评审过程中, 软件库程序、测试和漏洞评估。 安全地建立和分发产品的程序。 一旦发布,产品就会通过支持渠道被监测到缺陷,并提供给产品使用者。客户和开发人员可以安全地提供更新和升级,以解决报告的问题。 对于安全SDLC中的每一项操作,都要创建工件,以证明对以下内容的遵守情况所需的过程并加以概述。这些工件在""中概述。附录D:工件和 检查表.” 2.1安全的产品标准及管理 中描述的第二节。2开发安全的代码通过第2.5节提供代码,开发人员的用例取决于安全SDLC中定义的程序和政策。 过程。开发团队经理和成员调整和定制这个过程,以满足他们的具体需求。安全SDLC确定了确切的程序和政策,用于确保 实施安全的开发实践,并创建工件来证明。遵守已通过的安全SDLC计划,以实施和分配该产品。 一个开发团队是由开发、质量保证(QA)、构建等方面的专家组成的。工程,和安全。产品管理团队是由具有产品知识的人组成的。 具备领导经验,包括产品和开发经理、安全架构师、和公司一级的质量控制评估员,都有助于产品发布的监督。 最高级别的组织管理团队必须确保安全的开发政策和 在预算