RE: [CD] CD Proposal: SF-LOC (Software flaws in different lines o f code)
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?
>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?
"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