Resurrecting DWF

Five years ago, we looked at an effort to assist in the assignment of Common Vulnerabilities and Exposures (CVE) IDs, especially for open-source projects. Developers in the free-software world have often found it difficult to obtain CVE IDs for the vulnerabilities that they find. The Distributed Weakness Filing (DWF) project was meant to reduce the friction in the CVE-assignment process, but it never really got off the ground. In a blog post, Josh Bressers said that DWF was hampered by trying to follow the rules for CVEs. That has led to a plan to restart DWF, but this time without the "yoke of legacy CVE".

A bit of history

The CVE system was started in 1999 as a way to track and provide identification numbers for vulnerabilities. It is far easier and more robust to talk about CVE-xxxx-yyyy, rather than "that buffer overflow in the xyzzy project", especially when "that buffer overflow" might refer to any of several (or more) vulnerabilities. CVE IDs provide a specificity that was largely missing prior to their introduction; these days, of course, the highest profile bugs also have catchy names, web sites, logos, stickers, and branded shot glasses.

By the time DWF was introduced in 2016, there were lots of complaints about problems with the CVE system, though there was no real consensus on what should be done to fix it. There were a number of suggestions for ways to improve the CVE system; one relatively concrete approach was DWF, which was announced by Kurt Seifried:

I have increasingly noticed problems with Mitre's handling of the CVE database. This has come to a head now that I have multiple, confirmed, public reports of security researchers being unable to get CVE numbers assigned to them in a timely manner, if at all. As such the solution is simple:

We need a distributed, scale out method for assigning vulnerability identifiers that is as compatible with the existing CVE system as possible. Not just in terms of format but in terms of process and usage. As such I took on the task, creating the DWF system and getting a number of other people involved (Larry Cashdollar, Zachary Wikholm, Josh Bressers, etc.). My goal is to create a simple system for assigning vulnerability identifiers that relies on the community and not a single entity or organization. Additionally I want to reduce the time and effort needed to get identifiers, something best achieved by pushing assigning out to as close to the vulnerability discover/handling as possible.

The complaints eventually led the CVE maintainers to change the process for requesting (and receiving) a CVE ID. Before the change announcement, projects could request a CVE by posting to the oss-security mailing list; a CVE-request web form was set up for projects to use instead.

Even today, it is not hard to find examples of CVE requests going unanswered for two weeks or more. While that may be irritating and is definitely sub-optimal, Bresser points to a bigger problem in his post: CVEs are not keeping pace with the number of vulnerabilities. Based on data from his cve-analysis tools, the number of CVEs assigned was fairly flat for a few years until 2017, which is when the CVE-request web form was added:

We can see a noticeable uptick in 2017. For most of us paying attention this was what we were waiting for, the CVE project was finally going to start growing!

And then it didn't.

Since that spike in 2017, CVE assignments have been flat or even declining slightly, but no one would seriously argue that this reflects the number of actual vulnerabilities. For part of the explanation of why, Bressers pointed to a 2020 article that looked at the role played by CVE Numbering Authorities (CNAs), which are companies and other organizations that get blocks of CVE IDs that they can issue for vulnerabilities in their projects and products. The number of CNAs has expanded over the years, but slowly; by 2016, there were only 22 CNAs, while today there are 159.

The point in that article is that the CNA system lets a CNA decide what should get an ID. This is sort of how security worked in 1999 when security researchers were often treated as adversaries. This is no longer the case, yet researchers have no easy way to request and use their own CVE IDs. If you report a vulnerability to an organization, and they decide it doesn't get a CVE ID, it's very difficult to get one yourself. So many researchers just don't bother.

A DWF reboot

So, after a while, it became clear that the CVE situation was not getting any better, and that DWF was not solving those problems either. Bressers, Seifried, and others rethought things, which is what led to a new version of DWF:

The idea was to make CVE data work more like open source. We can call that DWF version 1. DWF version 1 didn't work out. There are many reasons for that, but the single biggest is that DWF tried to follow the legacy CVE rules which ended up strangling the project to death. Open source doesn't work when buried under artificial constraints. Open source communities need to be able to move around and [breathe] so they can thrive and grow.

The intent is for DWF to get to "100% automated CVE IDs", which has not quite happened, though you should "be able to get a CVE ID in less than ten seconds". There is a form at https://iwantacve.org, which requires a GitHub account to sign in with, then:

You enter a few details into a web form, and you get a candidate, or CAN ID. A human then double checks things, approves it, then the bot flips it to a DWF CVE ID assuming it looks good. Things generally look good because the form makes it easy to do the right thing. And this is just version one of the form! It will keep getting better. If you submit IDs a few times you will get added to the allowlist and just get a DWF CVE ID right away skipping the CAN step. Long term there won't be any humans involved because humans are slow, need to sleep, and get burnt out.

The project has carved off a piece of the CVE-ID namespace to issue its IDs, though that piece is far removed from the five-digit CVE IDs that the CNAs issue. The first identifier issued is CVE-2021-1000000, which was tracked via this issue in the DWF GitHub repository. There is some amount of controversy over the use of the normal CVE identifier format, but that is by design; the project thinks that the term "CVE" has become a generic term that simply means "vulnerability". Meanwhile, DWF believes that it makes sense to have all of the IDs for vulnerabilities live in the same namespace.

The CVE project seems to feel differently, as it put out a tweet disavowing CVE IDs that do not come from the CNAs. CVE board member Tod Beardsley also filed a pull request to change the identifiers to DWF-xxxx-yyyyy, which "will disambiguate vulnerability identifiers sourced from the DWF project from those produced by the federation of CVE Numbering Authorities, and avoid any confusion in downstream users of these identifiers". Seifried closed the request, quoting Bressers's comment on a separate suggestion for a different ID name:

CVE now means "vulnerability" in the same way a tissue is a kleenex. If we create a "new" naming scheme we end up with https://xkcd.com/927/ But if we reuse an existing naming scheme, there isn't an increase in identifiers names.

Bressers also noted that by choosing a range in the ID space starting at one million, there should be no logistical problems with numbering collisions: "possibly ever, but at least for decades".

The DWF project is broken up into three separate pieces, each with its own repository. The dwflist repository holds the JSON version each CVE that has been issued. At the time of this writing, there are eight entries from several different reporters, though no new CVEs have been assigned since March 18.

The dwf-workflow repository is the place "where conversations are meant to be held". It is currently a GitHub repository, but that could change depending on where the community wants to take things. It has the FAQ for the project, along with some other documentation. In addition, some conversations do seem to be getting started in the issues. Bressers described the workflow repository this way:

Everything is meant to happen in public. This is the best place to start out if you want to help. Feel free to just jump in and create issues to ask questions or make suggestions.

Finally, there is the inevitable dwf-request code repository, which holds the Node.js code for the web form and a Python bot for actually assigning IDs based on the GitHub issues that get created from the form. "Neither is spectacular code. It's not meant to be, it's an open source project and will get better with time. It's good enough."

The intent of DWF is clear: to have a community-driven process for assigning IDs to vulnerabilities, rather than the largely corporate-driven process that exists today. The community being targeted is explicitly including security researchers, who may not be well-represented in the CVE project. It would also include those interested in ensuring that vulnerability tags are not being haphazardly applied based on the commercial interests of those doing the tagging—community Linux distributions, for example. Whether there is enough "push" from those groups to sustain an approach like DWF remains to be seen, however.