当三个美国政府机构联合起来“大力鼓励”开发者采取某些做法时，你应该注意了。 CISA、NSA 和 ODNI 认识到网络黑客的威胁并在 SolarWinds 攻击之后宣布，他们将联合发布一系列保护软件供应链的建议，以防止未来出现此类漏洞。该公告明确表示，该文件的目的是鼓励开发者采用最佳实践，并指出“这些原则包括安全需求规划、从安全角度设计软件架构、添加安全功能以及维护软件和底层基础设施的安全。“
本指南由三部分组成，并将与软件供应链生命周期同时发布。 系列的第 1 部分重点关注对软件开发人员的建议，已于 2022 年 2 月发布。其余两部分将在不久的将来发布：第 3 部分将重点关注软件供应商，第 XNUMX 部分将重点关注接收软件的客户。最终目标是，本系列将帮助促进这三个主要利益相关者之间以及网络安全专业人员之间的沟通，以促进提高弹性并改善整体 软件供应链安全.
虽然并不总是清楚谁有责任确保软件安全，但无论谁在您的特定组织中承担总体责任，这 新指南 非常清楚地表明，所有开发人员都应该熟悉这些新的最佳实践，并且他们在保护软件供应链方面都发挥着作用。或者，如果我可以更直白的话： 开发人员，你们在保护组织的软件供应链方面发挥着关键作用！ 出于这个原因，我们认为您可能会发现阅读指南第一部分的（相对）简短摘要（专为您而写）会很方便。它来了。
简而言之，该指南：
在本开发人员实用指南中提到的大量潜在威胁中，有一些已确定的关键漏洞，您应确保解决这些漏洞并做好准备：
- 尚未正确记录的功能或实现有风险的功能
- 安全评估和代码交付之间核心安全假设的低调变化
- 供应链利益相关者的企业变革
- 不合标准的编码或安全实践
管理、财务和项目经理都有责任解决软件供应链的安全问题，但软件供应链的完整性 软件供应链安全 通常取决于软件开发人员的警惕性和所有供应链利益相关者的意识。该指南的第 1 部分重点介绍了开发人员的角色以及开发过程每个阶段所固有的威胁，并提供了应成为标准实践的缓解策略的建议。
第一阶段：确保产品标准和管理
安全开发始于产品和开发团队中所有主要利益相关者认识到软件供应链安全的重要性。威胁场景很常见，可能每个人都清楚；面临的挑战是让所有人就已决定的缓解政策达成共识。这些策略必须涵盖整个流程：设计和架构、威胁建模、编码、安全测试计划、发布标准以及未来如何管理漏洞。其中一部分还包括评估团队的能力并确保他们接受过适当的任务培训，然后定义文档实践以及定期安全审查和威胁评估。
第二阶段：安全代码开发
在代码开发方面，安全编码的正确实践已经在 SSDF。这就是为什么，在编程语言尚未预先确定的情况下，安全考虑也应该成为该决定的一部分。导游 提供有用的指导 对于开发人员来说，解决各种场景，例如“内部人员”（例如开发人员）插入有害源代码、开源软件以及处理它的最佳实践。如何创建安全的编码环境（包括安全构建配置和第三方软件工具）并随后测试集成产品的安全性。由于交付后也可能会出现漏洞，因此还提供了处理报告的漏洞并确保未来的外部软件扩展不会损害产品的安全完整性的建议。
第三阶段：强化构建环境
一旦代码被安全地开发出来，软件供应链安全就要求将构建环境硬化到与软件本身相同的标准。破坏构建系统是渗透代码的一种有吸引力的方式，因为它出现在开发过程的一个阶段，开发人员自然较少对其进行审查。
第四阶段：代码交付
该指南解决的最后一个弱点涵盖了软件供应链的最后阶段——代码交付。即使到目前为止代码已经得到适当的保护，仍然有两个关键的供应链漏洞需要缓解。第一个是最终包验证，例如，可以通过无意中暴露元数据、开发人员凭据或开源清单来利用它。经常被探测弱点的另一个步骤是分发系统，该系统可能会受到中间人攻击的影响，这种攻击可以接管交付中的一个或多个阶段。
通过在软件开发层面应用这些风险缓解实践，软件供应商可以避免可能导致更新渗透、代码签名操纵和隐藏在开源代码中的“意外”等弱点。
天下没有免费的午餐：第 3 方软件的隐性成本
关键 对开发速度的贡献者 已成为有效整合第三方软件的能力。这使得开发人员可以专注于创新或功能等，同时使用现成的组件来实现可扩展性或接口。第三方软件使用的增加给软件供应链安全带来了重大挑战。除了按照与评估您自己的代码相同的标准对此类代码进行评估之外，该指南还建议扫描二进制文件中是否存在任何漏洞并评估由此产生的风险。此评估的结果应作为使用或不使用特定软件组件的决定的考虑因素。软件组件的选择还必须考虑其来源；将第 3 方组件合并到您的源代码中是长期关系的开始，您应该努力与您可以信任的合作伙伴合作。代码所有权、编码实践和版本管理策略只是选择可信来源时需要考虑的几个要点。想想当发现新威胁时每个组件的所有未来更新、发布和维护工作。面临的挑战将是监控所有第三方变更、评估漏洞并做出相应响应，有时会面临严峻的时间压力。
通过 SBOM 提高软件供应链安全性
确保软件供应链长期完整性的一项关键做法是维护更新的软件供应链 软件物料清单 （SBOM）。 SBOM 是构成给定解决方案的软件组件的详细清单。
这将节省您的时间和精力，最重要的是，将减少您面临持续威胁的风险。集成到产品中的每个软件组件都应附带其自己的 SBOM，该 SBOM 必须经过验证并合并到产品的单个“主”SBOM 中。如果您打算合并未附带 SBOM 的组件，则需要使用软件组合分析 (SCA) 工具进行自己的分析。
SBOM 越准确、描述性越强，就越容易维护和参考。鉴于软件组件更新的速度令人眼花缭乱， 结构良好的SBOM 当需要追踪并记录每个更新、补丁或版本时，就会得到回报。更重要的是，一旦发现安全威胁，每一刻都至关重要。 记得： 您的软件供应链的安全 永远和你最薄弱的环节一样强大。当有数十个软件组件面临风险时，您会感谢拥有所有答案的 SBOM。
为了实现高效的工作流程，有用的 SBOM 应至少包括以下三个组件：
- 资料栏位 – 这些是您已实现的组件的描述符。即使在开发完成很久之后，也能够轻松识别哪些组件已被使用，有助于有效地监控它们是否存在漏洞。
- 自动化支持 – SBOM 的自动监控要求它们也以一种可接受的机器可读格式进行识别。
- 实践与承诺 – 管理 SBOM 需要对维护实践有共同的理解，例如版本频率、依赖性、已知的未知数、分发和交付、访问控制以及如何适应错误。
在特定产品的利益相关者（软件开发人员、软件供应商和客户）之间共享 SBOM 有助于提高透明度和一致性，从而提高软件供应链保护产品免受安全威胁的能力。必须指出的是，考虑到软件供应链中的所有移动部件，持续维护这样的 SBOM（可以轻松引用、监控和维护）是一项复杂的挑战。
最后的话：如何将您的软件供应链安全提升到一个新的水平？
随着软件供应链安全变得越来越重要，组织不断面临着对其交付或使用的软件建立透明信任的挑战。 由于将 SBOM 作为最佳实践的采用预计会不断增长，因此拥有一个能够帮助您克服这一挑战的工具是建立软件供应链安全的关键一步。这就是为什么我们最近推出了第一个基于证据的软件产品安全中心， 使用户能够跨团队和组织建立对其软件的信任。 这个用户友好的平台将通过使 SBOM 易于访问、易于使用来帮助开发团队降低软件供应链风险，最重要的是——使软件产品的安全性对客户、买家和安全团队透明.
如果您作为软件开发人员担心您的软件供应链安全受到威胁，我们敦促您 尝试该平台;它可以免费使用，没有任何附加条件。通过实施我们的工作流程，您将能够在整个供应链中共享您的 SBOM。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
