The Common Vulnerabilities and Exposures (CVE) turns 21 this year and, just like any 21-year-old, there have been growing pains along the way. There was even a growth spurt.

常见漏洞披露( CVE )今年已满21岁，并且与任何21岁的年轻人一样，一路走来，痛苦不断。 甚至出现了增长。

In the case of CVE, this happened between 2016 and 2017, when the number of vulnerabilities assigned a CVE ID skyrocketed from 6,447 to 14,714.

就CVE而言，这发生在2016年至2017年之间，当时分配CVE ID的漏洞数量从6,447个激增至14,714个。

Why the sudden increase? Let’s step back in time for a moment …

为什么突然增加？ 让我们退后一会儿……

In September 1999, MITRE Corporation published a paper titled The Development of a Common Enumeration of Vulnerabilities and Exposures.

1999年9月，MITRE公司发表了一篇题为《漏洞和暴露的通用枚举的发展 》的论文。

“(We are) building a system that can integrate and manage vulnerability information from different sources, such as network assessment tools, intrusion detection systems, and archives, in a database for supporting enterprise security operations,” stated MITRE.

MITRE表示：“(我们)正在构建一个系统，该系统可以在数据库中集成和管理来自不同来源的漏洞信息，例如网络评估工具，入侵检测系统和档案，以支持企业安全操作。”

MITRE’s desire to establish an independent naming authority stemmed from the fact there were already numerous vulnerability databases, all with differing naming protocols. Not surprisingly, this caused confusion among researchers and vendors because, among other things, they were unable to determine if these databases were referring to the same vulnerability.

MITRE希望建立一个独立的命名机构的原因是，已经存在许多漏洞数据库，而且所有漏洞数据库都具有不同的命名协议。 毫不奇怪，这引起了研究人员和供应商之间的困惑，因为，除其他外，他们无法确定这些数据库是否引用了同一漏洞。

“The goals of having CVE are to … assign a standard, unique name to each vulnerability, and exist independently,” stated MITRE, also realising that “for CVE to have any impact … (it) must be openly available to the public, without restrictions on distribution.”

MITRE表示：“拥有CVE的目标是……为每个漏洞分配一个标准的唯一名称，并独立存在。”他还意识到，“要使CVE产生任何影响……(它)必须向公众公开提供，而不必发行限制。”

MITRE recognised that a public vulnerability database might assist hackers but argued the benefits outweighed the risks. In a pre-social media world (remember, it was 1999), one interesting benefit given was: “Community opinion is shifting towards sharing information …”.

MITRE意识到公共漏洞数据库可能会帮助黑客，但是他认为这样做的好处大于风险。 在前社会媒体世界(记得是1999年)中，一个有趣的好处是：“ 社区舆论正在朝着共享信息的方向…… ”。

When CVE officially came into being (Oct. 1999), it was designed to deal with a maximum of 1,000 vulnerabilities a year. The year after CVE’s arrival the number of vulnerabilities exceeded the 1,000 mark — 1,020 — and, as the years progressed, the quantity of software and hardware … and vulnerabilities … escalated. By 2005 the number of assigned vulnerabilities was a whisker away from 5,000 (4,935). Dealing with this volume was proving an issue for CVE and it began looking at ways to address the expanding vulnerability landscape.

CVE正式成立时(1999年10月)，其设计目的是每年处理最多1,000个漏洞。 CVE到来的第二年，漏洞数量超过了1,000个标记(1,020个标记)，并且随着岁月的流逝，软件和硬件……以及漏洞……的数量不断增加。 到2005年，分配的漏洞数量已从5,000(4,935)减少到了500个。 处理此卷证明是CVE的一个问题，它开始寻找解决扩展的漏洞状况的方法。

候选命名机构 (CANDIDATE NAMING AUTHORITIES)

The September 1999 paper identified a Candidate Naming Authority (CNA) as an entity that could assist identifying and naming vulnerabilities. However, CNAs didn’t necessarily speed up the process. This is because between 1999 and 2005 there was a three-step process to naming (assigning) a vulnerability.

1999年9月的文件将候选人命名机构( CNA )确定为可以帮助识别和命名漏洞的实体。 但是，CNA并不一定加快这一过程。 这是因为在1999年到2005年之间，有一个三步来命名(分配)漏洞。

First a ‘problem’ was identified as a candidate — potential vulnerability — and given the prefix CAN e.g. CAN-1999–0345. This step could be done by a CNA, of which there were 23 in 2005. However, for a candidate to become a published vulnerability, the CVE Board had to discuss, review, and vote on whether a candidate was a vulnerability. This had to be done for every candidate. If the Board agreed, a candidate was given CVE status and the prefix changed accordingly, so CAN-1999–0345 became CVE-1999–0345. The final step, populating the CVE ID on the master, published list, was also done solely by CVE.

