[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TECH] New CVE Version and Legacy Candidates


A new CVE version will be created within the next 2 weeks.  An Interim
Decision will be made on more than 100 candidates on Monday, September
10, with a Final Decision on the 14th, and a new CVE version on the
14th or the 17th.

We have also created 571 legacy candidates.  After clusters are
created for those candidates, I expect to propose them "en masse" on
Tuesday, September 11.  The clusters will probably be larger than
usual, but there will still be 10 or more.  While it might be nicer on
your email readers to spread these out over a period of a month or so,
I don't see any real reason to delay them further.  Opinions on this
approach are, of course, welcome.

Once the candidates have been proposed, backmaps will be sent to all
data sources.  (Backmaps link the source's own unique ID to the
associated CAN/CVE).


For all issues that were publicized in 1999 and earlier, CAN-1999-xxxx
was used for the numbers (producing CAN-1999-1012 through
CAN-1999-1568).  Other issues that were discovered in 2000 were
assigned CAN-2000-xxxx numbers.  (There are various reasons why those
candidates were not actually created in 2000.)

I expect to follow this numbering pattern for as long as we continue
to use the CAN-yyyy-nnnn format.  (The concept of a new naming format
has not been forgotten.)

Details on the Sources for Candidates

We started with about 8500 legacy submissions, most of which came from
databases that were provided to us from Board members (sources).

902 submissions were used to create 571 legacy candidates.  (This
shows how little overlap there was across the 10 different sources,
since only an average of 1.6 sources "contributed" to each candidate.)
The oldest candidates date back to 1989.

2461 submissions were either (1) already related to existing CVE
candidates or entries, or (2) did not satisfy the CVE vulnerability or
exposure definition.  (It's more difficult to measure the overlap
across sources in this group, but I estimate that it was around 3 to 4
sources per matching candidate or entry.  Still, it's less overlap
than one might expect.)

3936 submissions were delayed (not fully "resolved") for processing
for one or more of the following reasons:

  (1) it was uncertain which vulnerability or exposure was being
  identified by the submission.  This was normally due to vague
  descriptions and the lack of references.  We will consult with the
  original sources on these submissions.

  (2) some submissions were related to complicated issues that were
  not quickly resolvable by the content team member who evaluated
  them.  For example, in summer 1999, numerous problems were found in
  wu-ftp.  It was not necessarily obvious how many different problems
  there were - let alone which vendor advisories were fixing which
  problems.  Another example involves several Oracle issues that were
  discovered and reported by ISS within a short time span, but for
  which there are insufficient details to be certain how to write
  distinctive descriptions.

  These more complex issues can be addressed with more analysis, but
  they have been delayed for this first round, with the hope that we
  will get the candidates "right" the first time we create them.

  (3) some submissions were related to larger questions which we want
  to address before proposing them to the Board.  For example, many
  sources reported various configuration problems related to Windows
  NT, or UNIX.  Some problems were at the OS level, and others were
  unique to specific applications.  There are many questions regarding
  the appropriate level of abstraction to use, and how to "break them
  up" in the first place.  We will devise reasonable "rules" for
  addressing these sorts of problems in the next round, though
  CAN-1999-0550 through CAN-1999-0665 may already cover many of these
  submissions; consequently, the next round will include a
  re-evaluation of those candidates.

We have approximately 1000 more legacy submissions whose status is
unknown.  We will identify them and make sure that they are processed

Page Last Updated or Reviewed: May 22, 2007