你看到的并不一定是实际执行的：基于内存的运行时组件清单（SBOM）生成技术，用于供应链安全防护

《Computers & Security》：What You See Is Not What You Execute: Memory-Based Runtime SBOM Generation for Supply Chain Security

　　摘要
现代软件开发严重依赖于来自公共仓库的第三方组件，这扩大了软件供应链的攻击面。为应对这些日益增长的风险，联邦政府推动了软件材料清单（SBOM）的发展，作为一种标准化机制来提高透明度，通过描述软件组件、依赖关系及其相互关系来实现。然而，基于元数据或文件系统工件构建的SBOM无法捕获运行时加载和执行的组件，尤其是在像Python这样的动态生态系统中。此外，通过 Instrumentation 生成运行时SBOM 需要提前部署监控，并且系统在整个执行过程中必须保持可观察状态。在生产环境和事件响应场景中，这些条件很难满足。相比之下，易变内存提供了一个可靠的方式来恢复运行中应用程序的实际运行时状态，而无需预先进行 Instrumentation。因此，本文提出了 MEM-SBOM，这是第一个直接从 Python 应用程序的运行时状态生成 SBOM 的内存取证框架。它从解释器的内部结构中恢复模块，解析包版本，并分析字节码以构建依赖关系图并识别可到达的脆弱函数。我们将 MEM-SBOM 实现为 Volatility 3 插件套件，并对其在 51 个真实世界的 Python 应用程序中进行了测试。在非敌对条件下，它实现了 100% 的提取准确性，识别出 Streamlit 是唯一调用 tornado 依赖项中脆弱函数的应用程序，并恢复了现有 SBOM 工具遗漏的所有运行时包，提供了更准确的依赖关系图和更好的脆弱性评估。这些能力使 MEM-SBOM 成为软件供应链安全和事件响应的实际基础，因为它提供了系统中执行的代码的取证可靠视图。