首先，将“问题”标识为候选对象(潜在漏洞)，并使用前缀CAN，例如CAN-1999-0345。 此步骤可以由CNA完成，CNA在2005年有23个。但是，要使候选人成为已发布的漏洞，CVE理事会必须讨论，审查并投票决定候选人是否为漏洞。 必须为每个候选人做到这一点。 如果委员会同意，将为候选人提供CVE身份，并且前缀也会相应更改，因此CAN-1999-0345变为CVE-1999-0345。 最后一步，将CVE ID填充到已发布的主列表中，也仅由CVE完成。

As a first step to speeding up the process, in 2005 the board vote was eliminated and all entries were automatically given a CVE ID. However, CNAs could still only identify but not populate the list and the multi-step process system remained in place until 2016, by which time ‘all things internet’ — and the corresponding amount of software/hardware — had continued to increase dramatically. This was matched by a sharp rise in the number of vulnerabilities, the sheer weight of which had once again slowed the process of assigning CVE IDs, resulting in some researchers not receiving a CVE assignment/s.

作为加快这一过程的第一步，在2005年，董事会投票被取消，所有参赛者都自动获得了CVE ID。 但是，CNA仍然只能识别列表而不是填充列表，并且多步处理系统一直保持到2016年，那时“万物互联”以及相应数量的软件/硬件继续急剧增长。 与此对应的是，漏洞数量急剧增加，其严重性再次减慢了分配CVE ID的过程，导致一些研究人员没有收到CVE分配。

This was because, at the time, the CVE program operated to a scope (list) of software types for which it would assign CVEs. This scope was created to focus resources on the most important products and, if a product wasn’t within the scope, CVE didn’t assign and populate the list.

这是因为当时CVE程序在为其分配CVE的软件类型范围(列表)中运行。 创建此范围的目的是将资源集中在最重要的产品上，如果某个产品不在该范围内，则CVE不会分配和填充列表。

变化的风 (THE WINDS OF CHANGE)

“A recent discussion of problems with the CVE system … has led some to wonder about its future,” wrote Linux Weekly News on March 9, 2016. “The problems stem from the difficulty, sometimes impossibility, of getting CVEs assigned for real vulnerabilities. That, in turn, has led some to stop even requesting CVE numbers for vulnerabilities that they find, which further reduces their usefulness.”

“ Linux每周新闻”于2016年3月9日写道：“最近对CVE系统问题的讨论……使人们对它的未来感到疑惑。这些问题源于为真正的漏洞分配CVE的困难，有时甚至是不可能。 相应地，这甚至导致一些人甚至停止要求CVE编号来查找他们发现的漏洞，这进一步降低了其实用性。”

It’s hard to imagine that this was the state of play less than four years ago. But it was. To the point where the online community was beginning to contemplate alternatives, such as OVE IDs: “unique IDs that you may use to refer to software security vulnerabilities (one ID per vulnerability), much like we use CVE IDs”, and the Open Source Vulnerability Database (OSVDB): “OSVDB’s goal is to provide accurate and unbiased information about security vulnerabilities in computerized equipment.”

很难想象这是不到四年前的状态。 但是确实如此。 到了在线社区开始考虑替代方案的地步，例如OVE ID ：“您可以用来引用软件安全漏洞的唯一ID(每个漏洞一个ID)，就像我们使用CVE ID一样”，以及开放源代码漏洞数据库( OSVDB )：“ OSVDB的目标是提供有关计算机设备安全漏洞的准确无偏的信息。”

Thousands of vulnerabilites were going un-assigned and, therefore, unpatched. Additional change was needed.

成千上万的脆弱性未分配，因此未修补。 需要进行其他更改。

On March 21, 2016, CVE wrote: “The recent explosion of Internet-enabled devices — known as the Internet of Things — as well as the propagation of software-based functionality in systems has led to a huge increase in the number of CVE requests … We did not anticipate this rate of growth … The result has been some of the delay in CVE assignments that the software security community has recently witnessed.”

CVE在 2016年3月21日写道 ：“最近启用Internet的设备(称为物联网)的爆炸式增长，以及系统中基于软件的功能的传播，导致CVE请求数量大幅增加。 ……我们没有预料到这种增长速度…………结果是软件安全社区最近目睹了CVE分配的某些延误。”

A few months later (June 2016), the Distributed Weakness Filing system (DWF) launched. As the name suggests, the DWF distributed the task of assigning CVE IDs and gave control of cataloguing vulnerabilities to, among others, independent experts, software vendors, and academic institutions.

几个月后(2016年6月)，分布式弱点归档系统( DWF )启动。 顾名思义，DWF将分配CVE ID的任务分配给了独立专家，软件供应商和学术机构，其中包括对编目漏洞的控制权。

“Rather than having to submit security reports through a single funnel, anyone within the community can work through a more streamlined reporting mechanism and receive a DWF number,” said Kurt Seifried, a security researcher at Red Hat, who built and launched the DWF (which lasted nearly three years, shutting down in March 2019).

