转载自www.onekey.com
为构建、集成或部署的固件生成软件物料清单（SBOM）的目的，不仅在于了解其中包含哪些软件组件及其版本，还在于将这些组件版本与已知的漏洞进行关联。
传统上，组件及其版本与一组已公开的漏洞之间的映射关系是通过通用平台枚举（CPE）来实现的。CPE是一个字符串，它以以下格式明确定义了受影响的组件：cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>。CPE 本身与CVE相关联。
对于可能已有记录但未收录在官方CVE数据库中的漏洞，可使用PURL，其标准化格式如下：scheme:type/namespace/name@version?qualifiers#subpath。
该机制运行良好，但存在两个主要限制条件：
● 正确性。CVE编号管理机构（CNA）需要为其发布的CVE分配正确的CPE，并维护这些CVE的CPE集合。
● 表达能力。CPE 并没有提供足够的信息来说明CVE可达且可被利用的具体条件。这包括受影响的模块、函数、功能等。
在这篇关于CVE匹配的第二篇博客文章中，我们将通过分析Android操作系统的CVE来探讨这两项限制。
每当谷歌发布影响Android操作系统的CVE时，他们会附上只显示受影响系统到Android OS版本的CPE（例如 cpe:2.3:o:google:android:10）。这些CVE通常会在他们发布修复这些CVE的Android补丁级别的当天发布。
这些补丁会在《Android 安全公告》中有所记录，表格会详细说明哪些CVE在哪个AOSP版本上被修复，以及属于哪个补丁级别。在下面的截图中，我们可以看到，例如，如果你应用了2025-03-01补丁级别，CVE-2024-0032就会在 12、12L、13、14上被修复。
2025年3月Android安全公告列出了多个影响Framework的CVE
这意味着，等到Android操作系统的CVE信息发布时，其CPE信息可能已经过时无效了，无法准确反映当前补丁状态。
仍以上面的示例为例，如果您的固件当前运行在Android 12 系统上，且补丁级别为 2025-03-01，那么 CPE 匹配会认为 CVE-2024-0032 影响到了您，但实际上并非如此。
Android CPE 通常会识别出“google:android”以及操作系统版本。这足以发现可能存在的CVE，但Android的修复机制是通过每月发布的安全补丁级别来体现的。因此，两台报告运行Android 13的设备，其安全风险可能截然不同，这取决于它们的补丁级别是在解决某个CVE的公告之前还是之后。
为了探究这一补丁级别差距有多大，我们收集了所有至少有一个CPE属于google:android的CVE。在6,512个CVE中，有4,847个不同的CVE出现在Android安全公告中。
我们收集了从4.4.4到17的每个明确的Android操作系统标签。诸如“16 QPR2”和“16-qpr2”之类的等效拼写会被规范化一个标签；而点版本和12L则保持独立。这产生了21个用于分析的明确版本标签。此外，还有2,876个公告CVE缺少可用的明确版本标签，但仍然被计入整体覆盖统计中。恰好有2个 CVE在公告的Linux内核部分带有6.1标签；追踪保留了该证据，但该标签未包含在Android OS图表中。
注：“原始候选项”并不意味着存在风险，“已移除”也不一定意味着该NVD记录在历史上有误。前者是基于版本的发现结果；后者则是基于明确的补丁级证据所做的评估调整。
对于每个操作系统标签，“最新补丁版本”指的是在固定公告数据中明确可用的该操作系统的最新补丁级别。对于已停止支持的版本，这指的是其可达到的最终级别，而非当前日历月。
上下文决策采用我们内部的“Android AOSP 规则”语义。如果被测试的操作系统版本等于或高于公告中明确指明的版本，且其补丁级别等于或晚于公告的补丁日期，则该规则会形成支持“不受影响”方向的证据。如果上述任一条件未满足，该候选项仍保留。当无法获取版本信息时，将保守地以补丁日期作为判定依据。没有公告规则支持的原始候选项仍保留为候选项，并被计为补丁级别证据不足。
根据补丁级别上下文筛选仅限特定 Android 版本的候选项
对于已达到最终可用补丁版本的Android 4.4.4，共有893个仅限该版本的候选项进入比较范围，最终剩余253个，候选项数量减少了71.7%。对于已锁定最新补丁版本的Android 16，相应数量分别为206和19，减少了90.8%。
请注意，这些条形图并不是用来比较支持生命周期的。旧版本的可用公告日期较少，而且数据集会随时间变化。
关于某个Android操作系统CVE是否影响特定版本和补丁级别的元数据来自Android安全公告，因此按版本统计的公告覆盖率是一个有效的衡量指标。通过这种方式，我们可以发现信息收集中的潜在缺口。
下面的覆盖率图表将每个版本的原始受影响群体分为两类：一类是具有可用安全公告规则的候选对象，另一类是缺乏充分补丁级别证据的候选对象。覆盖率可能很高，但消除率却很低：安全公告可能会明确指出，经过测试的版本或补丁级别仍然受到影响。反之，覆盖率不足绝不能作为移除的依据。
按版本划分的 Android 安全公告规则覆盖范围
在8.x版和12版之间存在一个明显的下降趋势。我们最初的假设是，这是由特定供应商的 CVE 引起的，但当时并不清楚究竟是哪家供应商导致的。请继续阅读，您会找到原因。
尽管这些漏洞都与Google:android CPE相关，但Android CVE并非在所有设备上都具有普遍适用性。其中相当一部分CVE仅影响高通、三星、联发科或 LG等制造商的定制代码。
该信息既可在CVE描述中查看，也可在参考资料中查看，参考资料通常会链接到供应商的特定资源。
此类案例的一个典型例子是 CVE-2024-34663，该漏洞报告涉及 libquram（一款仅存在于三星设备上的图像解码库），并将其与 google:android CPE 相关联：
CVE-2024-34663，一个影响三星 libquram.so 的漏洞
这些“错误”的CPE来自相关厂商，而在此具体案例中，是“三星移动（三星电子有限公司的移动通信业务）”发布的CNA。我们认为这些CPE有误，因为它们认为任何运行Android 12、13或14版本的Android设备都受到一个仅存在于三星设备上的漏洞的影响。而且，即使在三星设备中，也并非所有设备都嵌入了libquram。
通过绘制各厂商特定 CVE 的分布图，我们发现 21% 的 Android 操作系统 CVE 属于厂商特定 CVE：
按去重后的供应商上下文划分的Android CVE占比
图中列出的类别包含387个高通、533个三星、63个联发科和46个LG的CVE。具有多个已识别供应商信号的CVE 在“多供应商”类别中仅计数一次；未包含上述任一单一信号的CVE则仍归类于“其他Android CVE”。
为了验证Android 8.x至12版本中公告规则覆盖率较低是否与厂商特定CVE数量增加同时发生，我们使用与目录级视图相同的去重厂商类别，对每个版本的原始NVD数据集进行了划分。从Android 7.0到12版本，我们已经可以看到三星在厂商中的占比呈上升趋势。
按版本划分的 Android CVE 中的供应商背景
仅凭聚合分布无法确定造成这一现象的主要因素，因此我们针对每个受测版本，将供应商类别与公告规则覆盖范围按规范的 CVE 标识进行了关联。
该合并结果表明，三星是导致从Android 8.x到12版本总体覆盖率较低的主要因素。在Android 8.0、8.1、9或12版本中，没有一个标记为三星的候选漏洞被安全公告规则覆盖；在Android 10版本中，305个候选漏洞中仅有1个被覆盖；在Android 11版本中，249个候选漏洞中仅有1个被覆盖。高通在同一版本范围内的覆盖率始终维持在97.2%至97.8%之间，这印证了高通CVE通常包含在Android安全公告补丁规则中的假设。
在该区间内，被标记为“三星”的候选项占缺乏公告规则证据的候选项的64.8%至92.9%。图表中的确定性反事实分析仅从各版本的分母中剔除了这些行：Android 10的覆盖率从69.5%上升至86.6%，Android 12的覆盖率从81.9%上升至98.4%，从8.0到12的每个版本均呈现相同的变化趋势。
对于确实影响特定 Android 操作系统版本和补丁级别的 CVE，如果它们仅影响您未在固件中集成的特定 AOSP 应用程序，那么这些漏洞可能不会影响您的固件。
这些内容可能可以表示为 <target_sw> CPE 字段，或者通过 Android 应用程序包的自定义 PURL（例如 pkg:aosp/com.google.android.nfc@1.0）来实现，而不是使用通配符来匹配整个操作系统。
我们针对 Android 操作系统制定了一些应用程序特定规则，这些规则涵盖了部分（但并非全部）应用程序特定的 CVE。具体内容如下：
针对特定应用的 Android 上下文，按包标识进行去重
对比样本包括92个蓝牙、30个NFC、21个“设置”、20 个“通话”、4个 Keymaster 以及3个 Wi-Fi 相关的安全漏洞（CVE）。“其他应用程序特定”类别收录了上述命名组之外的包范围内的发现；“非应用程序特定”类别则包含没有应用程序规则的安全漏洞（CVE）。
仅基于Android操作系统版本进行简单的CVE匹配是不够的，这会导致报告大量误报。
在ONEKEY，我们通过以下方式解决这一问题：
● 确保该CVE影响您固件当前运行的版本和安全补丁级别，从而在Android 16上将候选CVE数量减少 90%；
● 当CVE与特定供应商相关联时，确保您的固件由该供应商生产，或运行在该制造商的芯片组上；
● 当CVE影响特定的Android软件包时，确保您的固件嵌入了该Android 应用程序。
由于谷歌和厂商提供的CPE信息质量较低，这些工作我们不得不自己来完成。在理想情况下，Android团队应维护与Android CVE相关的CPE条目：始终在CPE的“update”字段中提供安全补丁级别；当CPE影响AOSP包时，在“target_sw”字段中提供包名；并对三星或LG等主要厂商发布的特定于厂商的条目中的数据提出异议或进行修正。
与此同时，您可以放心，我们的平台会为您过滤掉无关信息，让您能够专注于真正影响您的Android固件和设备的问题。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。