distributedweaknessfiling.org

Distributed Weakness Filing Project Press Pack

If you do not find the information you are looking for below or need clarification please contact Kurt Seifried via email (kurt@seifried.org) to ask your questions, and so that the below information can be updated/added to.

Why the DWF exists

The legacy security vulnerbaility ecosystem lacks innovation and has ceased to grow in pace with software. What progress was made has not resulted in significantly more public security vulnerbaility identifiers being issued. It should also be noted that this lack of coverage is a known problem that is not being addressed properly by the existing legacy security vulnerbaility ecosystem at this time (e.g. https://www.youtube.com/watch?v=WmC65VrnBPI&t=2178s).

History of the DWF

The first incarnation of the DWF was created as an independent effort and made efforts to work with the legacy MITRE CVE ID system. In fact the DWF did become a CNA (CVE Numbering Authority) and the founder, Kurt Seifried, joined the CVE Board (https://cve.mitre.org/community/board/index.html). During this time Kurt Seifried managed to push MITRE to use a JSON data format, previously there were only legacy formats (txt, csv, html and xml (https://cve.mitre.org/data/downloads/index.html) and in fact these legacy formats are still the only ones supported by MITRE. Additionally, Kurt Seifried get MITRE to start using GitHub, however this is still labelled as a pilot project.

The previous incarnation of the DWF was found to be unsustainable and the DWF was shutdown in early 2019.

In January of 2021 Kurt Seifried resigned from the CVE board. The second incarnation of the DWF was started shortly after as an effort to improve the security vulnerbaility ecosystem.

Focus of the DWF

The current focus of the DWF is:

  1. Talking with the security community at large to find out what the pain points are and how we can work together to address them
  2. Improving the shared vulnerability identifier assignment process, speed, latency, and volume especially with respect to automation
  3. Improving the publishing of shared vulnerability identifiers, solved for DWF through the simple expedient of doing it transparently
  4. Improving the shared vulnerability identifier update process especially with respect to automation
  5. Creating processes and technology to allow community participation with both legacy shared vulnerability identifiers and modern shared vulnerability identifiers (updates, discussion, etc.)
  6. Improving interoperability with other security vulnerability management systems and efforts (e.g. Google OSV, RUSTSEC and so on)

DWF Name spacing and preventing overlap

The security identifiers (in the form CVE-YEAR-INTEGER) have been historically name spaced through the simple solution of assigning blocks of integers to legacy CNAs, when assigned these blocks of integers are marked as “** RESERVED **” in the records and published as such. The legacy CNAs are then supposed to use the integers as needed, and once made public the legacy CNAs push the data back to MITRE for publishing in the CVE Database (something that often fails to happen, there are over 500 CVE identifiers published by legacy CNAs that have not been published by MITRE https://distributedweaknessfiling.org/reserved-but-public/). In the past the DWF project has used the namespace 1000000 (one million) and up, this can be seen in the data when the first incarnation of the DWF operated for several years:

Year Examples  
2014 CVE-2014-1000000  
2015 CVE-2015-1000000 through CVE-2015-1000013
CVE-2015-1142857
 
2016 CVE-2016-1000000 through CVE-2016-1000393
2017
CVE-2017-1000000 through CVE-2017-1000510
CVE-2017-1000600
CVE-2017-1001000 through CVE-2017-1001004
CVE-2017-1002000 through CVE-2017-1002028
CVE-2017-1002100 through CVE-2017-1002157
CVE-2017-1002201
2018 CVE-2018-1000001 through CVE-2018-1000999
CVE-2018-1002000 through CVE-2018-1002009
CVE-2018-1002100 through CVE-2018-1002209
CVE-2018-1999001 through CVE-2018-1999047
 
2019 CVE-2019-1000001 through CVE-2019-1000049
CVE-2019-1002100 and CVE-2019-1002101
CVE-2019-1003000 through CVE-2019-1003099
CVE-2019-1010001 through CVE-2019-1010319
CVE-2019-1020001 through CVE-2019-1020019
 

You can see the sub-CNAs that operated under the DWF at various times using the namespace 1001000-1001999, 1002000-1002999, 1003000-1003999 and so on. The DWF usage of the 1000000 (one million) block and up ensures that legacy CNA namespace and DWF namespace will never overlap.

The current legacy CNAs only assign a maximum of 17,000 CVEs per year. This means that the existing legacy CNAs would need to handle and publish 25 times as many security vulnerabilities as they currently do, which is not expected given the flat trend. Keep in mind that the average legacy CNA is actually doing less security identifier per year due to the fact that while the number of legacy CNAs has grown, the number of CVE identifiers published by them has not appreciably grown in the last 4 years.

It is possible that a large number of additional CNAs could be added to the legacy CVE program that actually publishes vulnerabilities with CVE identifiers, and that existing legacy CNAs start handling more vulnerabilities and publishing them to MITRE, as such the DWF is committed to ensuring the namespaces do not collide, as such if existing legacy CNAs hit 100,000 published CVEs (massive growth of 500% after 4 years of effectively 0% growth) then the DWF will move to 2000000 (two million) and up to ensure significant buffer space is maintained, this is trivially achieved as the CVE identifier includes the year allowing changes to be made trivially every year. This process can of course be repeated assuming legacy CVE assignments grow rapidly.

What if legacy CNAs assign duplicate entries for issues handled by the DWF?

One concern people have is that people will submit duplicate security identifier requests for existing CVEs. If notified of a duplicate the DWF will check the NVD database to confirm the duplicate and we will then either mark the NVD CVE entry as a duplicate of ours, or possibly mark ours as a duplicate of the NVD CVE entry.

One significant concern brought up is that there are many low quality CVE entries in the NVD, and that they cannot be updated as easily as they can be in the DWF database.

So far as of 2021-04-19 this has not been a significant problem even though there are 3 duplicated entries:

Example 1

CVE-2021-1000001 assigned by the DWF on Mar 8 07:12:10 2021

CVE-2021-26806 assigned by MITRE on Apr 14 14:00:43 2021

So MITRE was over a month late and MITRE could have easily found this in the DWF database.

Example 2

CVE-2021-1000006 assigned by the DWF on Mar 16 11:39:05 2021 +0000

CVE-2021-28543 assigned by MITRE on Mar 16 15:00:44 2021 +0000

So 3+ hours late and MITRE could have easily found this in the DWF database.

Example 3

CVE-2021-1000007 assigned by the DWF Mar 18 16:23:10 2021

CVE-2021-29932 assigned by MITRE Apr 1 05:00:39 2021

So MITRE was 2 weeks late and MITRE could have easily found this in the DWF database.