红帽公司安全研究人员库尔特·塞弗里德(Kurt Seifried)表示：“社区中的任何人都不必通过单个渠道提交安全报告，而是可以通过更简化的报告机制来工作，并获得DWF编号。”历时近三年，于2019年3月关闭 )。

While the DWF eased the burden for CVE, it — CVE — already had plans afoot to improve the system in place.

DWF减轻了CVE的负担，但它-CVE-已经制定了计划以改进现有系统。

“By the time 2016 came around, CVE was wanting to not only introduce new CNAs, but implement process improvements,” said Chris Levendis, the MITRE CVE Project Lead, while speaking with SecAlerts.

MITER CVE项目负责人Chris Levendis在与SecAlerts交谈时说：“到2016年到来之时，CVE不仅希望引入新的CNA，还希望实施流程改进。”

One of these improvements was the new-look CNA program, with CNA now standing for “CVE Numbering Authority”.

这些改进之一是外观焕然一新的CNA计划 ，现在CNA代表“ CVE编号颁发机构”。

Whereas ‘old’ CNAs (Candidate Naming Authorities) could only identify a potential vulnerability — candidate — and name it with the CAN prefix, the new CNAs could do what only CVE had been tasked with doing i.e. assigning CVE IDs. Additionally, CVE did away with scope restrictions on what types of vulnerabilities it would publish.

“旧的” CNA(候选命名机构)只能识别一个潜在的漏洞(候选者)，并用CAN前缀来命名，而新的CNA可以完成仅CVE所要执行的任务，即分配CVE ID。 此外，CVE取消了将发布何种类型的漏洞的范围限制。

Participation in the CNA program was (and still is) voluntary and organisations must provide CVE IDs for free. They must also have a “public vulnerability disclosure policy” and a “public source for new vulnerability disclosures.” If there are any naming disputes, MITRE is the primary CNA and the “CNA of last resort”.

参与CNA计划是(现在仍然)是自愿的，组织必须免费提供CVE ID。 他们还必须具有“公共漏洞披露政策”和“新漏洞披露的公共来源”。 如有任何命名争议，MITRE是主要的CNA和“不得已的CNA”。

现在就知道的CVE (CVE AS WE NOW KNOW IT)

Allowing CNAs to assign CVE IDs, and eliminating scope restrictions, worked, and this resulted in the growth spurt (6,447 to 14,714) between 2016 and 2017.

允许CNA分配CVE ID并消除范围限制的做法奏效了，这导致2016年至2017年间增长突增 (从6,447到14,714)。

“Before the introduction of CVE Numbering Authorities in 2016, CVE populated 100% of CVE entries,” said Levendis. “Now the ratio is 60–40 in favour of CNAs. CVE continues to modernize the rules and underlying technologies to make it easier for CNAs to publish CVEs and it’s intended that, over time, CNAs will populate all entries.”

“在2016年引入CVE编号颁发机构之前，CVE占100％的CVE条目，” Levendis说。 “现在，支持CNA的比例为60-40。 CVE继续对规则和基础技术进行现代化改造，以使CNA可以更轻松地发布CVE，并打算随着时间的推移，CNA将填充所有条目。”

The list of CNAs grows constantly and, as of July 20, 2020, there were 132 organizations — including Google, Apple, Microsoft, Adobe, IBM, Cisco and Red Hat — in 22 countries.

CNA的列表不断增加，截至2020年7月20日，在22个国家/地区拥有132个组织 -包括Google，Apple，Microsoft，Adobe，IBM，Cisco和Red Hat。

Publishing times for CVEs are typically down to days or even hours. Where there is variability in publishing times, it is more often due to human factors rather than the CVE operational model.

CVE的发布时间通常减少到几天甚至几小时。 如果发布时间存在差异，则更多的原因是人为因素而不是CVE操作模型。

For example, a vulnerability researcher working with a vendor might take time to validate the CVE in order to make sure it is ‘legitimate’. Or it could be something even simpler.

例如，与供应商合作的漏洞研究人员可能需要花费一些时间来验证CVE，以确保它是“合法的”。 或者它可能更简单。

“A researcher might collect a CVE ID for a vulnerability but move on to another project before coming back to the vulnerability,” says Levendis. “CVE discourages this but it happens.”

“研究人员可能会收集漏洞的CVE ID，但在回到漏洞之前，请继续进行另一个项目，” Levendis说。 “ CVE不鼓励这样做，但确实发生了。”

CVE has come a long way in its relatively short lifetime. From 894 assigned CVE IDs in 1999 to a high (so far) of 16,556 in 2018, CVE, like any 21yo, continues to change with the times.

CVE在相对较短的生命周期中已经取得了长足的进步。 从1999年的894个分配的CVE ID到2018年的最高(到目前为止)16556个，CVE与任何21yo一样，都随着时代的发展而不断变化。

“CVE isn’t just about MITRE,” concludes Levendis. “It’s a public-private partnership that grows every day.”

莱文迪斯总结说：“ CVE不仅仅与MITRE有关。” “这是每天都在增长的公私合作伙伴关系。”