2023 年 XNUMX 月，CISA 发布了新的软件安全联合指南，名为 改变网络安全风险的平衡：设计安全和默认原则。该指南由美国国家安全局、澳大利亚网络安全中心（ACSC）、德国联邦信息安全办公室（BSI）等9个不同机构合作编写。来自世界各地的多个机构合作编写网络安全指南这一事实应该有力地证明了网络安全主题目前在全球范围内的重要性。
CISA 主任 Jen Easterly 在最近向匹兹堡卡内基梅隆大学的学生和教师发表的演讲中分享了她对网络安全主题的看法。 CISA 主任表示，这些指导原则应该有助于在未来几年引导全球软件行业：
- 安全的负担绝不应该完全落在客户身上。软件制造商应对其产品和代码负责。
- 技术制造商应该拥抱彻底的透明度，作为对其产品负责的承诺。
- 技术制造商应专注于构建安全的产品，开发设计安全且默认安全的产品。
CISA 指南采用了这些基本原则并对其进行了扩展，包括软件制造商可以采取的全面实用建议列表，以将更安全的产品推向市场。
有趣的是，许多明确的建议都是基于 NIST 的 SSDF 框架 但措辞更加实际，不那么自愿。
该指南中的一项建议与彻底的透明度直接相关，即软件制造商应包括制作 斯博姆 在他们的 SDLC 中提供对其软件组件的可见性。
但是创建 SBOM 甚至发布它真的就足够了吗？软件生产者或软件消费者实际上可以使用 SBOM JSON 或 XML 文件做什么？
在本文中，我们将研究 SBOM 可以为当今的软件生产商带来的用途、可以添加到 SBOM 中以丰富其内容的信息，以及通过检查此类丰富文档可以获得的商业智能。我们将快速了解使用 SBOM 的合规性方面以及您作为软件生产商、软件聚合商或开源维护者的责任所在。最后，我们将讨论风险管理以及 CISA 的设计安全和默认安全原则如何与网络安全监管合规性和开明的风险管理相结合。
并非所有 SBOM 都是一样的
如今有许多工具可用于创建 SBOM，从开源到专有解决方案，希望将 SBOM 创建纳入其 SOP 的个人或公司可以轻松实现。人们可以在不同的选项之间进行选择 标准 最适合他们需求的工具，但即便如此，您也可能面临太多工具来做出明智的决定。那么，在决定正确的选择时，您还需要寻找什么？ SBOM生成 适合你的工具吗？
首先，检查创建 SBOM 时包含或省略了哪些信息。包含属于开发过程但不属于实际产品一部分的工具和代码的物料清单可能包含大量冗余信息，这些信息很难从结果文件中“清除”，以便您只保留最相关的信息。同样，例如，当您想要扫描漏洞时，未包含或故意省略的工具或代码将明显丢失。
软件成分和依赖项的列表本身基本上是没有意义的。除了你可以选择用它做的事情之外，它没有什么用处。当今 SBOM 最普遍的用途是扫描软件组件以获取可能影响您的产品的漏洞列表。
重要的是要记住，您发现的大约 95% 的漏洞在您的产品中是不可利用的。诀窍是找到那难以捉摸的 5%，制定工作计划并开始处理这些可利用的漏洞。如何判断什么是可利用的，什么是不可利用的？这是让安全和工程人员夜不能寐的大问题。当前的一个建议是采用一种名为 VEX – 漏洞利用交换，一种安全咨询形式，其目标是在使用组件的产品环境中传达具有已知漏洞的组件的可利用性。它仍然留下了大量的工作来筛选漏洞信息并找到可利用漏洞的线索，这些工作主要由工程团队负责。毕竟——谁会比编码人员更了解他们的产品呢？
不过，您还可以做其他事情，特别是当涉及来自 docker 映像的父映像或来自依赖链中较远的依赖项的继承漏洞时。使用开源工具，例如 父图像 您可以找出哪些漏洞是由父映像带来的，哪些是您的代码直接导致的。这应该可以消除大量潜在的漏洞，并使筛选工作变得更加容易。使用有关不同漏洞的各种建议也是一个好主意，因为一旦确定某个漏洞不可利用，就应该让团队中的其他人或用户知道，这样您就不必在每个版本中继续检查相同的漏洞您甚至没有修改在其中找到该模块的模块。还建议遵循您的开源和第 3 方依赖项，以便一旦他们发现并修复可利用的漏洞，您就可以更新产品中的代码以确保您也免受该特定潜在问题的影响。
您还可以在 SBOM 上添加什么？
如上所述，当今 SBOM 最常见的用途之一是作为漏洞扫描的清单。使用各种免费可用的数据库，例如 NVD（国家漏洞数据库），您可以扫描组件列表（类似于 SBOM 提供的列表），并查看其中包含哪些漏洞。获得漏洞列表后，您可以按严重程度对其进行排序，检查是否有现有的修复程序，等等。
关于组件的另一层有用信息是它们的许可证。许多开源组件附带的许可证与商业用途不兼容。重要的是要确保所有开源组件（即使是您自己未包含但由其他组件包含的组件）与您尝试在其许可证方面制作的任何内容兼容。
最后一个建议是遵循您的依赖项的开源安全“健康”指标，例如 OpenSSF 记分卡。对开源库的网络安全健康状况进行客观相对简单的衡量，对于决定在产品中包含或删除哪些库可能有很大帮助。这些分数与漏洞严重性相结合是帮助排序您想要首先处理的漏洞的好方法。
作为商业智能练习的风险管理
存在多个 安全风险 对于当今任何软件生产商来说都是如此。在恶意软件、加密货币挖矿程序、密码窃取程序和勒索软件之间，制造商感到将任何东西推向市场都是安全的，这真是一个奇迹。没有人能够同时处理所有事情，因此公司创建威胁模型并尝试根据他们认为最薄弱的环节来管理风险。最简单的第一步是确保您的代码和开发流程符合任何相关法规和最佳实践。 尼斯特的SSDF 和 OpenSSF 的 萨尔瓦多 以及美国对 SBOM 之类的要求都是一个很好的起点。遵循法规和最佳实践至少可以保证相对安全，免受诉讼 安全港 程序。但这只是开始。
CISA 指南鼓励制造商在构建产品时首先考虑安全性。产品完成后的一些“附加”安全性无法缓解产品架构中的一些基本弱点。根据该指南，“设计安全”的产品是将客户的安全作为核心业务目标而不仅仅是技术功能的产品。也鼓励制造商拥抱 根本透明 和问责制。这意味着，除其他外，确保漏洞公告和相关的常见漏洞和暴露（CVE) 记录完整、准确。这还意味着鼓励共享代码的组件、其依赖项和漏洞，以此向用户和客户表明制造商至少意识到产品中的潜在问题。
根据维基百科， 商业智能 (BI) 包括企业为实现目标而使用的策略和技术 数据分析 和商业信息的管理。正如您可以想象的那样，收集每个版本的 SBOM 以及漏洞报告、许可证信息以及详细说明哪些漏洞可利用和不可利用的建议 – 这是大量信息。当您考虑到典型软件产品的生命周期以及您希望获得您正在使用的任何第三方代码或工具以及您所包含的开源包的此信息时，信息点的数量就会增加，直接或暂时地。为了以组织的安全权力（可能是 CISO 及其下属）可以使用的方式理解这一切，您需要一个系统，一个单一的“管理平台”平台它使您能够组织所有信息、有效搜索信息并在需要时将其呈现在有用的报告中。仅举一个例子来说明 BI 平台对于网络安全平台的重要性，请想象一下 日志4J 去年的剧。通过敲击几下键盘来搜索所有产品（包括依赖项和第三方工具）来应对这种“新”威胁，不是很棒吗？检查是否存在刚刚发布的不同的新威胁 CVE 怎么样？或者准备一份报告，说明贵公司的漏洞总数如何随着时间的推移逐渐减少（或至少没有增加）。这种有用的“大局”信息只有位于网络安全 SBOM 丰富的收集平台之上的 BI 系统才能提供。
只有掌握了所有相关信息后，您才能真正评估当前代码、依赖项以及选择在产品中包含或省略某些第三方工具或代码的风险。当持续运行时，您还可以使用此风险评估来控制构建，并在发现某些可疑活动时阻止它们的生产或交付。
展望未来
技术一直在不断进步。如果曾经将位于组织办公室的服务器上的整体代码项目视为常态，那么现在则由多云微服务架构和法学硕士引领。 SBOM 需要不断进步，以便能够支持任何复杂的架构或基础设施软件，以保持其相关性和有用性。例如，OWASP 的 CycloneDX 已经在致力于包括 机器学习透明度 以他们的 SBOM 格式。在规划未来时，同样的格式还确保包括 VEX 功能和 SBOM 共享 API。我预测越来越多的平台，例如由 刻划式打标系统 将创建用于积累和共享包括 SBOM 在内的安全相关信息，这既是出于监管原因，也是为了这些丰富的信息为正确利用它的组织带来的利益和价值。
Scribe 的平台即将发布一个新的 BI 工具，作为现有安全平台的一部分，具有我建议的所有功能以及更多功能。我鼓励你 试试看，查看随着时间的推移积累的此类信息的有用性，并了解您可以使用这些信息做什么。无论您是否选择将 Scribe 平台合并到 SDLC 中，对更安全的生态系统和更全面、更有用的 SBOM 的争夺还远未结束。最好现在就开始透明化，而不是通过监管或市场压力强行要求你实现彻底的透明化。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
