[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Initial Candidate Proposal and Acceptance Process
All: Below is a process I have defined for proposing and discussing candidates. This process is open to adaptation by the Editorial Board, as we go along and test it out, but in the interests of getting *something* rolling, I'll follow this method to begin with. 0) While Dave Mann and I have taken the "silence implies assent" approach, I believe it is important that everybody speak up for this part of the CVE validation. It's hard to know if someone's reading and silently agreeing, or if they're off on vacation somewhere. So please speak up! 1) At the moment, I will be the only Candidate Numbering Authority (CNA), so I am the only one who can propose candidates. This will change as we get closer to release, probably once we're discussing the "Unknown" candidate cluster and/or bringing in new vulnerabilities. (See another email for discussion of candidate clusters). 2) I will propose each cluster in a separate email. Each candidate in the cluster will include: - candidate number - proposer ID (just 001 for me, right now) - date assigned (i.e. date the candidate is "reserved" for use) - date announced (date candidate name is made public) - category - reference(s) - description The candidate number will be equivalent to the CVE number (in version 199904290013), i.e. CAN-1999-00345 will be the same as CVE-00345 in your CVE distribution. 3) Each member of the Editorial Board should respond to each candidate. The following responses are valid: (a) REVIEWING - member is reviewing/researching the candidate. (b) ACCEPT - member approves the vulnerability as proposed. (c) NO OPINION - member specifically avoids commenting on this vulnerability. May be useful e.g. if member is not an expert for that particular type of vulnerability. NO OPINION's are strongly discouraged. (d) REJECT - member rejects the candidate entirely, because: - it is not a vulnerability (i.e. was reported as a problem but turned out not to be) - it is unconfirmed (or not sufficiently confirmed) - it is not a *CVE vulnerability*, i.e. does not fit the CVE vulnerability definition - it is a duplicate - it subsumes a CVE vulnerability (i.e. it's too high level and encompasses existing vulnerabilities) - it is subsumed by a CVE vulnerability (i.e. it's an instance of an existing CVE vulnerability) (e) MODIFY - vulnerability is generally acceptable, but some details may be missing or wrong, e.g.: - description needs slight modification - references incorrect - category incorrect (f) RECAST - there needs to be a better term than this. The member does not believe the candidate as proposed should go into the CVE without being heavily modified, e.g.: - change level of abstraction of the candidate (merge/split with others) 4) Every so often (to be determined), I will pose a "summary" of candidates that appear to be close to resolution. I will also develop a clean way to announce when a final decision has been made. 5) As we get closer to release date, and as vendors/others begin to identify gaps between the CVE and their own vulnerability databases, then we will open the process to include other CNA's besides me.