Grype项目中关于扫描目录时内部格式控制的深入解析

在Grype项目的实际使用过程中，用户发现了一个值得深入探讨的技术现象：当直接使用Grype扫描目录与先通过Syft生成SBOM再扫描时，结果存在显著差异。本文将全面剖析这一现象背后的技术原理，并探讨其对安全扫描工作的影响。

现象描述

用户在使用Grype扫描包含依赖项的目录时，发现了三种不同扫描方式产生不同结果的情况：

1. 直接使用grype dir:.命令扫描目录
2. 先使用Syft生成CycloneDX格式的SBOM，再通过grype sbom:sbom.json扫描
3. 先使用Syft生成SPDX格式的SBOM，再通过相同方式扫描

前两种方式结果一致，而第三种方式则识别出了额外的安全风险。这一现象引发了关于Grype内部处理机制的疑问。

技术原理分析

Grype与Syft的协同工作机制

Grype在扫描目录时，内部会调用Syft生成中间表示形式。无论用户是否显式生成SBOM，这一过程都会发生。关键在于Syft生成的中间表示形式与显式生成的SBOM格式之间的差异。

包类型识别的重要性

核心差异在于包类型的识别。当使用直接扫描或CycloneDX格式时，.NET包会被正确识别为dotnet类型。而使用SPDX格式时，类型信息可能丢失，导致包被标记为UnknownPackage类型。

匹配策略的差异

Grype针对不同类型的包采用不同的匹配策略：

• 对于dotnet类型包，默认仅使用GitHub安全咨询数据库(GHSA)进行匹配
• 对于未知类型包，则默认启用CPE匹配

这一策略差异解释了为何不同扫描方式会产生不同结果。CPE匹配通常会产生更多结果（包括可能的误判），而GHSA匹配则更为精确但覆盖范围有限。

深入探讨.NET包扫描挑战

元数据提取的复杂性

.NET可移植可执行文件(PE)格式的元数据提取面临诸多挑战：

• 不同厂商使用不一致的版本信息格式
• 同一产品的不同版本间格式可能变化
• 二进制文件中可能缺少精确匹配CPE所需的信息

当前提取机制

Syft目前从PE文件中提取以下字段用于识别：

• 文件版本信息
• 产品名称
• 原始文件名
• 内部名称
• 公司名称

但这些字段的格式和完整性在不同二进制文件间差异很大，导致识别准确率受限。

实用解决方案

启用CPE匹配

对于.NET包扫描，可以通过设置环境变量启用CPE匹配：

GRYPE_MATCH_DOTNET_USING_CPES=true grype dir:.

这将使Grype对.NET包也使用CPE匹配策略，可能发现更多安全风险，但需注意可能的误判。

高级配置方案

用户可以通过Syft生成SBOM后手动编辑，修正已知的第三方组件信息，再传递给Grype：

syft -c config.yaml dir:. | grype

这种方式虽然需要更多手动干预，但能提供最精确的结果。

总结与建议

Grype与Syft的协同工作机制为安全扫描提供了强大能力，但也带来了理解成本。对于.NET环境下的扫描工作，建议：

1. 了解默认匹配策略的差异
2. 根据需求选择是否启用CPE匹配
3. 对于关键系统，考虑手动验证扫描结果
4. 关注项目更新，未来版本可能会改进.NET包的识别精度

通过深入理解这些机制，用户可以更有效地利用Grype进行安全风险扫描，在覆盖范围和精确度之间取得平衡。