RE: [CD] CD Proposal: SF-LOC (Software flaws in different lines o f code)

[Pascal Meunier <pmeunier@purdue.edu>]

Bill Fithen <wlf@CERT.ORG> wrote:

>It seems truly fundamental to me that the nature of a vulnerability is
>independent of the mechanism(s) that can be used to correct it. There
>may be many ways to correct a vulnerability. In fact, it seems obvious
>to me that a "list" of such corrections of countermeasures is an
>entirely separate undertaking on a par with CVE (perhaps CCE?).

This begs the question, if we have to analyze the nature of a
vulnerability to make a CVE entry, haven't we gone too far with
respect to the stated goals of the CVE?

( snip...)

>All other things being inconclusive with respect to the split/merge
>question, if we arrive at this rule and the vendor refuses to answer
>the split/merge question, then it seems to me the only conservative
>approach is to split. If we incorrectly split, the only consequence is
>information redundancy. If we incorrectly merge, the consequence is
>information loss. Once we split based on the lack of information, the
>(possibly redundant) entries are marked as 'this is all we know' and
>left that way until we know more. If at some point in the future (even
>after they might be voted into CVE), if someone learns enough to
>"prove" to us they should have been merged, then we merge them.

I agree with this.  Moreover, why not split by default, merge when
'someone learns enough to "prove" to us they should have been
merged', and save the headache?

Pascal
"You cannot build a happy private life in a corrupt society anymore
than you can build a house in a muddy ditch."
Anonymous Czech woman, from the 2000 Commencement Address by Bill
Moyers about the american political system