微软正在将其内部的、跨平台的软件物料清单生成工具公开化和开源化
SolarWinds的系统管理工具的妥协对任何使用CI/CD（持续集成和持续交付）构建流程的软件的人来说都提出了很多有趣的问题。我们如何才能确保我们分发给用户的软件是我们打算构建的软件？我们的代码的所有依赖性都是我们打算拥有的吗？如果我们使用了第三方模块，它们还是我们所期望的吗？
这是一个复杂的问题，由于我们在所有的代码下放置了分层和嵌套的依赖基础，使得问题更加复杂。现代开发依赖于来自世界各地的代码库，这些代码库是由无数的团队和个人开发的，我们永远不会见到。即便如此，我们还是相信他们的代码会像它所说的那样--我们把这种信任传递给我们的用户。
这一切都深深地交织在一起，正如Ted Nelson所说的那样。软件开发的网络远远超出了我们的办公桌和存储库。我们要怎么做才能确保对我们的代码的信任？
为什么要制定软件材料清单，为什么是现在？
美国政府对SolarWinds的妥协做出了回应，发布了"关于改善国家网络安全的行政命令"，要求国家标准和技术研究所制定和发布指导方针，以加强软件供应链的安全，即共同构建我们的代码的模块和组件网络。这些指导方针现在已经出台。他们要求软件在发货时必须有一个软件材料清单（SBOM），详细说明与你的代码一起发货的组件。
SBOM并不新鲜。许多公司，包括微软，都使用专有的清单向他们的用户提供这些材料。在没有标准化的情况下，格式各不相同，而且往往不是机器可读的。微软正在与信息和软件质量协会的工具对工具SBOM工作组合作，为SBOM模式制定一个标准。美国的行政命令增加了这一进程的紧迫性，该工作组已着手将其工作与Linux基金会的更成熟的软件包数据交换（SPDX）格式合并。
微软一直在使用它自己的工具，用它自己的报告格式为其软件生成组件清单。作为加入SPDX标准进程的结果，微软的内部工具已被更新为使用这种替代格式，并在其自身的开发和构建管道中推广。
像这样的工具需要广泛使用，易于使用，并能在你的代码可能使用的所有平台上工作。它们需要插入常用的开发工具或CI/CD管道，以确保代码的信息在开发和编译的地方被捕获。
生成两次SBOM似乎是多余的，但如果你的CI/CD管道被破坏了，合并时的SBOM与构建时的SBOM的比较可以帮助在代码发货前发现可能的问题。一个设计良好的SBOM工具将提供所需的数字签名和哈希值，为构建过程增加额外的认证，以帮助识别它是否被破坏，以及在哪里和何时发生破坏。
在你自己的构建中使用微软的工具
微软的内部SBOM工具现在是开源的，在GitHub上有二进制文件和源代码。该项目正在快速发展，并增加了新的检测器，以帮助识别代码和它的来源，以及它给你的代码库带来的依赖性。最后一点是关键。你可能知道你从NuGet或npm安装的是什么，但你对它所依赖的代码的洞察力要少得多。你可能认为你正在发送一些无害的东西，但却发现一个小小的依赖正在你的客户的硬件上运行一个加密器，将加密货币发送给世界另一端的罪犯。突然间，不仅你的客户在运行不安全的、有风险的代码，而且你现在要对这种风险和由此产生的任何问题负责。
安装微软的SBOM工具是非常简单的。GitHub上的readme有一些脚本，可以用PowerShell为Windows下载最新的二进制文件，也可以用curl为Linux和macOS下载。一个NuGet包与SBOM工具的API一起工作，你可以把它添加到.NET项目中。这使用GitHub自己的包库，你需要在其中添加你的项目文件的PackageReference。一旦你更新了你的代码的.csproj，运行dotnet restore ，为你的项目安装该包。
当前版本的微软SBOM工具是一个命令行应用程序。一旦下载并安装，它就可以使用了。你将需要创建一些文件来使应用程序运行。最重要的是一个需要包含在你的SBOM中的文件列表。这可以从你的应用程序源目录的目录列表中生成，也可以从你的代码所调用的模块中生成。你甚至可以给它一个要扫描的Docker镜像列表，以生成你的代码和构建过程之外的任何容器级依赖的列表。
在引擎盖下，SBOM工具的关键组件之一是组件检测，这是一个可以独立运行或在Visual Studio内运行的工具。它支持大多数常见的软件生态系统，扫描代码中的模块，并在可能的情况下建立一个依赖关系图，显示哪些模块被安装，从哪里安装。同样，这是一个开源工具，如果你使用的生态系统不被支持，可以选择使用其扩展支持来添加你自己的扫描。
为CI/CD编写SBOM扫描脚本
由于它是一个CLI工具，微软的SBOM工具是可以编写脚本的；你可以把它嵌入到你的CI/CD管道中，作为构建的一部分生成一个SBOM，并扫描你的源文件的依赖性和组件。产生的SBOM是一个SPDX JSON文档。虽然它是人类可读的，但你可能更喜欢写一个简单的JavaScript应用程序来解析数据并在浏览器中显示，甚至把它作为安全信息和事件管理或类似的安全工具的反馈，以报告应用程序版本之间的差异。在最简单的情况下，它可以识别可能需要调查的新组件和依赖关系。在更复杂的应用程序中，你可以生成一个可能有风险的组件列表，需要安全团队进行额外的调查。
一个有用的功能是支持分层构建，从模块化应用程序的不同组件中包裹SBOMs。在这里，每个组件的构建都会从自己的依赖树中生成自己的SBOM。当应用程序在最终构建阶段被打包时，该工具为整个应用程序生成一个组合的SBOM，准备与客户共享。各个SBOM在最终清单中被引用，允许它们与最终构建的SBOM进行核对，以确保不需要的软件不会与你的代码一起被打包。
SBOM是现代软件开发的一个重要工具，在当前的安全环境下，它们应该被认为是必不可少的。自动构建SBOMs非常重要，因为依赖链的深度对开发人员来说几乎是无法理解的。通过包括识别模块和组件以及扫描容器的工具，微软的免费SBOM工具在满足监管要求方面大有作为，同时让你通过主动提供SBOM和组件清单作为每次安装的一部分来领先于客户需求。
