It seems that we have collectively come up with a way to energize the Board in ways that it hasn’t been for some time.
We apologize for the delays in responding, and we intend this post to be the first step in opening discussions and making needed changes to CVE.
In recent days, some posters have noted ideas or suggestions they have raised in the past. We appreciate the reminders, and suggest that everyone should feel free to repeat or reprise prior comments so that they can be included in current conversations.
In the last few weeks, we have been working to change several things about CVE. Obviously, we can no longer operate cve-assign as we have in the past, and revamping cve-assign will create or cause several changes that we expect to ripple through CVE.
In the upcoming days, we will be publishing the following to this list:
- A clarifying statement of the scope of CVE.
- Discussion item for the Board with regard to clarification/notification that CVE cannot (in fact) and will no longer (by design) cover all publicly known vulnerabilities, as defined by the scope of CVE.
- Discussion item for the Board specifically regarding the topic of quality issues in the assignment of CVE IDs and the tradeoffs between performing more or less analysis of a request at the time of ID assignment and resultant downstream issues.
We view the above as essential to moving forward by reducing the backlog and the response time for CVE ID requests. If we were to compare CVE to a house, scope would be the footings for the foundation of the house, and counting (abstraction) decisions
would be that foundation.
We appreciate your patience as we have worked through a number of standing issues. We expect that these discussion and others in the near future will enable us to significantly improve the operation of CVE.
We greatly appreciate the Board’s attention, involvement, insights and opinions, and we look forward to working with the Board members on the upcoming discussions and decisions.
Best Regards,
Steve Boyle