该论文关注一个长期被安全社区低估的问题：Python 的 import 语句不仅是依赖解析机制，更是一个执行边界——在模块与包的初始化阶段就会实际执行代码。这种执行可能触发异常、动态加载模块或原生扩展、访问文件/网络/环境资源，甚至在应用尚未调用目标包的任何 API 之前就修改安全敏感状态（如全局配置、日志、密钥、认证开关、反序列化钩子等）。作者指出，已有研究多聚焦于包选择风险、恶意包检测或包自身的漏洞，而缺少对「导入行为本身如何引发缺陷与安全问题」的系统性实证分析。为填补这一空白，作者构建了 ImportMine 研究流程：把公开安全公告（advisories）与 PyPI 项目历史数据结合，利用源码与补丁证据进行人工/半自动确认，回答四个问题——import 在什么条件下激活问题、问题为何产生、开发者如何修复、以及需要哪些程序信息才能解释该行为。研究保留 31 个与 import 相关的公告漏洞和 38 个应用-数据边界案例，并在 1,302 个代码仓库中确认了 1,429 个项目历史缺陷。关键发现包括：在初始化阶段被激活的项目历史缺陷中，97.6% 会导致正常执行中断或功能受损；而在 20 个初始化阶段激活的公告漏洞中，90.0% 被评级为 High 或 Critical。模块级代码与包初始化共激活了 98.3% 的分析案例，说明风险主要集中在导入即执行的语义上；动态加载虽占比很低，但其案例大多执行了安全敏感操作。作者还观察到一种普遍的修复反模式：许多补丁只是改变 import 何时变为「激活」（延迟导入、条件导入、移动到函数内部），而非真正移除依赖或消除危险副作用。最后，论文发布了 ImportVulBench，包含 228 组修复前/修复后配对程序，覆盖全部 11 种缺陷类型，可用于评估静态分析与程序理解工具对 import 触发行为的检测能力。

Python 应用在机器学习、科学计算等关键领域广泛存在，这些应用常通过集成 C 等底层语言编写的原生代码来提升性能或实现互操作。然而，原生代码中的缺陷（即 native code bugs）通常隐蔽且难以察觉，给整个 Python 应用的质量带来了额外挑战。尽管已有相关研究，但学术界和工业界对这些缺陷的系统性理解仍然不足。本文首次针对 Python 应用中的原生代码缺陷进行了深入的大规模实证研究。作者从 GitHub 上真实的开源 Python 项目中人工筛选并分析了 216 个原生代码缺陷，结合自动化工具与人工分析，系统梳理了这些缺陷的常见症状（如崩溃、内存错误）、引入位置（如绑定层、扩展模块）、外在表现特征、根本原因（如内存管理错误、类型转换问题、引用计数问题）以及修复模式。研究获得了一系列新颖的发现，例如这些缺陷往往集中在特定类型的 API 边界处，且某些根因在不同项目中反复出现。作者还总结了有效的修复策略和代码审查中值得关注的信号，为 Python 生态中的开发者、代码审查者以及安全人员提供了第一份系统的证据基础，有助于改进工具检测、测试方法和编程实践，从而降低原生代码引入的安全与稳定性风险。

该实证研究聚焦于 Python 字节码作为安全工件的风险，揭示了当前 Python 包安全机制主要依赖源代码检查，但 Python 运行时可直接执行 .pyc 文件、编译模块和序列化后的代码对象，造成检查与执行之间的差距。研究者收集了 1,034,843 个 PyPI 制品，识别出 7,388 个包含字节码的制品，涉及 228,578 个 .pyc 文件，其中 28,193 个为制品内无对应源代码的字节码文件。针对现代 CPython 3.8-3.14 字节码，至少一个反编译器能够为 204,901/204,904 个文件生成源代码，但这仅代表发射成功，而非验证功能等同。工具鲁棒性方面，PyPI 实际字节码可触发反编译器的托管异常和超时，而对抗性变异字节码更可导致反编译器进程崩溃，共观察到 17 种不同鲁棒性特征。模糊测试产生 1,009 个堆栈去重后的运行时发现，以指针解引用为主；其中 261 组具有潜在内存破坏特征，至少 91.7% 的组能执行到超出文档声明的不安全摄入边界之外。这些发现均无法从普通 Python 源码复现，表明字节码行为可独立于源代码。结论强调，字节码是生态系统中显眼的、可分析的、与安全相关的解释器输入，其行为可能偏离源代码语义，安全审查必须将其纳入考量。

该论文关注Python包供应链安全中的重建验证问题。Python已成为AI交互的主流语言，包主要通过PyPI分发，但恶意注入风险日益突出。独立重建包（在加固环境中重新构建）可以生成构建溯源，提高包的可靠性。现有两个大规模重建工具macaron和oss-rebuild对PyPI上12,180个流行版本进行重建，发现字节级等价率普遍较低（macaron仅15.4%，oss-rebuild仅19.1%）。论文分析了重建后wheel包差异的原因，并提出一种基于归一化函数内核的等价关系，该内核通过保持溯源的数据日志规则定义。作者实现了工具daleq4py，用于自动判定Python wheel包的等价性。实验表明，daleq4py将可接受的等价重建比例大幅提升：对源码等价的重建，macaron从15.4%提升至60.2%，oss-rebuild从19.1%提升至78.9%。该方法为大规模自动化重建验证提供了实用方案，有助于增强Python包供应链的安全信任基础。适合安全研究员、软件供应链安全工程师及PyPI包维护者阅读。

Python原生的序列化协议pickle虽然功能强大，但存在已知的安全风险，尤其是在传输不可信数据或保存机器学习模型时。为了缓解风险，开发者通常会在反序列化时限制导入的模块，或使用静态和动态分析工具检测恶意负载。然而，这些方法依赖于对Pickle虚拟机（PVM）操作码的准确解释，而Python的三种原生PVM实现（pickle、cPickle、_pickle等）之间存在行为差异，可能导致误判或漏检。为了高效、可扩展地发现这些差异，本文提出了PickleFuzzer，一种基于生成的定制化模糊测试工具。PickleFuzzer根据自定义语法生成pickle对象，然后分别传递给不同实现，通过比较异常抛出和关键内部状态的变化来检测不一致性。它不需要规范的预言机，而是通过差分测试比较执行行为。实验发现了14个新的不一致性，其中4个是严重的安全缺陷，可绕过Hugging Face等模型托管平台使用的安全扫描工具。作者已向Python软件基金会报告了所有发现，并通过漏洞赏金平台获得750美元奖励。研究表明差分测试是发现pickle实现中安全相关差异的有效方法，为未来更定向的模糊测试提供了方向。

本论文首次开展了大规模的人类辅助Python反编译实践研究。研究数据来自pylingual.io平台，涉及181,646个PYC二进制文件、9,003个用户提交的修补补丁以及393个经过准确性验证的补丁。论文分析了逆向工程师如何应对不准确的反编译结果，并识别出影响其达成准确反编译的关键因素。此外，作者还通过受控用户实验，将修补不完美Python反编译的技术难度作为独立变量进行考察。研究发现，用户通常需要手动修正反编译器输出的错误，且错误类型复杂多样，包括控制流、变量命名、类型推断等问题。实验结果表明，即使经验丰富的逆向工程师也需要耗费大量精力才能修复反编译输出。该研究为提升反编译工具的性能和用户体验提供了实证依据。

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