安全漏洞SCAP规范标准

关注

转载最新推荐文章于 2026-04-08 10:35:43 发布 4.1k 阅读 AI 写同款· GEO 优化 ›

「网络安全术语解读」通用平台枚举CPE详解通用平台枚举（Common Platform Enumeration，简称，CPE）是描述和识别企业计算资产中存在的应用程序、操作系统和硬件设备类别的标准化方法，它提供了一个标准的机器可读的格式，利用这个格式可以对IT产品和平台进行唯一编码。CPE字典当前最新的版本为2.3，发布于2011年7月29日，该字典以XML格式提供，由NIST托管和维护，公众可以免费使用。阅读详情

在日常的漏洞研究和管理中，通常会发现，不同漏洞平台、不同团队对于漏洞的编号、严重程度的定义通常会出现差异化。

比如以下为漏洞常见的6个要素：

我们以心脏出血漏洞为例：

这些内容都是描述心脏出血的，可以看到不同的平台有不同的编号，类别也不同，影响组件的、等级、标题都是存在差异的，那么对于安全研究人员或者漏洞管理，就不可避免的需要去识别是不是同一个漏洞，然后需要自己去判定漏洞等级和类型等，不同的人或者团队，常常就会存在如以下的矛盾点：

这缘于不同的知识面、对漏洞的认知、标准，所以才导致的这些问题。那么有没有一个统一的标准来处理这个问题？有，SCAP！

SCAP

今天主要介绍SCAP1.0版本。

SCAP包含了Protocol(协议)与Content(内容)，协议是指SCAP由一系列现有的公开标准构成，这些公开标准被称为SCAP Element(SCAP元素)，Protocol规范了这些Element之间如何协同工作。Content指按照Protocol的约定，利用Element描述的生成应用于实际检查工作的数据。

SCAP六大元素：

这其中可能大家对CVE、CVSS相对会比较熟悉，接下来就一一讲解下：

CVE

CVE相对好理解，通俗的讲就对漏洞的统一收录和编号，当然，这里是针对通用组件漏洞的，这也就是大家经常会看到会有安全人员在自己的简历写自己活得了多少个CVE编号，那意味着对应编号的通用组件漏洞是当时由他发现的0DAY，是他拥有独立的0DAY发现能力的象征；当然，CVE并没有体现漏洞的影响和严重程度等情况，所以单从CVE编号看不出什么，一个很水的漏洞也是可以申请个CVE编号的。

CVSS

CVSS是个评分系统，基本的表达方式比如右侧图的那种5.0直接分数的形式，还有就是类似于

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/RL:O/CR:L

这种向量的表达方式，至于这里面的AV、AC等都代表什么意思，我们可以继续往下看就大概清楚了。

CVSS的评分是有三个指标组，一般我们看漏洞本身的严重程度主要就看基础指标，这个指标就更多的是从漏洞本身的一些点去计算的，而时间指标组有时也会进行考虑，比如说随着时间的变化，原来没有利用方式，后面出现了，漏洞的利用情况就完全不是一回事了，危害指数可能就应该是直线上升，比如永恒之蓝，一开始漏洞爆发，虽然伴随Exp，但只有少数人会用，但是随着网上各种利用文章、MSF的插件有了之后，瞬间满世界都是利用这个漏洞攻击的；再者环境指标，主要就是漏洞在不同环境上的影响可能会有所差别。

那刚才讲到，上面的AV那些是什么？其实就是这些指标项，具体可以见下图，在PPT里被翻译成了中文是为了方便大家理解，这里面的H、L可能就代表高、低，具体可见官网说明https://www.first.org/cvss/specification-document。

回到分数计算，要怎么计算分数呢？其实是有公式的，我们以基础指标组为例。

针对漏洞的每个指标判定是属于什么情况，比如说攻击向量，有网络、相邻网络、本地、物理，指的是发起漏洞攻击的几种方式，对应用作计算的因素分数分别是0.85、0.62、0.55、0.2，一般来说，能够直接通过网络发起攻击的漏洞是最方便利用的，所以分值也最高；其他几个指标项也是一样的。

我们以漏洞《phpMyAdmin 反射型 XSS 漏洞 (CVE-2013-1937)》为例：

然后套进公式计算：

ISCBase = 1 - [(1−ImpactConf) × (1−ImpactInteg) × (1−ImpactAvail)] = 1 - [(1−0.22) × (1−0.22) × (1−0)] = 0.3916

ISC =
Scope Unchanged 6.42 × ISCBase
Scope Changed 7.52 × [ISCBase−0.029] − 3.25 × [ISCBase−0.02]15
=7.52 × [0.3916−0.029] − 3.25 × [0.3916−0.02]15 = 2.72675084384

Exploitability
= 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction
= 8.22 × 0.85 × 0.77 × 0.85 × 0.62 = 2.8352547300000004

If (ISC <= 0) 0 else,
Scope Unchanged Round up (Minimum [(Impact + Exploitability), 10])
Scope Changed Round up (Minimum [1.08 × (Impact + Exploitability), 10])
= Round up (Minimum [1.08 × (2.72675084384 + 2.8352547300000004), 10])
= Round up (Minimum [6.006966019747201, 10])
= 6.1

最终这个漏洞的基础分数就是6.1分。

大家会不会觉得这个计算很麻烦？其实不用这么复杂，官网提供了在线计算器，直接选择然后就能自动计算出来了：

这就是CVSS了。

CPE

CPE是通用平台枚举，经常描述一个漏洞的时候需要描述漏洞影响了什么组件的什么版本，那么就可以使用CPE。

CPE有三种格式，分别是WFN、URI、FS，对应的一个格式是