引言
第三方库和框架在公共仓库中的广泛采用已成为现代软件开发不可或缺的一部分，它促进了快速的功能集成，同时也扩大了软件供应链的攻击面（Nahum 等人，2024 年；网络安全与基础设施安全局（CISA），2021 年；国家反情报与安全中心（NCSC），2021 年）。对手正越来越多地利用这些仓库分发恶意包，从而危害下游应用程序（Vu 等人，2023 年）。2024 年，在公共注册表中发现了超过 700,000 个恶意包，比前一年增加了 156%（Sonatype，2025 年）。官方的 Python 仓库 PyPI 也多次遭遇此类事件，仅 2022 年就移除了超过 12,000 个恶意包（Fiedler，2023 年），尽管进行了仓库级别的扫描（Samaana 等人，2025 年；Kampourakis 等人，2025 年）。例如，zlibxjson v8.2 包含了窃取凭据的脚本，用于导出 cookie 和身份验证令牌（Wang，2024 年）；fshec2 则在编译后的字节码（.pyc）中隐藏了凭证盗窃和远程命令处理功能，以逃避检测（Nelson，2023 年）。2025 年 4 月，另外三个恶意包（bitcoinlibdbfix、bitcoinlib-dev 和 disgrasya）被下载了超过 39,000 次，其中最后一个包包含了自动化的信用卡欺诈脚本（Lakshmanan，2025 年）。即使是被信任的框架也可能引入关键漏洞，例如 Django 中最近的 SQL 注入漏洞（CVE-2025-64459），受影响的版本在本文撰写时仍在 PyPI 上公开可用（Bidart，2025 年）。这些反复发生的事件凸显了提高软件供应链透明度的迫切需求，促使监管机构和行业努力提高对软件组成的可见性。作为回应，由网络安全与基础设施安全局（CISA）和国家电信与信息管理局（NTIA）领导的倡议推动了软件材料清单（SBOM）的发展，作为一种标准化的软件透明度和风险管理机制（国家情报局局长办公室（ODNI）等人，2023 年）。SBOM 是一个结构化的软件组件和依赖关系清单，指定了它们的元数据（例如名称、版本和许可证）及其关系（工具和实施工作组，2024 年）。根据 CISA 的指导，SBOM 已成为联邦软件采购的越来越重要的要求（网络安全与基础设施安全局（CISA），2025 年）。因此，出现了多个工具来自动化跨生态系统的 SBOM 生成。然而，这些工具仍然受到静态元数据的限制，如构建清单和包文件（例如 requirements.txt、pyproject.toml 和 setup.py），这些文件描述的是构建的内容而不是实际执行的内容。先前的研究表明，由于格式支持不一致、解析器差异以及对动态或环境特定依赖关系的处理较弱，这些基于元数据的工具生成的 SBOM 是不完整和不准确的（Yu 等人，2024 年；Dalia 等人，2024 年；Cofano 等人，2024 年；Xia 等人，2023 年；Stalnaker 等人，2024 年）。此外，元数据文件本身也可能受到攻击，因为攻击者可能会修改依赖关系规范，误导 SBOM 工具生成错误的组件和版本信息（Zahan 等人，2023 年）。最近的努力将 SBOM 生成扩展到了软件部署阶段，包括容器级分析（Kawaguchi 和 Hart，2024 年）、包管理器集成（Benedetti 等人，2025 年）以及部署组件的完整性验证（Sharma 等人，2024 年）。尽管这些方法相比静态构建阶段的方法提高了准确性，但它们仍然依赖于文件系统工件和包管理器，这些只反映了软件在安装时的状态。在动态解释型语言（如 Python）中，这种限制更加明显，因为依赖关系是在执行过程中解决的，而不是在构建时解决的。运行时 SBOM 通过系统 Instrumentation 捕获运行中应用程序的活跃组件来解决这一限制（Mirakhorli 等人，2024 年）。然而，这种方法假设系统在整个执行过程中可以安全地被监控。在生产环境中，这种监控会引入操作开销，并有可能干扰正在调查的运行时状态（Beyer 等人，2016 年；Reichelt 等人，2024 年）。此外，在事件响应场景中，受损系统无法安全地暂停、调试或事后 Instrumentation。现有的运行时 SBOM 工具反映了这些限制，因为它们要求目标系统在调查事件之前处于活动状态、可观察并且已 Instrumentation，包括基于代理的平台（如 Rezilion 的 Dynamic SBOM（Rezilion，2022 年））、基于 eBPF 的监控器（如 Oligo Security（Oligo Security，2023 年）以及 Instrumentation-API 工具（如 Eclipse jbom（Eclipse Foundation，2022 年）。除了部署限制之外，根据公开可用的文档，这些方法从外部观察应用程序行为，而不分析加载组件的内部状态、构建运行时依赖关系图或追踪其中的脆弱代码路径，同时仍然从安装元数据中获取包版本。易变内存通过提供一种可靠的方式来恢复实际运行时组件和依赖关系，直接从语言运行时中获取这些信息，而无需预先 Instrumentation 或活系统来解决这些差距。在这项工作中，我们针对 Python，因为需要特定于语言的 SBOM 工具（Stalnaker 等人，2024 年），以及跨生态系统的跨语言工具产生的不一致结果（Halbritter 和 Merli，2024 年；Mirakhorli 等人，2024 年）。Python 由于其高度灵活的导入机制而给 SBOM 生成带来了独特的挑战，该机制允许在运行时通过条件性、延迟性或反射性导入加载模块（Ali 等人，2025b），导致不同的框架和应用程序以不同的方式加载和保留依赖关系。例如，在升级共享依赖项（如 asgiref）时，Django 的 StatReloader 会在执行期间动态地将新版本加载到内存中，而 Celery 缺乏自动重载机制，继续使用启动时已加载的旧版本。因此，在本文中，我们提出了 MEM-SBOM，这是第一个直接从 Python 应用程序的运行时状态生成 SBOM 的内存取证框架。它遍历解释器的内部结构，包括模块注册表、线程上下文、垃圾收集器和堆区域，以提取内存中的所有模块。这种多层次架构即使在存在逃避技术的情况下也能确保完整性和取证可靠性，例如模块删除和覆盖、导入钩拦截、绕过导入的模块创建、子解释器注入和垃圾收集器操纵。然后汇总从所有层和应用程序进程中恢复的模块，过滤掉内置和标准库组件，并按其顶级包进行分组。为了确定提取的第三方包的版本，MEM-SBOM 检查所有模块的版本属性，将它们与安装元数据相关联，并在必要时查询 PyPI，然后将这些包序列化成符合 CycloneDX 标准的 SBOM。除了生成 SBOM 之外，MEM-SBOM 还分析与每个包关联的 Python 对象，并反汇编其函数的字节码，以构建捕获直接和传递运行时关系的依赖关系图。利用生成的 SBOM 和图表以及公共脆弱性数据，该框架执行细粒度的函数级可达性分析，以区分运行时可利用的代码路径。我们将 MEM-SBOM 实现为 Volatility 3 新插件套件（Volatility Foundation，2025 年），并在 51 个真实世界的 Python 应用程序中进行了测试，这些应用程序涵盖了 23 个不同的类别，包括 CLI 工具、Web 框架、机器学习平台、工作流调度器和可视化工具。经过双重静态和运行时真实值的验证，MEM-SBOM 准确地提取了已安装包的缓存元数据，并在异构执行环境中恢复了所有应用程序包，包括那些在运行时动态加载的包。它还识别出十个实例，其中加载代码中嵌入的版本与安装时声明的版本不同。在 tornado 案例研究中，函数级可达性分析显示，在六个依赖 tornado 的应用程序中，只有 Streamlit 在运行时调用了脆弱函数，消除了 83.3% 的误报。最后，我们将 MEM-SBOM 与八种最先进的 SBOM 工具进行了比较，发现它们都不支持所有 Python 元数据配置，也无法捕获动态加载的包，导致 SBOM 不完整、依赖关系图部分构建，以及最终脆弱的报告不准确。

