这几年写了很多文字 斯博姆 – 软件物料清单。通过所有这些曝光，人们觉得他们知道什么可以很好地解释——它是软件成分的列表，它对于透明度和安全性很重要，并且有助于暴露暂时的依赖关系。这一切都是真的。
尽管如此，SBOM 并不像看起来那么明确。一方面，要保持更新，每个新的库版本或补丁都需要发布新的 SBOM。通常，您一次只更改或修补一两个库，这样您就可以分解它们的新成分，将其添加到 SBOM，而其他所有内容保持不变，对吗？
那么“已知-未知”的概念又如何呢？如果开发人员知道他们遗漏了某些内容，他们可以将其输入为“已知-未知”并稍后填写空白（或根本不填写）。
还有一些非常复杂的软件工件，包括多个互锁元素，每个元素都有其自身的权利。每个元素通常都有自己的、单独的 SBOM，并且整个构建可以有一个更大的、聚合的 SBOM。
这一切都表明，您最终可能会得到许多不同的、不断变化的元素，而不是一个清晰、简单的 SBOM 文件，您必须不断地使这些元素保持最新状态。
这一切都很好，但如果 SBOM 或 SBOM 的一部分不那么准确或最新，这对任何人来说会有什么不同呢？我们可以做些什么来保持 SBOM 的出处及其准确性？
在本文中，我们将研究 SBOM 在漏洞扫描和漏洞披露中的使用。我们将讨论加密签名，并了解对 SBOM 或其部分进行签名如何使其成为更有用的安全性和透明度工具。我们还将讨论元数据以及为什么它在 SBOM 和其他工件生产中如此重要，尤其是在以加密方式签署证明时。
从这里开始：什么是加密签名？
加密签名用于验证数字文件或文件夹的完整性和准确性。签名的文件无法在不使签名无效的情况下被篡改，因此一旦有人尝试验证签名的文件，就会立即被发现。
这使得数字签名成为武器库中无价的工具 软件安全 行业中，数字资产的数字或加密签名的简单概念已经发现了许多用途。
它是如何工作的？数字签名基于非对称加密技术，其中实体有两个密钥——私钥和公钥。两个密钥以这样一种方式链接在一起，即可以使用一个人的公钥来验证使用一个人的私钥签名的文档。验证意味着文档没有以任何方式被篡改（即使是单个位的更改也会使签名无法验证），并证明签名者的身份，或者至少证明所使用的密钥的身份。
您用那个 SBOM 做什么？
SBOM 不仅仅是包含软件组件信息的长而复杂的文件。它们是您准确了解软件工件由哪些组件组成的门户。您需要了解完整的组件列表，因为即使您可能认为自己确切地知道所包含的内容，但很可能您在交付的每个添加的库中都包含许多隐藏和暂时的依赖项，每个依赖项都可能是漏洞或利用的载体现在已包含在您发送给客户的软件中。
一旦您有了 SBOM 以及完整的成分列表，您就可以根据已知漏洞数据库扫描该列表，并查看您的软件中包含哪些漏洞。但这仅仅是开始。任何运行过漏洞扫描的人都知道，即使是简单的工件扫描，结果也很容易发现数百个（或更多）漏洞。
这就是艰苦工作的开始，映射每个漏洞，看看它是否可以在您的特定软件组合中被利用，记录该信息，并通过修补和修复它们来处理可利用的漏洞，最好按照它们所代表的危险顺序（实时）野外的攻击比从未发生过的理论上的攻击更危险）。
所有这些工作以及漏洞文档和修复对于软件生产商来说非常重要，而且对于您的客户、合作伙伴和潜在的审计人员也很重要。
他们想知道您是否意识到了潜在的漏洞，并且您正在修复和纠正缺陷，以便这些漏洞不会影响他们作为您的客户或合作伙伴。
由于新漏洞不断出现，因此进行扫描的时间非常重要，因此对 SBOM 及其创建时间的元数据进行签名是表明您确实处于领先地位的好方法您的漏洞列表。
通过这种方式，您可以证明您提前知道某个漏洞并且该漏洞不相关（使用 VEX 建议），它不存在于某个版本中，或者在您发布上一个版本时它甚至不存在。
我在哪里签字？
现在，让我们用本文开头描述的更复杂的用例之一替换该简单的成分列表文件。一旦您将多个 SBOM 组合起来形成一个更大的聚合版本来描述您的完整工件，签名和验证该聚合版本的每个单独部分就变得更加重要。假设您正在构建一个复杂软件工件的新版本。在这个新版本中，唯一改变的是由 1 部分组成的工件的第 3 部分。其他两个部分完全相同。为什么要浪费时间和资源来构建完整的 3 部分 SBOM、扫描所有 3 部分中的漏洞以及映射所有 3 部分中的相关漏洞？唯一的更改是在第 1 部分中，因此这是您唯一应该投入工作的部分。如果您在上次创建 3 个 SBOM 和漏洞扫描时对其进行了签名，那么您可以包含其他两部分的信息，因为您知道它不能包含这些信息。已被修改。然后，您可以随时证明第 2 部分和第 3 部分的 SBOM 与原始版本相同。当然，如果您担心新的漏洞，您可以再次进行扫描，但这完全取决于您和您的软件 风险分析.
出于多种原因，能够向您的客户、合作伙伴和审核员证明您创建 SBOM 并扫描其漏洞的时间和频率非常有用。尤其重要的是，它可能会在法庭上用来证明您不对漏洞利用造成的损害承担责任，因为您已经做了所有应该受到保护的事情，从而获得了 避风港.
从这往哪儿走
正如我们之前所说，对软件工件或文件进行数字签名的问题之一是处理密钥管理系统的麻烦。一旦我们通过使用 Sigstore 之类的东西绕过传统 PKI 的使用并使签名和验证流程自动化来消除这个麻烦，就没有什么理由不使用这个安全工具了。当您认为用于签署文件或工件的身份也可以在验证 CI/CD 管道安全性的策略中使用时，您应该更有动力开始签署几乎所有可见的内容。
使用元数据对文件进行签名可以帮助您验证其来源的时间和位置，以及创建它们的角色和系统，以及通过安全专家的视角考虑的所有相关信息。当简单的替换可以呈现签名的令人信服的伪造品时，能够判断人员、系统和时间与创建软件的公司和流程相匹配是一个好主意 - 直到检查唱歌角色。
考虑到我建议的用于签名和验证证据的工具是免费使用的，你真的应该没有任何借口。查看我们的完整文章 瓦林特 – 我们的验证完整性工具，看看您还可以用它做什么，并立即开始签署您的 SBOM 和其他生成的证据。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
