[CVEPRI] CVE candidate issues - handling new candidates
Now that CVE is public, we need to address some issues related to CVE
It is likely that there is a backlog of 1000-2000 vulnerabilities or
exposures that have not yet been assigned a candidate number. As
Board members and others make their tools and databases CVE-compatible
and contribute their "top 100" lists to me, I believe we will be able
to address the backlog by using candidate clusters, in the way that we
did earlier this year.
However, we must not allow CVE to become obsolete with respect to
recent or newly discovered security problems, which come in at the
rate of about 1 or 2 per day. We need to take a balanced approach so
that CVE can also be as current as possible with respect to new
*** The Executive Summary ***
This is a big message, so here are the most salient points:
1) We should start educating the public about candidates now. The
sooner we use candidate numbers, the better.
2) Until content decisions and candidate assignment issues are well
resolved, I'll remain the sole CNA to minimize "noise."
3) I could assign candidate numbers to Board members who provide me
with sufficient information to write up a description and include a
reference. Subsequent proposals will be sent to interested Board
members on a regular basis.
4) We will restrict this approach to new problems ONLY, using
established methods to deal with legacy entries. This scopes the
problem while making CVE be as complete as possible from this point
5) Basic candidate information is provided on the web site (e.g. as a
large HTML or text file), with enhancements to occur later.
6) Your feedback is appreciated.
*** THE ISSUES ***
1) How - and when - to educate the public about candidates and their
difference from CVE entries.
CVE has been given some attention in the past month. However, it's
clear that the public still needs to be educated about it (consider
the recent discussions on the firewall-wizards mailing list). If
we make candidates more prominent - e.g. by including them in
advisories or somehow attaching them to postings to mailing lists -
will we obscure the original message that this initiative even
exists? Do we confuse the public with two numbering schemes (CVE
numbers and candidate numbers)? How much does that increase the
risk of candidate numbers becoming the de facto standard? If all
major products are looking to be CVE-compatible, then this problem
is probably reduced significantly.
On the other hand, people will have to be educated about candidate
numbers sooner or later, so why not just educate them now? In
addition, the longer we delay attaching candidate numbers to early
vulnerability information, the more effort everyone will have to
spend coordinating all that information.
2) Identifying the best mechanism and infrastructure for making
candidate information available to (a) voting Board members, (b)
mappers, and (c) other interested parties, while minimizing
confusion with normal CVE entries.
There are several database design and implementation issues that
will take some time to resolve before a viable candidate
information source can be provided, whether to Board members or to
the public as a whole. But there is a clear need for it. Board
members need to be able to know which candidates they've voted on
(or need to vote on). Mappers and other interested parties should
be able to access this information to stay current, especially if
they are seeking CVE compatibility. There are also some questions
with respect to the best way to handle databases that use both CVE
numbers and candidate numbers. In addition, the linkage between
CVE numbers and candidate numbers will need to be recorded,
especially for cases where a candidate is split or merged.
Dissemination of candidate information could be addressed in
phases. For example, I have already made some basic candidate
status information available to Board members in a comma-separated
format. We could make that available for download by interested
parties along with other basic formats, saving other issues
(e.g. database design or a good search utility) for later.
3) How to assign candidates in a way that minimizes "noise" as well as
the amount of work that the Board needs to do to validate entries
(both now, when so many content decisions are undecided, and later,
as new CNA's are brought into the process).
If there are too many sources of candidates early in the process,
then there is an increased risk of (a) duplicates, (b) rejections,
and (c) recasts. The more candidates there are, the more work that
Editorial Board voters will have to do. This problem will be
exacerbated by the lack of a good mechanism for obtaining and
managing candidate information, as described above in (2). In
addition, very few content decisions have been sufficiently
discussed and approved by the Board, which will cause more problems
in terms of being able to reliably assign candidate numbers that
have a good chance of acceptance.
4) How to link announcements of new vulnerabilities/exposures
(e.g. advisories) to CVE or candidate numbers without forcing the
announcer to give up their real or perceived "competitive edge" for
being the first to disclose the problem.
There are several complexities in dealing with this particular
problem. Consider "first-time advisories" in which a problem is
first announced to the public in a formal advisory. In the best of
all possible worlds, the advisory would be posted with a CVE
number(s) included in it. However, a CVE number would require
validation by the Board, which would require the advisory
organization to disclose sufficient details for validation (current
voting rules do not allow a candidate to be accepted with only a
single Board member and confirmation by the software vendor). The
organization with the advisory may not want to provide this
information to their competitors. (This concern has already been
expressed.) In addition, if the candidate really isn't public,
then there would need to be a secure mechanism to protect the
related information while it is being validated, which poses
challenges for maintaining confidentiality. If such a mechanism is
feasible, it will take time to set up.
In short, while it might be best that an advisory could include a
validated CVE number with it, there are various challenges which do
not make this possible in the short term. So at this time, a
"first-time advisory" would at best contain candidate numbers. But
if we haven't educated the public as in (1), then the advisory
would need to also take on the task of educating the public about
This particular issue only appears to apply to formal,
well-validated first-time announcements such as advisories.
However, advisories are far-reaching and typically deal with the
most serious and extensive problems, so they could serve as a
vehicle not only to educate the public about CVE, but to provide a
name for major problems as early as possible.
*** AN APPROACH ***
Here's what I suggest as an approach for dealing with new
vulnerability information at this time. It allows us to move forward
on some issues that can be acted upon now, while taking the proper
time to resolve longer-term issues.
0) We treat backlog issues independently of the issues related to new
1) We take steps to educate the public about candidates now.
Education could take the form of (a) web pages on the CVE web site
describing the differences between candidates and CVE entries, (b)
short statements in any forum where candidate numbers are used
(e.g. advisories or mail messages), and (c) additional
clarifications by Board members in various forums where the subject
2) With me continuing to act as sole CNA, I could interact with Board
members who have a desire to obtain candidate numbers for new
- Submissions would be limited to new vulnerabilities ONLY (for
- The submission MUST be ready for public dissemination (or already
- Submitters should only do submissions for vulnerabilities which
they are the first to announce or publicize (this reduces "noise"
of many Board members sending me the same submission). An
alternate approach would be to have different submitters with
different expertise (e.g. Windows NT vs. Unix) to focus on a set
- The submission includes a short description and references,
i.e. looks very much like a candidate proposal
- I then give them a candidate number (or numbers) to use
- The candidates are packaged up and proposed to the Board list on
a weekly basis (to reduce traffic on the list)
- Interested Board members can request to be emailed directly when
new candidates arise, instead of waiting for the weekly posting
This allows for some consistency across candidates while reducing
duplication and other problems. Restricting the request for
candidates to new information, *and* to the original source of the
information, reduces the effort required in this first step.
This also allows me to continue to "schedule" and cluster content
decision debates accordingly so that we avoid discussing too many
technical issues at the same time. As various issues are resolved
(e.g. database design, content decisions, etc.) these experiences
could be used to begin a "training manual" for other CNA's.
By having the candidate submitters send information to me in a
"near-candidate" format, it allows prospective CNA's to begin to
identify and address their own issues.
3) We provide a candidate status page on the CVE web site, including
the capability to download candidate information in various formats
(e.g. text, HTML, CSV). The status information should be detailed
enough to allow Board members to view which candidates they've
4) We delay creating a forum for the Board to discuss non-public
information until some of these other issues have been sufficiently
addressed. But with the public being educated, most first-time
advisories could at least include candidate numbers.
What do you think about this approach?