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 ([email protected]) 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)