(编辑中)软件发布前 OSS [外包检索]（OSS系列 004）

OSS [外包检索]

在软件外包服务中，作为外包人员，当甲方仅开放部分仓库模块代码（如 Network - * 系列仓库），并提供 OSS 名称及版本信息时，精准检索项目中的 OSS 漏洞与评估修复情况，成为保障项目安全稳定运行的关键任务。本教程将围绕整理 NVD 与 OSS 评分表、判断 CVE 漏洞对应功能使用及修复情况，进行深度、细节化阐述，并提供充分论证依据。

一、前期准备：构建精准检索基础

（一）全面梳理甲方提供信息

1. 信息核对与确认：拿到甲方提供的 OSS 清单（如包含 “log4j 2.14.1”“okhttp 4.9.3”）后，与甲方项目负责人进行详细沟通，明确清单中各 OSS 在项目中的应用场景与大致功能模块。例如，确认 “okhttp” 用于项目的网络数据交互模块。同时，对清单中的版本号进行二次校验，避免因笔误或信息传递错误导致后续检索偏差。
2. 制定检索计划：根据仓库模块开放范围（如 Network - * 系列仓库）和 OSS 清单，制定详细的检索计划。确定每个 OSS 在代码审查和功能分析阶段的重点关注区域，明确各阶段的时间节点与责任人，确保检索工作有条不紊地进行。

（二）环境搭建与工具准备

1. 搭建本地测试环境：在本地搭建与项目生产环境相似的测试环境，包括安装相同的操作系统、数据库、中间件等。对于涉及网络通信的 OSS（如 “okhttp”），配置相应的网络代理和防火墙规则，模拟真实的网络环境，为后续功能模拟与测试提供准确的运行条件。
2. 选择合适的代码扫描工具：除了常用的 ScanCode 工具外，还可搭配使用 WhiteSource、Sonatype Nexus 等工具，进行交叉验证。WhiteSource 能够实时监控开源组件的漏洞和许可证风险，Sonatype Nexus 则可帮助管理项目依赖，检测依赖传递过程中引入的潜在漏洞。将这些工具组合使用，可提高扫描结果的准确性与全面性。

二、检索执行：深度挖掘 OSS 漏洞信息

（一）基于 NVD 的漏洞信息检索

1. 高级搜索技巧应用：在 NVD 官网（https://www.nist.gov/itl/nvd）搜索时，除了输入 OSS 名称和版本号进行基础搜索外，还可利用高级搜索功能。通过筛选 “影响类型”（如 “远程代码执行”“信息泄露”）、“发布日期” 等条件，快速定位与项目相关性高的 CVE 漏洞。例如，针对 “log4j 2.14.1”，优先筛选出近一年内发布的高危远程代码执行漏洞。
2. 关联其他漏洞数据库：为获取更全面的漏洞信息，将 NVD 查询结果与 CVE Details、SecurityFocus 等漏洞数据库进行交叉比对。不同数据库在漏洞描述、影响范围和修复建议等方面可能存在差异，通过综合分析，可更准确地评估漏洞对项目的实际影响。例如，CVE Details 数据库可能会提供更多关于漏洞利用方式的实际案例，帮助判断项目受攻击的可能性。

（二）代码审查与功能分析

1. 代码结构解析：对于开放的仓库模块（如 Network - * 系列仓库），首先分析代码的整体结构，识别出各功能模块的划分和依赖关系。通过查看代码中的包名、命名空间、目录结构等信息，快速定位与 OSS 相关的代码文件。例如，在 Network - * 仓库中，根据包名 “com.example.network.okhttp”，找到 “okhttp” 相关的代码文件。
2. 函数级代码审查：对与 OSS 相关的代码进行逐行审查，重点关注函数的输入参数、处理逻辑和输出结果。利用代码注释、函数命名等信息，理解函数的功能。对于复杂的函数逻辑，可绘制流程图或使用调试工具进行动态分析。例如，在审查 “okhttp” 处理 HTTP 请求头的函数时，通过调试工具观察请求头数据的解析过程，判断是否存在未验证长度的缓冲区操作，从而确定是否存在与 CVE 漏洞描述匹配的代码逻辑。
3. 功能调用链路追踪：借助 IDE（如 IntelliJ IDEA、Eclipse）的代码导航功能，追踪 OSS 功能在项目中的调用链路。从入口函数开始，逐步分析函数之间的调用关系，确定哪些功能模块实际使用了 OSS 的特定功能。例如，通过追踪发现，项目中的用户登录模块调用了 “okhttp” 的网络请求功能，将该模块作为重点审查对象，进一步分析是否存在 CVE 漏洞风险。

