Towards the Detection of Inconsistencies in Public Security Vulnerability Reports（usenix2019）
1 绪论
1.1 论文背景及意义
电脑及网络系统的安全漏洞对广大用户、机构及组织构成严重威胁。无法匹配的漏洞常常会导致现实世界的攻击，从 WannaCry导致医院和学校数十万台机器关闭，到 Equifax数据泄露导致美国一半人口受到影响。
为了达到在漏洞被攻击者利用之前找到并修补它们的目的，一个强大的机构就因此诞生。最具影响力的力量包括常见漏洞和曝光(CVE)项目和国家漏洞数据库(NVD)。CVE是一个全球性的列表/数据库，利用“大众的力量”，将已知的漏洞进行索引，互联网上的任何人(安全供应商、开发人员和研究人员)都可以在CVE上分享他们发现的漏洞。NVD是美国政府(i.e. ,NIST)建立的一个更加标准化的数据库，NVD从CVE网站接收数据馈送，并通过分析来分配常见的漏洞严重性评分(CVSS)和其他相关的元数据。更重要的是，NVD标准化了数据格式，以便算法可以直接处理它们的数据。CVE和NVD在指导漏洞修补方面都发挥了重要作用，到目前为止，超过100,000个漏洞被索引，CVE/NVD数据流已经与全世界数百个安全供应商集成。
在漏洞数据库积累海量数据的同时，信息质量也日益受到关注，更具体地说，CVE/NVD上列出的信息可能是不完整的或过时的，这使得研究人员很难重现漏洞。更糟糕的是，某些CVE条目包含错误信息，这可能导致开发和部署补丁的重大延误。在实践中，由于更新成本高，工业系统经常长时间使用遗留软件。当一个相关的漏洞被曝光时，系统管理员通常会查找漏洞数据库，以确定他们的软件(以及哪个版本)是否需要修补。此外，CVE/NVD是安全公司评估客户安全水平的关键信息源，关于CVE/NVD的错误信息可能使关键系统没有打补丁。
在本文中，提出了一个新的系统来自动检测完全标准化的NVD数据库和非结构化CVE描述及其引用的漏洞报告之间的不一致信息。本文构建的系统VIEM首次允许我们在大范围内量化信息的一致性，本文的研究集中在易受攻击的软件版本上，这是漏洞重现和漏洞修补最重要的信息之一。在构建VIEM时，本文面临三个主要的技术挑战，首先，由于软件名称和版本的高度多样性，很难建立字典或正则表达式来实现高精度和召回。其次，漏洞报告和总结的非结构化文本往往包含代码，其独特的书写风格难以被传统的自然语言处理工具处理。第三，需要提取“易受攻击”的软件名称及其版本，并有效地排除那些令人分心的项目(例如:无漏洞版本)。
1.2 CVE/NVD简介
CVE：当人们发现一个新的漏洞，他们可以从一个CVE Numbering Authorities (CNAs)请求一个唯一的CVE-ID号码。CNA将对漏洞进行研究以确定细节，并检查该漏洞是否已经被报告过。如果漏洞确实是新的，则为其分配一个CVE-ID，并通过CVE列表公开发布相应的漏洞信息。
CVE列表是由MITRE维护的一个网站，CVE团队发布了每个报告的漏洞摘要。在写CVE总结时,CVE团队将分析(公共)第三方漏洞报告然后包括细节的描述,如影响软件的名称,漏洞软件版本,漏洞类型,利用这个安全漏洞的条件/要求。
除了摘要之外，每个CVE条目还包含一个外部引用列表。外部引用是指向第三方技术报告或博客/论坛贴子的链接，这些贴子为CVE团队提供了必要的信息，以编写非故意的漏洞描述。有关CVE的信息可以帮助软件供应商和系统管理员准确定位易受攻击的软件版本，评估其风险级别，并进行相应的补救。
NVD：NVD(National Vulnerability Database)是由一个不同于CVE的组织(例如NIST)维护的。NVD与CVE列表完全同步，目标是CVE的任何更新都会立即出现在NVD中。在新的CVE-ID出现在CVE列表之后，NIST NVD团队在第一时间执行分析，在创建NVD条目之前添加例如严重性评分等增强的信息。
与CVE相比，NVD提供了两个额外的特性。首先，结构化NVD数据条目，NIST NVD团队将把非结构化的CVE信息转换为结构化的JSON或XML，其中信息字段(如漏洞软件名称和版本)根据通用缺陷枚举规范进行格式化和标准化。其次，数据条目不断更新，在最初的漏洞报告之后，NVD中的信息可能会(手动)更新。例如，随着时间的推移，NIST员工或外部人员可能会发现新的易受攻击的软件版本，这些版本将被添加到现有的NVD条目中。
1.3 技术挑战
CVE和NVD数据库主要是手工维护的，这导致了许多重要的问题。首先，考虑到一个漏洞可能在许多不同的地方被报告和讨论，那么CVE/NVD数据库中的信息(例如，易受攻击的软件名称及其版本)有多完整?其次，考虑到相关机构不断努力研究报告的漏洞，目前手动方法保持CVE/NVD条目的最新有效程度如何?
本文的目标是彻底理解外部漏洞报告网站和CVE/NVD数据条目之间的不一致。CVE列表已经归档了超过100,000个不同的CVE(尽管某些CVE-ID被合并或撤回)。每个CVE-ID也有5~30个外部第三方报告。手工提取这些信息是不可行的。主要的挑战是从非结构化报告中自动且准确地提取相关信息项。
许多现有的NLP工具旨在从文本中提取相关信息。然而，漏洞报告的独特特征带来了重大挑战，使得现有技术不足，如下：
1.前所未有的软件出现:CVE列表介绍了新的漏洞软件频繁,很难使用一个预定义的字典来识别所有漏洞软件的名字。因此，基于字典的方法不适用于这个问题。
2.报告非结构化:大多数CVE漏洞报告摘要是高度结构化的,因此简单的基于正则表达式的技术几乎可以有效。
3.非漏洞软件是普遍的:一个漏洞报告通常包含信息漏洞和非漏洞的版本的软件(参见图1)。我们的目标是提取“易受攻击的”软件名称和版本，同时排除与非易受攻击软件相关的信息项。依赖于预定义规则的技术在这里几乎不起作用。
4.多个感兴趣的实体存在:在一份报告中提到的漏洞软件通常是指多个实体(参见图1 b)和这些实体的关系取决于上下文的报告。这一需求消除了缺乏处理多个实体能力的技术。
5.漏洞类型是多样的:CVE覆盖各种各样的漏洞类型,每一种都有其各自的特点的描述。因此，我们不能简单地使用针对某些类型的漏洞设计的技术，使用的工具是专门为内核内存损坏漏洞设计的。我们对我们的ground-truth数据集进行了测试，但没有收到令人满意的结果(召回率低于40%)。
2 系统设计
为了解决上面提到的挑战，本文通过组合和定制一组最先进的自然语言处理(NLP)技术来开发自动化工具VIEM。
2.1 系统设计概述
为了查明和匹配系统感兴趣的实体，本文设计VIEM来完成三个单独的任务。
命名实体识别（NER）模型：首先，VIEM利用最先进的命名实体识别(NER)模型来识别我们感兴趣的实体，即易受攻击软件的名称和版本、易受攻击的组件的名称和版本以及易受攻击软件所依赖的底层软件系统的名称和版本。这种设计背后的原因有两方面。首先，NER模型根据输入文本的结构和语义定位实体，这为我们提供了跟踪训练数据中从未观察到的软件名称的能力。第二，NER模型可以学习和区分与软件的易受攻击版本和非易受攻击版本相关的上下文，这使得我们排除软件的非易受攻击版本，并且只确定我们感兴趣的实体。
关系提取(RE)模型：在提取出实体后，VIEM的下一个任务是对识别出的实体进行相应的配对。如图1所示，软件名称和版本共同出现在报表中是很常见的。因此，一种本能反应是将软件名称和版本就近分组，并将其视为易受攻击的软件和版本对。然而，这种直接的方法并不适合我们的问题。如图1c所示，易受攻击的软件名称并没有与所有易受攻击的版本紧密相连。仅仅应用上述方法，我们会不可避免地会错过易受攻击的软件的版本。
为了解决这个问题，VIEM首先检查了版本和软件名称之间所有可能的组合。然后，利用关系提取(RE)模型来确定最有可能的组合，并认为它们是正确的实体对。这种设计背后的基本原理如下，RE模型的最初设计不是为了在实体之间找到正确的对，相反，它负责确定一对实体的属性，例如，假设一个RE模型被训练为为一对实体指定以下三个属性之一——“born in”、“employed by”和“capital of”。假设文本中有两对实体P1 =(“Steve Jobs”，“Apple”)和P2 =(“Steve Jobs”，“California”), “Steve Jobs出生在加利福尼亚州，是苹果公司的首席执行官。”，RE模型将把“employed by”属性分配给P1，把“born in”属性分配给P2。
在本文的模型中，每一个可能的版本和软件组合都可以被视为一对独立的实体。利用关系抽取模型的思想，VIEM为每一对分配一个属性，表示对应实体之间关系的真实性。然后，以相应的性质为正确的配对。以图2为例，2个软件(Microsoft VBScript和Internet Explorer)和2个版本范围(5.7和5.8以及9到11)显示了4个实体。它们可以以4种不同的方式组合。通过将这些组合视为4对不同的实体，我们可以使用一个RE模型来为每个组合分配一个二进制属性。假设分配的二进制属性表示对应的实体是否应该被分组为软件及其漏洞版本，VIEM可以用属性分配作为判断实体对的指标。应该注意的是，我们使用公共平台枚举(CPE)格式表示成对的实体。例如，cpe:/a:google:chrome:3.0.193.2:beta，其中google表示供应商，chrome表示产品，3.0.193.2表示版本号，beta表示软件更新。
迁移学习：回想一下，我们需要度量不同类型的漏洞报告。不同漏洞类型的报告不一定使用相同的数据结构。因此，使用单一的机器学习模型来处理所有的漏洞报告是不可行的，除非我们能够构建并手动标注一个涵盖各种漏洞的大型训练数据集。不幸的是，没有这样的标记数据集可用，并且标记一个大数据集需要大量的人力。为了解决这一问题，VIEM采取了迁移学习策略，即学习前面提到的NER，使用一个主要类别的漏洞报告进行重新建模，然后将其能力转移到其他类别的漏洞中。这样，我们可以减少数据标注的工作量，使VIEM对任意类型的漏洞报告都有效。
2.2 命名实体识别模型（NER
我们首先从文本中提取命名实体(漏洞软件的名称和版本)，我们基于最近的NER模型开发了我们的系统。除此之外，我们还整合了gazetteer，以提高其提取易受攻击软件名称的准确性。在高层，NER模型首先使用单词和字符嵌入的串联将文本序列编码为单词向量序列。这种嵌入过程是必要的，因为深度神经网络不能直接处理文本，是以单词向量的序列为输入，利用双向递归神经网络对序列中的每个单词预测一个标签。下面将介绍关键技术细节。
对于单词和字符嵌入，NER模型首先利用标准的单词嵌入方法将每个单词编码为矢量表示。然后利用双向门控循环联合(Bi-GRU)网络在字符级进行文本编码。如图3所示，NER模型将这两个嵌入件串联成一个向量序列，然后将其作为另一个Bi-GRU网络的输入。
与前面提到的用于文本嵌入的Bi-GRU网络不同，第二个Bi-GRU网络负责为单词分配标签。由于我们的任务是识别与易受攻击的软件相关的实体，所以我们使用Bi-GRU网络来确定与该信息相关的单词。更具体地说,我们训练这Bi-GRU网络分配每个单词下面的标签之一——①SV(软件版本)②SN(软件名)和③O(其他类型)——说明这个词的性质。需要注意的是，我们对易受攻击的软件、易受攻击的组件以及易受攻击的软件所依赖的底层软件都给予了相同的SN标签。这是因为此工作测量与漏洞相关的所有软件的版本不一致性2。
考虑到NER模型可能不能很好地跟踪到易受攻击软件的名称，我们进一步构建了一个gazetteer (即由81,551个软件组成的字典词典)来提高NER模型的识别性能。具体来说，我们设计了一种启发式方法来纠正NER模型未能识别或错误跟踪的信息。首先，我们对每个漏洞报告执行字典查找，然后，如果NER模型已经将至少一个字典单词标识为软件名称，我们将该报告中的字典单词标记为软件名称，这样，我们就可以纠正一些识别错误的标签。例如，在图2中，假设NER模型将SN标签分配给单词Microsoft VBScript和Explorer，表示与该漏洞有关的软件。通过字典查找，我们在地名词典中找到了Internet Explorer软件，由于gazetteer表明既不是Internet也不是Explorer曾经单独作为一个软件名称出现过，而且它们是最接近字典中的单词Internet Explorer的，所以我们扩展了我们的标签，用一个SN标签标记整个字典中的单词Internet Explorer，并将其视为单个软件。
2.3 关系提取模型（RE）
关系提取模型最初用于提取两个实体之间的关系。在过去的十年中，研究人员提出了各种技术方法来建立高精度和计算效率高的RE模型。在所有被提出的技术中，分层注意神经网络在许多自然语言处理任务中表现出更好的性能。对于我们的系统，我们修改了一个现有的分层注意神经网络去配对提取出的实体(例如，将易受攻击的软件名称与其版本配对)。更具体地说，我们在RE模型中实现了一个新的词级和句子级的组合注意网络以提高性能。下面将简要介绍这个模型，并讨论如何将其应用到本文的问题中。
如图2所示，RE模型通过三个步骤确定了软件名称和版本之间的正确关系。在第一步中，它对软件名称和版本信息的出现进行编码，然后生成一组位置嵌入来表示当前单词到两个命名实体(例如软件名称和版本) 在同一个句子中的相对距离。具体来说，RE模型首先对上述NER模型生成的实体标签序列进行索引，然后，它在每一个可能的组合中遍历所有软件名称和版本，并基于实体标签的索引使用单热编码对组合进行编码。在一次热编码完成后，RE模型进一步使用单词嵌入方法将一次热编码转换为两个表示位置嵌入的单个向量(见图2)。
在第二步中，与NER模型相似，RE模型使用相同的技术对文本进行编码并将文本序列转换为向量序列。然后，在单词序列向量的后面，RE模型将每组位置嵌入单独地追加。例如，在图2中，NER模型确定了两个软件名称和两个版本，它们形成了四种不同的组合(所有配对软件名称和版本的可能方式)。对于每个组合，RE模型将位置嵌入向量附加到单词嵌入向量中，形成最后一步进行分类的输入。在本例中，产生了四个向量作为输入，每个向量表示一个可能的软件名称-版本对。
最后，RE模型将每个向量序列作为基于注意力的神经网络的输入，并输出一个向量表示序列的新表示。然后，如图2所示，RE模型将输出向量作为另一个注意网络的输入，通过该注意网络，RE模型预测哪个名称-版本配对最有可能捕捉到软件名称与其对应版本之间的关系。继续图2中的示例，seq 1和4与一个正输出相关联，这表示Microsoft VBScript 5.7和5.8与Internet Explorer 9到11之间的合法配对关系。
3 系统实现
3.1 系统评价
本文使用ground-truth数据集来评估VIEM的性能。首先，我们使用内存损坏漏洞数据集来评估系统性能并微调参数。然后，我们使用其他12个类别的数据来检验模型的可转移性。
3.1.1 评价NER和RE
为了评估NER和RE模型，我们使用内存损坏漏洞报告及其CVE摘要(3448个CVE ID)。
NER模型：给定一个文档，NER模型提取出易受攻击的软件名称和版本。首先在单词层面进行提取，然后将连续的带有SN或SV标签的单词分组为软件名称或软件版本。我们使用三个评价指标对词级提取进行评价:(1)精度表示相关实体相对于提取实体的比例;(2)召回率表示提取的相关实体占相关实体总数的比例;(3)总体精度表示正确预测占所有预测的比例。分别计算了软件名称提取和版本提取的查全率和查全率。
本文以8:1:1的比例分割了ground-truth数据集，用于训练、验证和测试。本文使用一组默认参数，稍后将显示本文的性能对这些参数不敏感。这里，预先训练过的单词嵌入的维数是300(字符嵌入为50)。为了对齐输入序列，我们只考虑每个句子的前200个单词。根据经验，我们观察到绝大多数句子都少于200个单词。除了单词级嵌入权值W(使用FastText方法)外，NER模型中的所有层都是共同训练的。默认批处理大小为50,epochs数为20。我们使用先进的随机梯度下降方法Adam作为优化器，它可以自适应调整学习率，以减少收敛时间，还采用了dropout来防止过拟合。
我们通过随机分割数据集来重复实验10次，用于训练、验证和测试。表1显示了平均精度、召回率和准确度。我们的NER模型是高度准确的，即使没有应用gazetteer(即字典)。提取漏洞软件名称和版本的精度为0.978，召回率为0.991。此外，我们还证明了gazetteer能够如预期的那样提高软件名称提取的性能。应用gazetteer后，总体精度高达0.9969。这种高精度的NER是可取的，因为任何错误都可能传播到以后的RE模型。
通过结果观察到，本文的NER模型确实提取了从未出现在训练数据集中的软件名称(和版本)。例如，将NER应用到测试数据集中后，我们提取了205个唯一的软件名称，其中47个(22.9%)没有出现在训练数据集中。这证实了NER模型已经学习了可归纳的模式和指示器来提取相关的实体，这使得模型能够提取以前未见过的软件名称。
RE模型：接下来我们进行实验，首先检查RE本身的性能，然后通过结合NER和RE来评估端到端的性能。与之前一样，我们以8:1:1的比例分割数据集进行训练、验证和测试。这里，我们将预先训练过的单词嵌入的维数设置为50。位置嵌入件尺寸为10。默认批处理大小为80,epochs数为200，将双向层的数量设置为2。与NER模型一样，本文的RE模型也使用了预先训练好的单词嵌入权值W。位置嵌入权重与模型中的其他参数一起随机初始化和训练。
首先，我们进行了一个实验来评估单独的RE模型。更具体地说，我们假设已经正确地提取了命名的实体，并且我们仅使用RE测试了“配对”过程。这假设早期的NER模型具有完美的性能。如表2所示，RE的精度也很高。该模型的精度为0.9955，召回率为0.9825。
其次，我们评估端到端的性能，并使用NER的输出作为RE模型的输入。如表2所示，精度从0.9916下降到0.9704(无gazetteer)和0.9764(有gazetteer)。退化主要发生在精度上，进一步检查发现，NER模型错误地提取了一些非软件名称的实体，成为RE的错误输入，影响了分类精度。此外，在NER和RE合并后，gazetteer的优势也出现了，精度从0.9248提高到0.9411(但不会影响召回)。结果表明，该模型能够准确地从非结构化文本中提取出易受攻击的软件名称及其对应版本。
基线比较：为了将VIEM的性能与其他基线进行比较，我们对同一数据集应用其他方法。首先，对于NER模型，我们测试了SemFuzz。SemFuzz使用手工构建的正则表达式从漏洞报告中提取出易受攻击的软件版本。我们发现SemFuzz达到了合理的精度(0.8225)，但是召回率很低(0.371)。作为比较，VIEM的精度和召回率都在0.978以上。其次，对于端到端的评估，本文使用现成的NLP工具包实现了一个基线系统。更具体地说，我们使用条件随机场序列模型提取命名实体，该模型使用了斯坦福的词性标签和其他语法特征。然后，我们将提取的实体输入一个基线RE模型，该模型使用斯坦福神经依赖解析的特征进行训练。端到端计算返回的精度为0.8436，收回率为0.8851。结果证实了VIEM具有更好的性能，至少对于我们的应用程序而言(即处理漏洞报告)。
模型参数：以上结果基于一组默认参数，这些参数已经根据验证数据集进行了微调。为了验证我们的参数选择，我们一次更改一个参数并查看它对模型的影响。我们对所有参数(例如word embedding dimensions, batch sizes, network layer，epochs)执行这个测试，事实本文的模型对参数设置不是很敏感。
本文预先训练了我们自己的词嵌入层在语料库建立从所有非结构化报告在我们的数据集。我们已经测试了两个最先进的方法:Word2vec和FastText。我们选择FastText，因为它的精确度稍高(提高1%)。图4显示了不同嵌入尺寸下FastText嵌入的总体精度。结果表明，性能对该参数不敏感(只要配置在合理范围内)。在训练RE和NER时，需要对神经网络的批处理大小、epoch数、双向层数和位置嵌入维数进行设置。同样，我们将RE和NER参数分别交换。为简便起见，我们仅在图5-图7中显示了RE模型的结果。
3.1.2 迁移学习的评价
最后，我们检查了对其他漏洞类别的模型的概括性。首先，为了建立一个基线，我们直接将用内存损坏数据集训练的模型应用到其他漏洞类别。其次，我们应用转移学习，并为每一个其他的漏洞类别再训练一个专门的模型，本文将这两个实验分别称为“迁移前”和“迁移后”。
当每个漏洞类别没有足够的标记数据时，迁移学习是有用的。在这种情况下，我们可以使用内存损坏分类器作为教师模型。利用每个类别的数据对教师模型的最后一层进行微调，可以训练出一系列特定类别的分类器。更具体地说，本文使用来自内存损坏类别(3,448个CVE id)的所有真实数据来训练一个教师模型。然后利用教师模型对12个漏洞类别分别训练一个新模型。给定一个目标类别(例如SQL注入)，我们以1:1的比例分割它的ground-truth数据，用于训练和测试。训练数据将应用于预训练的教师模型，以微调最后的隐藏层。这样，就构造了一个专门针对“SQL注入”报告进行优化的新模型。最后，我们将此新模型应用于测试数据来评估其性能。
结果如表3和表4所示。我们发现，在迁移学习之前，NER模型已经是高度可推广的，迁移学习在准确性上只带来了很小的提高(从0.987到0.994)。其次，当直接应用到其他类别时，RE模型(针对内存损坏数据进行训练)的性能有明显下降，总体精度只有0.876。通过迁移学习，准确率可以提高到0.9044。
为了证实迁移学习是必要的，本文运行了一个额外的实验，通过使用来自13个类别的所有的ground-truth数据集来训练一个单一的模型。发现端到端的准确率只有0.883，低于迁移学习的准确率。某些类别的准确性明显下降(例如CSRF的0.789)。这说明不同类别的漏洞报告确实具有不同的特点，值得建立自己的模型。
3.2 测量信息不一致
在本节中，我们将VIEM应用于整个数据集，以检查信息的一致性。特别是，我们试图检查结构NVD条目与CVE条目以及引用的漏洞报告的匹配程度。在下面，本文首先定义度量来量化一致性，然后对ground-truth数据集进行初步测量，估计VIEM引入的测量误差。最后，本文将VIEM应用到完整的数据集，以检查随着时间的推移，不同的漏洞类型之间的一致性水平是如何不同的。
3.2.1 测量方法
NVD数据库以其完整的结构化和标准化的数据条目，使自动化信息处理和智能挖掘成为可能。然而，考虑到NVD条目是通过手工创建和更新的，本文关注它的数据质量，特别是它跟上最新发现的易受攻击的软件和版本的能力。为此，我们试图衡量NVD条目与其他信息源(包括CVE摘要和外部报告)的一致性。
匹配的软件名称：给定CVE ID，我们首先匹配NVD数据库中列出的易受攻击的软件名称，以及那些来自非结构化文本的名称。令C ={ (N_1,V_1)， (N_2,V_2)，…， (N_n,V_n)}是从NVD中提取的漏洞软件名称版本元组，Cprime= {(N_1, V_1prime)， (N_2, V_2prime)，…(N_m, V_mprime)}从外部文本中提取的名称版本元组。在本文的数据集中，大约20%的CVE id与多个软件名称相关联。在本文中，我们只关注NVD和外部报告之间匹配的软件名称。我们的匹配方法可以灵活地处理相同软件名称的略微不同的格式。如果匹配的单词数量大于或等于未匹配的单词数量，则将两个名称视为匹配。例如，“Microsoft Internet Explorer”和“Internet Explorer”匹配是因为匹配的单词比未匹配的单词多。
测量版本一致性：给定一个软件名称N_1，我们试图度量报告版本V_1和V_1prime的一致性。本文研究了两种类型的匹配。首先，严格匹配是指V_1和V_1prime完全匹配(V_1 = V_1prime)。其次，松散匹配意味着一个版本是另一个版本的超集(V_1in V_1prime或V_1
i V_1prime)。注意，松散匹配的情况包含严格匹配的情况。除了松散匹配之外，这意味着V_1和V_1prime各自都包含了一些对方没有报告的漏洞版本(即:相互矛盾的信息)。
要执行上述匹配过程，需要将V_1和V_1prime的文本格式转换为可比较的格式，在非结构化文本中，软件版本要么描述为一组离散值(例如，“版本1.1和1.4”)，要么描述为连续范围(例如，“版本1.4和更早版本”)。对于像“版本1.4和更早版本”这样的描述，我们首先将文本表示转换为数学范围。转换基于我们预先准备的字典。例如，我们将“... and earlier”转换为“le”。这意味着“1.4及更早版本”将被转换为“le1.4”。然后，对于基于“范围”的版本描述，我们查找NIST维护的CPE目录，以获得给定软件的所有可用版本的列表。这允许我们将“范围”描述(“≤1.4”)转换为一组离散值{1.0,1.1,1.2,1.3,1.4}。转换后，我们可以确定V_1和V_1prime是否匹配。
如果一个CVE ID有一个以上的软件名称(k >1)，我们采用保守的方法计算匹配结果。只有所有的k个软件版本对都符合严格匹配，我们才会认为报告是“严格匹配”。类似地，只有当所有对都被限定为松散匹配时，我们才会将报表标记为“松散匹配”报表。
3.2.2 ground- truth测量
根据上述方法，我们首先使用ground- truth数据集估计测量误差。更具体地说，给定所有的ground- truth漏洞报告和CVE总结，本文使用的最佳性能模型(带有gazetteer和迁移学习)来提取漏洞软件名称和版本元组。然后对提取的条目进行严格匹配和松散匹配，并将匹配率与ground-truth匹配率进行比较。结果如表5所示。
本文证明了VIEM在实际匹配率上引入了一个小的偏差。对于内存损坏漏洞，VIEM模型表明87.3%的报告松散地匹配NVD条目，只有45.9%的报告严格匹配。结果与ground-truth非常接近，匹配率分别为85.3%和46.3%。对于其余12个漏洞类别，VIEM模型表明松散匹配率为93.3%，严格匹配率为61%。同样，结果与ground-truth非常相似(93.7%和62%)。与ground-truth的偏差在1.9%以内。结果表明，VIEM模型是足够准确的测量。
3.2.3 大规模实证测量
在以上验证之后，我们使用完整的ground-truth数据集来训练VIEM，并将模型应用于其余未标记和非结构化文本(漏洞报告和CVE摘要)。然后计算NVD版本与外部信息源(CVE网站和5个外部网站)的匹配率。
结果概述：在所有78,296个CVE ID中，我们总共提取了18,764个独特的漏洞软件名称。这些易受攻击的软件名称对应于CVE摘要中的154,569对软件名称版本对，来自外部漏洞报告的235,350对软件名称版本对，以及来自NVD数据库的165,822对软件名称版本对。在匹配NVD和其他源之间的软件名称之后，还剩下389,476对用于检查一致性。
在名称版本对水平上，我们发现305,037对严格匹配(78.32%)。这意味着来自NVD的大约22%的名称版本对与外部信息源不匹配。如果放宽匹配条件，我们找到361,005对松散匹配(93.49%)。
然后我们在报表级别聚合匹配结果。虽然松散匹配率仍然很高(90.05%)，但严格匹配率明显降低。只有59.82%的漏洞报告/CVE总结严格匹配NVD条目。这是因为严格匹配的报告需要所有提取的版本与NVD的版本匹配。为了理解一致性水平如何在不同方面发生变化，接下来将分析结果以进行更深入的分析。
信息来源网站：图9显示了NVD条目与5个信息网站和CVE网站之间的匹配率。CVE的匹配率相对较高(严格匹配率约为70%)。这并不奇怪，因为NVD被声称是与CVE feed同步的。更有趣的是，我们发现ExploitDB对NVD的匹配率甚至更高。在进一步检查了NVD条目和其他网站上相应报告的发布日期，发现绝大多数(95.8%)的开发数据库报告是在创建NVD条目之后发布的。然而，ExploitDB有81%的报告比其他4个网站的报告发布得更早，这可能有助于吸引NVD团队的注意来进行更新。
过多或过少的信息：对于松散匹配的版本，就外部报告而言，NVD条目可能涵盖过多或过少了易受攻击的软件版本。CVE-2005-4134的示例如图8所示。与CVE 摘要相比，NVD多于Mozilla Firefox和Netscape Navigator的漏洞版本，因为NVD列出的漏洞版本比CVE多。相反，对于K-Meleon, NVD有较少的漏洞软件版本范围。
图10显示了松散匹配的NVD条目中超出和缺少的百分比。“严格匹配”对不包括在这个分析中。考虑到NVD应该搜索不同的源来保持条目的更新，所以NVD条目覆盖更容易受攻击的版本是合理的。即使我们把5个网站和CVE的易受攻击的版本联合起来，NVD仍然涵盖了更多的版本。更有趣的是，与每个外部信息源相比，NVD少申报了条目。这表明NVD要么延迟更新条目，要么无法跟踪外部信息。只有很小一部分NVD条目包含过多或过少版本(参见图8中的示例)。
冲突案例的例子：接下来，本文检查了冲突的对，并观察到不匹配的一个常见原因是拼写错误。例如，在CVE-2008-1862下，软件ExBB Italia在CVE和ExploitDB上列出的版本都是0.22和更早的版本。然而，NVD版本略有不同，“到(包括)0.2.2”。另一个例子是CVE-2010-0364，其中来自NVD和CVE 摘要的软件版本对于Videolan VLC media player都是0.8.6。但是，SecurityFocus上的信息有一个明显的错误，即0.6.8。
在其他情况下，不清楚谁的信息是正确的。例如，有时引用的漏洞报告提供了比CVE摘要更详细的信息。例如，在CVE-2012-1173中，在NVD中libtiff的漏洞版本是3.9.4，但SecurityTracker声称漏洞版本应该是3.9.5。在CVE-2000-0773下，根据NVD，软件Bajie HTTP web服务器在1.0版本中存在漏洞，然而，CVE列出了0.30a版本和SecurityFocus列出了0.90、0.92、0.93。在纯文本层面上无法确定矛盾信息的正确性，但我们认为，这种测量结果的价值在于指出需要验证和纠正的情况。
时间的一致性：图11显示了NVD和其他6个信息源(CVE和5个报告网站)之间的一致性水平随着时间的推移而降低。严格匹配率随时间有一定的波动，但仍有减小的趋势。我们对这两个匹配率进行线性回归，发现两者都有一个负斜率(分别为-0.0015和-0.0056)。结果表明，在过去的20年里，整体的一致性随着时间的推移而下降。然而，如果我们仔细观察最近三年(2016年至2018年)，一致性水平开始上升，这是一个好迹象。
当我们比较CVE和5个外部网站的一致性时，图12显示了不同的趋势。CVE与外部位点的一致性水平相对稳定，有轻微上升趋势。我们对这两个匹配率进行线性回归，得到一个正斜率(分别为0.0006和0.0028)。这表明CVE网站在总结漏洞版本方面做得越来越好。
类型的漏洞:如图13所示，我们根据漏洞类别对结果进行分解。虽然松散匹配率仍然相似(约90%)，但它们在严格匹配率上有明显差异。例如，“SQL注入”和“文件包含”具有最高的严格匹配率(超过75%)，但是像“内存损坏”这样的类别具有更低的严格匹配率(48%)。进一步的手动检查表明，内存损坏漏洞通常比文件包含或SQL注入下的漏洞更复杂，因此需要更长的时间来重新生成和验证。因此，随着时间的推移，NVD丢失新发现的漏洞版本的情况并不少见。
推断不一致的原因:最后，我们试图通过分析NVD条目创建/更新时间与外部报告的提交时间来推断不一致的原因。更具体地说，NVD为每个CVE ID维护一个“更改历史”，这允许我们提取条目创建时间，以及添加/删除新软件版本的时间。然后我们可以将其与5个网站相应报告的发布时间进行比较。为了进行分析，我们随机选取了5000个CVE ID，这些ID在NVD中的漏洞版本与5个网站的漏洞版本不一致。
我们发现，66.3%的NVD条目自首次创建以来从未更新过。这包括5.8%的NVD条目，这些条目是在5个网站发布报告之前创建的。例如，对于CVE-2006-6516, NVD声称KDPics 1.16在2006年是有漏洞的。2010年晚些时候，SecurityFocus报告说版本1.11和1.16都存在漏洞，NVD直到今天才添加了新的1.11版本。对于更大一部分(60.5%)的NVD条目，它们是在至少一个外部报告已经可用时创建的。一个例子是CVE-2016-6855，因为在2016年8月，ExploitDB声称Gnome 3.10.2的是有漏洞的。一个月后，创建了不包括3.10.2版本的NVD条目。从那时起，没有任何更新。
对于其余的33.7%的NVD条目，他们在创建条目后至少对漏洞版本进行了一次更新。我们比较了5个网站的最新更新时间和外部报告发布时间。我们发现所有的NVD条目都是在一些外部报告发布后进行最新更新的。总的来说，这些结果表明NVD团队没有有效地包括来自外部报告的漏洞版本，尽管这些报告在创建/更新条目时就已经可用了。结果反过来反映了自动监控不同在线源和提取漏洞版本的需求，以更主动的版本测试和条目更新。
3.3 案例研究
为了演示我们的不一致性度量的现实意义，我们执行案例研究。我们从数据集中的不匹配案例中随机选择了7个真实世界的漏洞。然后我们尝试在不同版本下手动复制相关软件的漏洞。这些漏洞与7个不同的CVE id相关，总共覆盖了47个漏洞报告。请注意，在案例研究中，本文不仅包含了来自5个网站的CVE摘要和报告，还考虑了这些CVE id参考列表中的所有其他来源网站。对于这些报告中提到的软件，本文详尽地收集了这些软件程序的所有版本，总共得到了185个版本的软件。我们在表6中列出了每个软件的唯一版本的数量。
使用收集到的软件，检查每个版本中的漏洞，组成了一个由3名安全研究人员组成的团队，手动分析这些软件程序的源代码，并通过手工制作PoC(概念验证)输入动态验证报告的漏洞。
真正易受攻击的版本列在表6的“ground-truth”列中。总的来说，在185个软件版本中，本文确认有64个版本存在漏洞。其中12个真正的漏洞版本是我们第一次发现的，它们在现有的漏洞报告或CVE/NVD条目中从未被提及。
观察1 错误的信息确认：通过与ground-truth漏洞版本的比较，本文确认了包括CVE和NVD在内的大多数信息源要么漏掉了真正的漏洞版本，要么错误地包含了非漏洞版本。有普遍和例行的夸大和低估，考虑到许多系统管理员严重依赖漏洞报告中的信息来评估他们的系统的风险，并决定他们是否需要升级他们的软件，“低估”问题可能使漏洞的软件系统没有修补，这是一个很大的担忧。另一方面，这种夸大可能会浪费安全分析师在执行风险评估方面的大量手工工作。
观察2 多数投票的好处和限制：鉴于这一弱点，如果我们在不同的信息来源中采取多数投票，我们可以减少“夸大”的问题，然而，这会放大“低估”的问题。结果表明，系统管理员和安全分析人员不能简单地利用多数投票机制来确定他们的软件系统的风险。
观察3 机构的利益和限制：如果我们取所有声称的易受攻击版本的并集，我们可以看到得到的多数来源的易受攻击版本比真正的易受攻击版本覆盖得更好。这说明了广泛搜索不同的在线信息源和自动提取新发现的漏洞版本的好处。在承认其好处的同时，我们也注意到机构的做法并不完美。首先，联合集很容易引入夸大的版本，在表6中的所有漏洞中，我们发现了15个外部报告(不包括NVD/CVE条目)，在这些报告中，声称的漏洞版本根据我们的测试被证明是不存在漏洞的。其次，联合集有时不能覆盖真正易受攻击的版本。如表6所示，我们确认了CVE-2009-5018、CVE-2016-8676和CVE-2016-9556的12个新的漏洞版本。通过对给定软件的所有可用版本进行全面测试，我们首次发现了这些易受攻击的版本。在实践中，我们的方法(测试所有版本)是不可伸缩的，因为需要大量的手工工作。完全自动化漏洞验证过程仍然是一个公开的挑战。总的来说，联合方法至少有助于缩小测试空间，并提高真正存在漏洞的版本的覆盖率。
4 复现环境及过程
4.1 环境配置
作者在论文中给出了VIEM系统的开源代码，代码网址为https://github.com/pinkymm/inconsistency_detection。
4.1.1 系统开发语言及平台
VIEM系统是基于python语言开发的，用到的版本为python3。
本次复现使用的平台是Pycharm以及Anaconda，下面简单介绍这两个软件：
PyCharm：PyCharm是一种Python IDE，带有一整套可以帮助用户在使用Python语言开发时提高其效率的工具，比如调试、语法高亮、Project管理、代码跳转、智能提示、自动完成、单元测试、版本控制。此外，该IDE提供了一些高级功能，以用于支持Django框架下的专业Web开发。
Anaconda：Anaconda就是可以便捷获取包且对包能够进行管理，同时对环境可以统一管理的发行版本。Anaconda包含了conda、Python在内的超过180个科学包及其依赖项。
4.1.2 实验依赖库
下面列出本系统需要安装如下几个库以及对应的版本：
| 包名称 | 版本 |
|---|---|
| bs4 | 0.0.1 |
| lxml | 4.1.0 |
| nltk | 3.2.4 |
| tqdm | 4.23.0 |
| numpy | 1.14.3 |
| requests | 2.18.4 |
| Lasagne | 0.2.dev1 |
| tensorflow | 1.11.0 |
| Theano | 1.0.1+2.gcd195ed28 |
4.2 实验过程
1.通过anaconda prompt创建一个python3的环境并安装本系统需要的依赖库，用到的指令如下：
>conda create -n my_env_py3 numpy==1.14.3 #创建环境
>conda create install package(包名称)==version(版本号) #安装库
其中在安装Theano 和Lasagne这两个包时遇到了很大的阻碍，虽说高版本一般可向下兼容，但是对于这个实验却不行，清华源里面并没有这两个包的对应版本，我到处寻找这两个包的线索，终于在github中找到了Lasagne对应的0.2.dev1版本，下载网址为https://github.com/Lasagne/Lasagne。Theano1.0.1后面加的数据我没搞明白什么意思，不过这个并不影响。
安装完所需依赖库之后截图如下：
2.通过项目中给出的README.MD文件可以知道：
作者手动标记的数据集包含5193个CVE ID的CVE摘要和非结构化漏洞报告，包括ExploitDB、SecurityFocus、Openwall。数据集涵盖了cvedetails中提供的所有的13类漏洞，并且包括NER数据和RE数据。
NER数据集格式：报告中的每个单词都被指定三个标签:易受攻击软件名称(‘SN’)、易受攻击软件版本(‘SV’)或其他标签(‘O’)。每一行都是一个单词以及紧跟着的标签，实例截图如下：
RE数据集格式：通过检查同一句子中所有可能的实体对来对SN和SV实体进行配对。例如有2个软件(Apple Watch和WatchOS)和2个版本(3和4.0.1)这4个实体。它们可以两两组合为4种不同的方式。通过将这些组合视为4对不同的实体，然后为每个组合分配一个二进制标签，标签可以是“Y”和“N”。每行包含头实体和尾实体的索引、标签和说明，示例截图如下：
3.在NIST机构的NVD列表中下载（网址https://nvd.nist.gov/products/cpe）最新版本的official-cpe-dictionary_v2.3.xml，然后通过以下指令来生成字典，其中字典的键为软件名称，值为对应的软件版本，截图如下：
python data_collection / cpe_dic_parser.py
4.通过如下指令生成包含所有软件名称的存档raw_cvedetails_software_list和clean_cvedetails_software_list，截图如下：
python data_collection / obtain_cvedetails_products.py
5.通过如下指令来从cve漏洞网站来抓取漏洞报告，由于源代码中需要爬取该网址所有漏洞报告，实践过程中总是会出现连接超时情况，所以我将它的抓取数目设置少了，漏洞网址为：https://www.cvedetails.com，过程截图如下：
python data_collection/cvedetails_crawler.py
6.在准备好上述的基本的文件后，就可以训练NER模型了，这里以memc（内存损坏漏洞）为参来进行训练，指令以及过程截图如下：
python ner_model/train_NER.py --category=0
7.整个过程出现了好多的问题，我通过各种上网查阅，修改有问题的代码，最终还是会有问题，最后才发现是作者在给出的代码中少了好几个文件，github上有一个外国小哥提出了这个问题，但是作者并没有给出具体的解决措施，我已经联系了这篇论文的第一作者和其他参与者，若是得到他们的回信，我会将最后的结果补齐。下面为所提出问题的截图：
5 课程总结与实践总结
5.1 实践总结
先来说说对这篇论文的总结：本文主要设计并开发了一个自动化工具VIEM，用于对结构化NVD数据库与非结构化CVE摘要和外部漏洞报告之间的信息一致性进行大规模测量。论文的结果表明，不一致的信息是高度普遍的，通过对案例研究证实，NVD/CVE数据库和第三方报告要么漏掉了真正易受攻击的软件版本，要么错误地包含了非易受攻击的版本。然而错误的信息可能使漏洞软件得不到修补，或者增加安全分析人员进行风险评估的手工工作。所以说本文的研究价值还是蛮高的。
再说说这个过程中我的感受：通过本次实践，让我最大的一点感触就是，复现好难好难啊，在这个过程中会有一大堆的未知的错误等着你，我第一篇选择的论文由于环境问题经过无数次的调整最终无果，然后换成了这篇论文，结果在环境的配置和代码的调试上又是多少个日夜的工作，说多了都是泪。不过虽说过程是艰辛的，但结果还是不错的，尤其是过程中时而喜时而悲的感觉，让我的心志也增强了，相信对我之后课题的研究会有很大的帮助。
5.2 课程总结
受到疫情的影响，本学期所有的课程都是在线上进行，这对老师和同学都是一个考验，但是我们很好的坚持了下来，虽然不能像线下教学那样在课堂上与老师当面沟通，但是对于教学效果来说并不会有太大影响，相反的，线上教学的方式更加的灵活，电子平台的教学资源更加丰富。作为本门课程的课代表，我一直积极与老师沟通，将老师布置的任务及时转达给同学们，配合老师开展本学期的教学任务。虽然说老师对我们的要求比较严格，教学任务也比较重，但是我确实从中学到不少知识，提升了我的动手能力，这对我将来的课题研究有着很大的帮助，在这里我衷心的谢谢老师。
我认为本课程最大的特色就是能大幅度的增强同学们的动手能力。对于课程的建议和意见这点，我认为可以在每章节的学习之前，老师可以对此章节的大纲做一个概述。由于同学们的专业基础各有不同，可能对同样的问题有着不同的观点，所以应该先让基础较薄弱的同学们将基础知识学习的更扎实一点。