CVE-bin-tool中SBOM解析的CPE与PURL优先级问题分析
项目地址: https://gitcode.com/gh_mirrors/cv/cve-bin-tool 问题背景
在软件供应链安全分析领域，CVE-bin-tool是一个广泛使用的开源工具，用于扫描软件组件中的已知问题。该工具支持通过软件物料清单(SBOM)进行组件分析，特别是SPDX格式的SBOM文件。在实际使用中，SBOM可能同时包含CPE(通用平台枚举)和PURL(包URL)两种组件标识符。
问题现象
用户报告了一个关键问题：当SBOM中同时包含CPE和PURL标识符时，CVE-bin-tool 3.4版本会错误地优先处理PURL，导致即使存在有效的CPE信息，最终识别出的供应商仍显示为"UNKNOWN"，从而无法正确匹配已知问题。
具体案例中，一个包含cpe:2.3:a:arm:mbed_tls:3.6.0和pkg:github/Mbed-TLS/mbedtls@V3.6.0的SPDX文件被扫描时，工具未能正确识别出供应商为"arm"，而是显示为"UNKNOWN"，导致漏报了多个已知问题。
技术分析
预期行为
根据设计文档，CVE-bin-tool对SBOM中组件标识符的处理优先级应为：
- CPE 2.3标识符
- CPE 2.2标识符
- 包URL(PURL)
- SBOM中的名称和版本(供应商未指定)
这种优先级设计是基于CPE能够提供更完整的供应商信息，而PURL主要用于开源组件，通常不包含供应商信息。
实际实现问题
在代码实现中，parse.py文件中的逻辑错误地将PURL检查放在了CPE检查之前。具体表现为：
if decoded.get("purl") is not None: # 错误地先检查PURL
LOGGER.debug("Found PURL")
return decoded.get("purl")
elif decoded.get("cpe23Type") is not None:
LOGGER.debug("Found CPE23")
return decoded.get("cpe23Type")
这种实现导致了即使存在CPE信息，工具也会优先返回PURL，进而导致供应商信息丢失。
行业标准考量
值得注意的是，行业趋势确实倾向于使用PURL而非CPE，因为：
- CPE数据往往不一致且存在错误
- PURL特别适合标识开源软件组件
- PURL格式更加标准化和统一
然而，PURL的一个主要局限是不包含供应商信息，这可能导致问题匹配时供应商显示为"UNKNOWN"。
解决方案
针对这一问题，开发者提出了两种可能的解决方案：
-
修正优先级顺序：严格按照设计文档的优先级处理标识符，即先检查CPE再检查PURL。这种方法简单直接，能够解决当前问题。
-
混合使用标识符：当同时存在CPE和PURL时，可以结合两者的优势：
- 使用PURL进行组件识别
- 从CPE中提取供应商信息
- 避免重复报告相同的问题
第二种方案更符合行业发展趋势，但实现复杂度较高。
影响与建议
这个问题影响了CVE-bin-tool 3.4版本中SBOM扫描的准确性，可能导致严重问题被漏报。建议用户：
- 临时解决方案：从SBOM中移除PURL信息，强制工具使用CPE
- 等待官方修复：开发者已确认问题并将修复优先级设为较高
- 长期来看，关注工具对混合使用CPE和PURL的支持改进
对于开发者而言，这个问题也提出了一个值得深思的设计考量：在软件成分分析工具中，如何处理不同标识符系统之间的优先级和互补关系，特别是在它们各有优劣的情况下。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