（三）功能模拟与漏洞复现

1. 测试用例设计：根据 NVD 中 CVE 漏洞的描述和代码审查结果，设计针对性的测试用例。测试用例应覆盖所有可能触发漏洞的场景，包括正常输入、边界值输入和异常输入。例如，对于 “log4j 2.14.1” 的远程代码执行漏洞，设计测试用例时，构造包含恶意代码的日志信息，模拟不同的日志记录场景，测试是否会触发漏洞。
2. 漏洞复现与验证：在搭建好的测试环境中，执行测试用例。若出现与 CVE 漏洞描述相符的异常现象（如程序崩溃、数据泄露），则说明项目可能受到该漏洞影响。此时，记录详细的复现步骤和相关日志信息，作为漏洞存在的有力证据。同时，通过对比正常运行和异常运行时的系统状态，进一步分析漏洞的影响范围和潜在危害。

三、评估与判断：科学确定修复情况

（一）修复标准的精准界定

1. 官方修复版本确认：查阅开源项目官方发布的公告、版本更新日志，确定每个 CVE 漏洞的修复版本。除了关注主版本号的更新外，还要留意补丁版本的发布情况。例如，“log4j” 官方可能针对某个特定漏洞发布了 2.14.2 - 1 这样的补丁版本，该版本同样包含漏洞修复。
2. 自定义修复方案评估：如果甲方采用了自定义的修复方案，对其进行技术评估。分析自定义修复方案是否真正解决了 CVE 漏洞的根本问题，是否会引入新的风险。可通过代码审查、功能测试和安全测试等方式，验证自定义修复方案的有效性。例如，甲方对 “okhttp” 的某个漏洞进行了代码修改，通过对比修改前后的代码逻辑，以及进行大量的网络请求测试，判断修复方案是否可行。

（二）修复情况判断与论证

1. 已修复情况论证：当项目中 OSS 版本符合官方修复版本要求，且经过代码审查和功能测试未发现与 CVE 漏洞相关的代码逻辑和异常现象时，判定该 CVE 漏洞已修复。例如，项目中 “log4j” 版本为 2.16.0，高于官方修复 CVE - 2021 - 44228 漏洞的 2.15.0 版本，同时在代码审查中未发现可触发该漏洞的代码，在功能测试中也未出现异常，可得出 “CVE - 2021 - 44228 已修复” 的结论。为增强论证的可信度，可附上详细的版本对比截图、代码审查记录和测试报告。
2. 未修复情况论证：若项目中 OSS 版本低于官方修复版本，或存在与 CVE 漏洞描述匹配的代码逻辑且可被触发，则判定该 CVE 漏洞未修复。例如，项目中 “okhttp” 版本为 4.9.2，低于官方修复某 CVE 漏洞的 4.9.3 版本，并且在代码审查中发现处理 HTTP 请求头的函数存在缓冲区溢出风险，通过功能测试可成功复现漏洞。此时，详细记录代码中的漏洞代码片段、测试用例执行过程和复现结果，作为 “CVE - XXXX - XXXX 未修复” 的有力依据。

四、报告输出：专业呈现检索成果

（一）NVD 与 OSS 评分表制作

1. 表格内容细化：在评分表中，除了包含 OSS 名称、版本、CVE 漏洞编号、CVSS 评分、是否修复、理由等基本信息外，还可增加 “漏洞影响范围”“漏洞利用难度”“修复建议优先级” 等列。例如，对于 “log4j” 的 CVE - 2021 - 44228 漏洞，在 “漏洞影响范围” 列中注明 “影响所有使用该版本 log4j 的项目功能模块”，在 “修复建议优先级” 列中标记为 “紧急”。
2. 数据可视化处理：为使评分表更直观易懂，可对部分数据进行可视化处理。例如，使用颜色标记不同的 CVSS 评分范围（红色表示高危，橙色表示中危，黄色表示低危），通过柱状图或折线图展示不同 OSS 的漏洞数量趋势，帮助甲方快速了解项目的整体安全状况。

（二）总结报告撰写

