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

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



                                                       模式驱动的漏洞测例子集
                                               最小可复现测试用例        兼容 Python 3.13 的测
                               漏洞模式分类           (Python 驱动模块和    试环境以保证语义一        统一测试接口 (包括
                                                 C/C++ 扩展模块)     致性与版本兼容性        XML 格式源汇点定义)
                        漏
                        洞
                        基
                        准
                        套                             软件供应链真实工程漏洞子集
                        件                                                             评估系统
                              高安装              检测互操作接口, 分析      本地配置构建环境, 确
                              PyPI 软件包库        外部函数声明与实现,        保测试集可正常编译            漏洞标签
                                                 提取互操作程序             与评估


                                              图 4 漏洞基准套件构建总体流程图

                    针对第   2  节中定义的每一种细粒度漏洞模式, 构造对应的最小可复现测试单元, 统一由一个                        Python  测试脚本
                 与一个配套的     C  扩展模块构成, 形成“模式-测例”一一映射关系. 所有测例均提供一致的测试接口, 并通过统一的
                 测试脚本调用目标测例, 以支持自动化批量测试与结果收集. 事实上, 我们在漏洞测例子集中构建的测例要远多于
                 在第  2  节中展示的测例, 即一个细粒度漏洞模式会对应多个具体漏洞情形. 以代码                     5  的整数溢出漏洞为例, 接口层
                 运算溢出   (T1.2) 除了来自加法外, 还可能来自其他运算如乘法、移位等.
                    为了保证在不同工具和平台下的可执行性与稳定性, 所有测试用例均基于                         Python 3.13  环境进行构建, 确保语
                 义一致性与版本兼容性. 同时, 考虑到           Mopsa 与  PolyCruise 等程序分析工具的构建需求, 测试模块在构建时内嵌
                 相关辅助标注与兼容支持, 并配套提供以             XML  格式编写的    criterions.xml 源点/汇点定义文件, 标注输入变量与潜
                 在传播路径, 以满足静态污点分析与动态信息追踪的需要.
                    漏洞基准测例按照漏洞模式编号组织目录结构, 并采用模块化设计以支持后续对测试集的动态增补与工具适
                 配的迭代更新, 具备良好的可维护性与可扩展性.
                  3.2   软件供应链真实工程漏洞子集构建
                    在基于   Python/C API 构建  C/C++扩展模块的过程中     (参考图  2 代码), 跨语言程序通常包含#include<Python.h>
                 这一关键性的预处理指令. 该头文件作为             Python-C/C++互操作外部接口     Python/C API 的核心入口, 集中声明了所
                 有与  Python  解释器交互所必需的函数、数据类型、宏定义等. 因此, 本文以是否包含#include<Python.h> 作为一
                 种项目级的静态特征, 用于初步判定项目中是否存在                 Python-C/C++互操作行为, 从而作为后续筛选的依据.
                    具体的项目筛选流程如图          4  所示. 首先, 我们参考第三方统计平台提供的安装数据, 获取了                PyPI 平台上安装
                 量排名前   100  的软件包. 这一选择策略的初衷在于确保所筛选项目具有较高的实际使用频率和社区影响力, 能够
                 代表主流工程实践中       Python-C/C++互操作程序的开发现状.
                    随后, 我们编写自动化脚本, 对上述项目源码进行递归遍历, 检测各源码文件是否包含                          Python.h  头文件. 该检
                 测作为一个快速过滤步骤, 能够有效排除完全未使用                 C/C++扩展机制的项目. 然而, 该策略并非充分条件, 因为某
                 些文件虽包含该头文件, 但可能仅用于文档示例、测试代码或注释, 尚不足以确认实际互操作行为. 为进一步提升
                 识别准确性, 本文实现了一个基于           Clang  的轻量级静态分析器, 用于深入分析源码中是否存在实际的                   Python-C/
                 C++互操作结构. 该分析器能够从源码中识别出声明外部函数的                      Python/C API 结构体  PyMethodDef (图  2  第
                 14–19  行), 并进一步提取其定义的     Python  侧调用函数名及其对应的       C/C++外部函数实现.
                    通过以上的静态结构分析与筛选, 我们最终得到                16  个安装量排名前列且实际包含         Python/C API 调用的  PyPI
                 软件包, 这些项目具有代表性且在           Python  软件供应链中使用广泛. 除了用于编写          C/C++扩展外, Python/C API 还
                 可以用于将    Python  运行时嵌入  C/C++程序以实现     Python-C/C++调用, 这种用法在   Python  软件供应链中非常少见.
   41   42   43   44   45   46   47   48   49   50   51