基于构件的软件开发-基于gstreamer的网络媒体播放系统的开发

本周在欧洲开源峰会上讨论的开源 GitBOM 工具可以自动跟踪每个构建工件中包含的每个源代码文件。

微软首席软件工程师 Nell Shamrell-Harrington 通过视频连线告诉与会者基于构件的软件开发，GitBOM 工具基于一种紧凑的工件依赖图（Artifact Dependency Graph，ADG）技术，可以在任何编程语言和环境中进行验证，而无需开发商的任何努力。 以及打包格式中使用的工件。 为此，gitBOM 重用了 Git 版本控制软件中可用的有向无环图。

GitBOM 标识符（一个唯一的、内容可寻址的引用）需要在构建时插入到工件中。 Shamrell-Harrington 说基于构件的软件开发，这个标识符随后会创建一个可供 ADG 使用的 Gitoid。 每个 Gitoid 然后将工件视为二进制大对象 (bLOB)，通过它识别进入工件的所有组件，包括源文件、依赖项和目标文件。

还包括对 Package Data Interchange 2.3 格式的支持，该格式用于共享 GitBOM 发现的软件物料清单 (SBOM) 信息。

GitBOM 还在运行时检测每个可能受影响的软件工件中的潜在漏洞，无论其深度如何，以便 IT 团队更轻松地解决问题。 这种方法使得在（例如）应用程序环境中查找可能的 Log4j 漏洞的每个实例变得更加简单。 GitBOM 仅包含创建指纹所需的最少信息，以实现对已知易受攻击工件的高效运行时扫描。

Shamrell-Harrington 说，目标不是取代 SBOM 工具，而是让它们更容易以对开发人员来说最无摩擦的方式收集工件数据。 GitBOM 允许将任何元数据链接到一组特定的相应软件工件，从而更容易准确地发现它们的构造方式。 然后可以扩展工件 ID 以生成其他构建工具可以使用的 GitBOM 文档。

GitBOM 的共享正值对保护软件供应链的关注达到历史最高水平之时。 在 Log4j 漏洞被披露后，拜登政府要求每个联邦机构建立一个 SBOM，使开发人员能够发现易受攻击的软件组件的实例。 大多数大型企业组织通常都会效仿。

然而，收集 SBOM 只是更大挑战的第一步。 然后，组织需要工具来分析 SBOM 并向应用程序开发人员提供反馈。 事实上，组织最终将能够根据用于创建软件的组件来接受或拒绝软件。 有了这些洞察力，开发人员可以选择升级软件组件，以便应用程序符合组织定义的任何策略。

SBOM 在 IT 组织中普及可能还需要一段时间，但眼前的问题只是找到侵入性最小的方式来创建它们。