我们的贡献如下：
• 我们提出了 MEM-SBOM，这是第一个直接从 Python 应用程序的运行时状态生成 SBOM 的框架，提供了基于执行的软件组件视图。
• 我们描述了在运行过程中隐藏 Python 模块的逃避技术，并设计了一种能够检测和恢复所有模块的强大多层次提取架构。
• 我们构建了运行时依赖关系图并执行函数级脆弱性可达性分析，识别可利用的代码路径。
• 我们在 51 个真实世界的 Python 应用程序中评估了 MEM-SBOM，实现了比现有 SBOM 工具更高的准确性和脆弱性精度。

本文的其余部分组织如下。第 2 节提供背景信息，第 3 节总结相关工作。第 4 节讨论威胁模型。第 5 节概述关键挑战，第 6 节解释方法论。第 7 节介绍评估结果，第 8 节讨论通用性、限制和未来方向，第 9 节总结本文。

背景
本节介绍了 SBOM 的类型和标准，随后概述了 Python 运行的导入机制和内存分析。

相关工作
评估现有的 SBOM 工具。先前的研究主要评估了 SBOM 工具、标准化挑战和采用障碍。Dalia 等人（2024 年）从多平台支持、格式兼容性和易用性方面评估了 Syft、Microsoft SBOM Tool、Tern 和 CycloneDX 工具，表明这些工具仍然是静态的、基于元数据的，并且缺乏操作准备性。Mirakhorli 等人（2024 年）分析了 84 种工具，观察到它们严重依赖于包管理器。

对手目标
对手旨在通过 PyPI 和 GitHub 等公共仓库分发恶意 Python 包，将它们注入应用程序的依赖关系链中，并确保它们在受害者的系统上执行，而不被平台扫描器、SBOM 生成工具或运行时分析工具发现。

对手能力
对手可以通过模仿合法包（通过 typosquatting、starjacking 和依赖关系混淆）或通过破坏现有包来制作和分发恶意包。

挑战
本节确定了 MEM-SBOM 设计要克服的六个挑战。
C1：对 Python 导入系统的规避操纵。Python 的动态特性允许在运行期间对其导入系统进行内省和修改。同样的灵活性可以通过 monkey patching、自定义导入钩子或动态加载器来实现扩展性，也可以被利用来隐藏或修改内存中的模块。攻击者可能会删除或覆盖解释器注册表（sys.modules）中的条目。

方法论
图 1 说明了 MEM-SBOM 框架。在识别出应用程序进程并定位内存转储中的解释器内部结构后（Ali 等人，2025b），该框架提取运行时模块以生成符合 CycloneDX 标准的 SBOM、依赖关系图和函数级利用路径。这三个输出通过一个渐进式管道连接起来。SBOM 列出了应用程序的运行时包及其版本，然后对其进行扫描。

评估
本节首先验证了 MEM-SBOM 在生成跨异构安装环境的准确运行时 SBOM、构建依赖关系以及实现精确的脆弱性影响评估方面的能力。它还通过一系列实验展示了其在运行时包恢复、依赖关系图完整性和脆弱性相关性方面的优越性。

通用性
尽管 MEM-SBOM 针对的是 Python 运行时，但其实现处理了 Python 版本 3.6 到 3.14 之间的结构变化。该方法论的通用性超越了Python范畴，因为内存取证技术已被应用于从各种解释型和编译型语言的运行时环境中恢复运行时状态（Sylve等人，2012年；Case和Richard，2016年；Wang等人，2022年；Manna等人，2022年；Ali等人，2026年）。然而，每种运行时环境都具有独特的内存管理机制、对象布局等特性。本文介绍了MEM-SBOM，这是一个首个能够直接从Python应用程序的运行时状态生成准确软件清单（SBOM）的内存取证框架。通过遍历解释器注册表、线程状态、垃圾回收器、线程分配区和堆区域，该框架能够恢复所有驻留模块，甚至那些无法通过单一提取方式找到的模块。提取出的模块随后会根据其父包进行过滤和分类，以隔离出应用程序包及其版本信息。

**作者贡献声明**
Hala Ali：负责撰写、审阅与编辑、原始草稿的撰写、内容验证、软件实现、方法论设计、调查分析、数据整理以及概念构建；
Andrew Case：负责撰写、审阅与编辑、内容验证、软件实现、方法论设计、调查分析以及概念构建；
Irfan Ahmed：负责撰写、审阅与编辑、项目监督以及方法论设计。

**手稿准备过程中使用生成式AI和AI辅助技术的声明**
在本书的编写过程中，作者使用了Claude（Anthropic）工具对语言表达进行了一些微调和组织工作。使用该工具后，作者对内容进行了必要的审阅和编辑，并对最终发表的文章内容承担全部责任。

**利益冲突声明**
作者声明没有任何可能影响本文研究的已知财务利益或个人关系。

**作者背景**
Hala Ali于2026年在美国弗吉尼亚州里士满的弗吉尼亚联邦大学（VCU）获得计算机科学博士学位。她的研究领域包括内存取证、恶意软件分析以及软件供应链安全。她于2016年在叙利亚霍姆斯的AlBaath大学获得信息工程学士学位，并于2020年在印度特伦甘纳邦瓦朗加尔的国家技术学院获得计算机科学与信息安全硕士学位。