CPE:2.3:类型:厂商:产品:版本:更新版本:发行版本:界面语言:软件发行版本:目标软件:目标硬件:其他

前面2.3指的是使用的CPE的版本，因为CPE也有多个版本，在2.2版本里是不存在sw_edition、target_sw、target_hw、other这几个字段的，具体的表示方式大家可以参考上图左侧的样例。

当然，CPE的除了可以用来描述漏洞影响的组件及对应版本情况，还有一个重要的场景就是直接用来匹配是否存在漏洞；针对某个环境进行探测组件版本，使用CPE进行描述，然后与漏洞影响的CPE版本进行匹配，就能直接描述是否该环境受这个漏洞影响；这种场景，CPE是用对应的匹配方式，具体可以参考上图；如果需要在代码中实现，也很简单，一般都有现成的模块，比如Python有现成的第三方包也叫CPE，就包含有相关匹配、格式化的方法可以很方便的使用。

CCE

再来说说CCE，其实CCE也好理解，可以理解为针对基线配置的CVE编号，CVE是针对通用组件漏洞，而CCE是针对基线配置。

比如说图中示例的：

CCE-27868-9
Definition: The maximum password age setting for Apache's service account should be configured appropriately. Parameter: number of days. Technical Mechanisms: defined by Local or Group Policy

CCE-27868-9描述的是针对Apache服务的账号最大过期时间的要求，要求使用一个合适的值。

OVAL

继续说说OVAL，他是一种用来定义检查项、脆弱点等技术细节的描述语言。这么说好像不好理解，通俗的你可以理解为他就是告诉你怎么在一个对应的环境下一步步检测某个漏洞是否存在，他也是有一个库的，可以通过上图oval:org.mitre.oval:def:24241这样的编号去检索，是XML格式；我们还是以心脏出血为例：

这是其中一部分，描述了在Ubuntu12.04的版本下，如果系统中存在libssl 1.0.0这样的dpkg包，版本小于0:1.0.1-4ubuntu5.12那么就意味着存在心脏出血漏洞。

OVAL以一种统一的标准来描述某个漏洞的检测细节，而OVAL也是可以通过社区贡献的，这样的话，安全人员、安全工具其实就可以基于OVAL实现对相关漏洞的检测。

XCCDF

最后需要讲到的就是XCCDF了。

XCCDF看起来跟OVAL有点类似，但XCCDF被设计为支持信息交换、文档生成、组织化和情境化调整、自动一致性测试以及符合性评分，能够支持与多种基础配置检查技术交互。其中推荐的、默认的检查技术是MITRE公司的OVAL。在实际的SCAP应用中，XCCDF和OVAL往往是成对出现。可以理解OVAL可以作为一个XCCDF的子集。

在XCCDF文档中除了OVAL，你其实也能看到如CPE。它也是一种XML格式文件。

回过头去六个元素，借用网上的一张图来表示，其实他们之间的关系和作用大概是这样的：

SCAP工具

讲完了这些，有没有相关工具可以帮助我们使用SCAP这一套东西呢？比如说基于XCCDF进行检测输出检查结果？比较出名的比如有OpenSCAP：

这大概就是关于SCAP的一些简单介绍，更多的内容大家可以参考官网文档以及一些应用案例。

其实SCAP的主要作用还是统一标准，这样的话，不用安全研究人员、安全工具就可以直接应用这些标准进行相关的漏洞研究、学习、使用、检测等，一般来说，而不会出现因为不同理解而出现的描述和定义不同等问题。一般做的比较好的安全产品，即使有自己的一套标准，一般也会兼容部分SCAP，而其中CVE应用最为广泛。当然，如果在使用SCAP的过程中，对于标准的理解不同，还是可能导致一些差异，比如咱们计算CVSS过程中，对于漏洞不同指标项的判定，虽然官方有解释和说明，但也有可能不同人对漏洞理解不同而设定的结果不同，最终计算的值也会存在差异，这又是不可避免的了，但SCAP是尽可能的提供统一的标准。

注：SCAP 1.2版本新增

CCSS 通用配置评分系统，类似CVSS，只是CVSS是针对漏洞，与CVE关联；而CCSS是针对配置，与CCE关联 OCIL 开放检查表交互式语言，类似XCDDF

扩展阅读

漏洞命名

关于漏洞命名问题，之前也设计过一套命名规范，不属于SCAP规范的内容，整体的目的是通过漏洞命名就能大概清楚是什么样的漏洞，大家也可以参考下：

语法

漏洞库中的漏洞命名主要包含有产生漏洞的组件名称(即漏洞影响的组件):漏洞影响的版本、漏洞产生位置、漏洞类型以及可选的向量组成，命名规则如下:

漏洞影响组件名称+漏洞影响版本+漏洞产生位置+(向量)+漏洞类型

漏洞影响组件名称: 漏洞影响组件名称主要指的是产生漏洞的具体组件的名称，组件包含比如各种 Web 应用、某个插件、某个系统、某个通用模块等，均可称为是组件。
漏洞影响版本: 漏洞影响版本指的是对应该组件受到该漏洞影响的版本号，这里的版本号可以是单个版本(如 V1.0)或者是区间 (如>V1.0&<2.0)，也可以设定是最小值(如>V1.0)或者最大值 (如\<V2.0).
漏洞产生位置: 漏洞产生位置指的因为具体的问题导致漏洞产生，该问题所处于的文件位置(如/admin/admin.php)或者具体通用函数名或者类名(如_LoadBMP 函数)或者是两者的组合情况。
向量: 向量指 vector，可选，指的是漏洞的输入点(比如说某个 SQL 注入漏洞的向量是参数 id)
漏洞类型: 漏洞类型指的通用漏洞类型，即该漏洞对应的通用分类情况下的漏洞分类名称。