Page 54 - 《软件学报》2026年第7期
P. 54

胡明哲 等: Python  软件包库中   C/C++外部语言调用的安全性分析                                        2739


                 件工程实践中可能尤为重要, 定制分析规则并成功执行分析的困难和人工开销有时可能比识别大量误报更大.
                    ● RQ5: 已有漏洞检测工具在大型        Python-C/C++互操作项目上是否具有良好的可扩展性?
                    PolyCruise 的分析流程依赖于用户显式指定的源汇点对, 同时其与                PolyFuzz 均需构造特定输入以触发项目执
                 行过程中的动态行为, 因而在大型项目中难以进行系统性的评估. Mopsa 是静态分析工具, 但其对                           C  扩展文件的
                 结构有特定要求, 且需借助        Python  脚本触发相应执行路径, 因此在分析复杂项目时同样面临可扩展性方面的限制.
                 在实际应用方面, PolyCruise 所依赖的实现版本较低           (仅支持  Python 3.7), 其依赖分析与插桩追踪的机制需要专家
                 定制, 加之项目本身缺乏持续维护, 限制了其适用性. Mopsa 同样仅支持较低的                    Python 3.8  版本, 其静态建模所覆
                 盖的软件包并不完整, 导致一旦遇到未建模或非常规结构, 分析过程则无法继续进行. 由于上述工具在分析条件上
                 存在较大约束, 在实际评估中, 我们发现其难以对高下载量的                   16  个软件包进行有效分析. 如表        9  所示, 项目级的
                 PolyCruise 仅在  numpy 上成功触发分析, 得到   3 个警告, 其都为真阳性     (TP), 其中  1 个为接口层运算溢出     (T1.2), 2 个
                 为缓冲区越界访问       (M3.1). 文件级的  Mopsa 对  16  个高下载量软件包的所有文件都未能成功触发, 因此列举了其
                 在两个小型库上的分析结果.
                    相较而言, CPyChecker 与   PyRefcon  的集成方式更为有效: 仅需在项目的原始编译流程中将编译器替换为支
                 持  Python-C/C++互操作分析插件的     GCC  和  LLVM/Clang  版本, 即可实现对   C/C++扩展代码的自动化静态检测,
                 无需额外修改源代码或构建逻辑. 这种特性使其更易于在真实软件供应链中部署与应用, 因而我们在全部                                   18  个
                 PyPI 包  (16  个高下载, 2  个对比  PolyCruise 和  Mopsa) 上均进行了完整测试  (见表  8). 其中  CPyChecker 由于对版本
                 迭代的支持较差, 在      18  个项目中有  13  个可以顺利编译; PyRefcon   则对  18  个项目全部编译通过, 表现出最好的可
                 扩展性.
                    PyCType 依赖编译前端解析工具        pycparser, 并不利用项目原生编译脚本, 因此在配置过程中需手动指定头文
                 件路径、宏定义和编译参数. 尽管其可扩展性相较于                   CPyChecker 和  PyRefcon  较差, 但相较于  PolyCruise  和
                 Mopsa 仍表现更优. 如表    9  所示, 对全部  18  个  PyPI 包, 文件级的  PyCType 在所有包中都找到了可分析文件, 并在
                 其中  50.8%  的文件中成功触发了其支持的漏洞检查.
                    ● Answer 5. 对于表  8、表  9  中  5  个开源且非纯动态  (不完全依赖构造输入驱动) 的分析方法, PolyCruise 需要
                 针对项目定义源汇点, Mopsa 需要修改互操作源码. 仅有              CPyChecker、PyRefcon  和  PyCType 具备相对高自动化
                 地检查大型项目的可扩展性.

                  5   总结与展望

                    软件包库的安全性是软件供应链分析中的关键问题, 然而现有研究在分析                         Python  软件包中涉及    C/C++外部
                 语言调用的安全性时存在明显不足. 为此本文系统地构建了一个面向                       Python-C/C++互操作的漏洞基准套件       (开源
                 仓库地址: https://github.com/dynapx/PythonC-Benchmark), 涵盖  5  类语言特性共  15  种典型漏洞模式, 并结合  PyPI
                 中安装量最高的      16  个含  C/C++扩展的软件包进行了实证安全分析. 通过评估多种现有的先进互操作漏洞检查工
                 具, 本文在  6  个软件包中新发现      3  种共  21  个真实漏洞, 同时分析揭示了当前研究和工具在互操作安全性分析方面
                 的能力局限与改进方向.
                    (1) 提升完备性, 支持复杂语言特性互操作的安全性分析. 现有先进工具不能检查                       Python-C/C++互操作漏洞基
                 准套件   15  种漏洞模式中的    7  种, 尤其针对复杂语言特性的安全性分析存在明显不足, 包括内存管理中引用计数之
                 外的错误, 以及异常处理和并发控制相关的错误. 跨语言互操作时多种内存接口、语言间异常和并发机制的差异
                 是问题的根源, 值得深入分析. 同时, 对于能够支持的              8  种漏洞, 也存在漏报率较高的问题, 安全性分析往往只能覆

                 盖最基础的语言特性.
                    (2) 提升可靠性, 降低已有安全检查的误报率. 部分工具误报率极高, 难以应用于工业级的供应链安全分析, 确
                 认  21  个真实漏洞排除了超过      700  个误报. 现有外部调用安全性分析方法在建模粒度和分析精度上仍有不足, 此
                 外  Python/C API 的版本迭代更新也是一个重要影响.
   49   50   51   52   53   54   55   56   57   58   59