该论文对来自 Wild SBOMs 数据集的 78,612 个真实世界的软件物料清单（SBOM）文件进行了大规模实证研究，首次刻画了其中声明的依赖图结构。研究发现，这些 SBOM 可分为三类：52.9% 的 SBOM 未声明任何边（不符合 NTIA 最低元素要求）；8.8% 虽然声明了依赖块但大多数组件孤立（退化状态，对于组件数≥50 的此类 SBOM，中位孤儿比例为 93%，且作者生成的 11 个 Syft 容器镜像 SBOM 孤儿比例达 95%-98%）；38.3% 形成了良好连接的图。边的生成完全由生成工具决定，而非被描述的软件（不同工具的零边率从 0% 到 100%）。用于声明图不完整性的规范级机制（CycloneDX compositions）仅被 0.10% 的 SBOM 使用。作者指出，在前两类状态下，常见的消费者推断“无路径即不可达”是一种不合理的封闭世界结论。在生产级漏洞优先级排序系统中，用退化检测器保护下的显式“未知”级别替换原有的否决逻辑，可将 KEV 召回率从 0.600 提升至 0.950（控制重评分），在端到端运行时达到 0.957，且不会造成警报泛滥。论文发布了流式扫描器和完整的每个 SBOM 拓扑数据集。

该研究论文探讨了软件物料清单（SBOM）在增强软件供应链安全方面的潜力。研究背景指出，软件供应链攻击日益频繁，如SolarWinds事件，凸显了透明度和可追溯性的缺失。核心问题是如何利用SBOM来识别和缓解供应链中的漏洞和风险。研究方法包括对现有SBOM标准（如SPDX和CycloneDX）的分析，以及案例研究评估SBOM在漏洞响应、许可证合规性和依赖关系追踪中的实际效果。主要贡献是提出了一个框架，将SBOM集成到DevOps流程中，实现自动化的安全审计和风险评估。实验证明，该方法能显著缩短漏洞发现到修复的时间，并提高供应链整体的可见性。适合安全架构师、DevOps工程师和合规管理人员阅读。

现代软件开发高度依赖来自公共仓库的第三方组件，这扩大了软件供应链攻击面。为了应对这一风险，美国联邦倡议推动了软件物料清单（SBOM）作为标准化机制，通过描述软件组件、依赖关系及其关联来提升透明度。然而，基于元数据或文件系统工件构建的SBOM无法捕获运行时加载和执行的组件，尤其是在Python等动态生态系统中。此外，通过插桩生成运行时SBOM需要提前部署监控并保持系统可观测，这在生产环境和事件响应场景中难以满足。相比之下，易失性内存为恢复运行中应用程序的实际运行时状态提供了可靠来源，无需事先插桩。本文提出了MEM-SBOM，首个直接从Python应用程序运行时状态生成SBOM的内存取证框架。它从解释器内部结构恢复模块、解析包版本、分析字节码以构建依赖图并识别易受攻击的函数。我们将MEM-SBOM实现为一套Volatility 3插件，并针对51个真实世界Python应用进行了评估。结果显示，它实现了100%的提取准确率，识别出Streamlit是唯一调用tornado依赖中易受攻击例程的应用，并恢复了现有SBOM工具遗漏的所有运行时包，提供了更准确的依赖图和更好的漏洞评估。这些能力使MEM-SBOM成为软件供应链安全和事件响应的实用基础，通过对系统上实际执行的内容提供取证可靠的运行时视图。