1. 报告结构优化：总结报告采用 “总 - 分 - 总” 结构。开篇概述项目背景、检索目的和整体结论，中间部分详细阐述检索过程、各阶段发现的问题及修复情况判断依据，结尾提出针对未修复漏洞的具体解决方案和项目后续安全建议。在每个章节中，合理运用小标题和段落划分，增强报告的逻辑性和可读性。
2. 论证材料补充：在报告中插入代码截图、测试日志、漏洞复现视频链接等论证材料，对关键结论进行支撑。例如，在描述 “okhttp” 未修复漏洞时，附上包含漏洞代码的函数截图和测试过程中程序崩溃的日志信息，使甲方能够清晰地了解问题的严重性和真实性。同时，对每个论证材料进行详细的文字说明，解释其与结论之间的关联。

 

  深度、细节化的操作流程和充分的论证，可全面、准确地完成项目 OSS 外包检索任务，为甲方提供有价值的安全评估报告和改进建议，有效降低项目的安全风险。

五、OSS检索实战

（一）前期准备

  以我接触的一个项目 AR*** 作为示例，这是一个摄像机的源码项目，而我们的任务聚焦于 Net*** 网络相关模块的 OSS 检索工作。
  该项目源码存储在甲方服务器上，我们仅能通过甲方提供的远程账号，访问搭载 ubuntu20.04 系统的服务器来开展工作，且没有服务器安装权限，这就限制了我们只能使用系统自带的基础工具进行检索。

  1.全面梳理甲方提供信息

信息类别	详情
项目名称	AR*** OSS 检索
检索目标	Net*** 网络相关模块 OSS 检索
源码存放位置	ubuntu20.04 服务器
主要开发语言	C/C++，可能包含少部分其他语言库
甲方提供 OSS 清单	已经提供清单
检索范围	Network-Wifi_Driver_152H Network-Wifi_131H Network-Infra_161H Network-Business_161H Network-Resource_161H

  2.环境搭建与工具准备

  受限于服务器安装权限，无法在 ubuntu20.04 服务器安装额外工具，只能依赖系统自带的grep、find等基础命令行工具完成 OSS 检索任务。
  提前熟悉这些工具的高级用法和组合技巧：

• • grep工具：支持正则表达式，可用于在文件中搜索特定字符串或模式。例如，grep -r -i "openssl" /path/to/Net***可递归搜索 Net*** 模块目录下所有包含 “openssl”（不区分大小写）的文件，并展示匹配行；grep -E "函数名|类名" file.cpp能通过正则表达式搜索file.cpp中包含特定函数名或类名的行，用于查找 OSS 组件相关功能代码。
  • find工具：可依据多种条件查找文件和目录。如find /path/to/Net*** -name "*.h" -o -name "*.cpp" -exec grep -i "libcurl" {} \;，先在 Net*** 模块目录下找到所有.h和.cpp文件，再对这些文件执行grep命令，搜索包含 “libcurl” 的内容；find /path/to/Net*** -mtime -7 -type f -exec grep -i "zlib" {} \;，查找近 7 天内修改过的文件，并对其进行 “zlib” 相关内容的搜索。

（三）代码审查与功能分析

  1.查看CVE漏洞说明

  

  评分挺高，漏洞描述：python-gnupg 0.4.3 允许上下文相关的攻击者欺骗 gnupg 解密其他非预期密文。要执行攻击，攻击者必须控制 gnupg 的密码，并且应该信任密文。与影响影响功能组件的“CWE-20：不正确的输入验证”问题相关。

  2.给出审查方案

  通过漏洞描述，主要是 该漏洞允许攻击者通过控制 GnuPG 的 passphrase 来解密其他不应解密的密文。
  分析发现：

1. 1. python-gnupg 是一个用于与 GnuPG（GNU Privacy Guard）加密工具进行交互的 Python 库，让开发者可以在 Python 程序中方便地调用 GnuPG 的功能。
      
   2. 本项目主要使用C/C++，也可能使用了Python语言，或则C/C++通过系统调用了python-gnupg
      • 根据官方给给出的python-gnupg使用案例，需要包含 import gnupg  ,则使用 grep 查询对应目录下的 .py 文件是否包含，再去分析
      • gpg --full-generate-key 、gpg --encrypt --recipient "recipient@example.com" -o encrypted_file.asc plaintext.txt、gpg --decrypt -o decrypted_file.txt encrypted_file.asc

  分析结论：

     ① 检查是否使用Python语言，搜索 .py 后缀 .
     ② 使用 grep 查询对应目录下的 .py 文件是否包含import gnupg ，然后进行上下文分析
     ③ 开启上下文分析.