On Mon, 25 Jun 2012, Art Manion wrote:
: On 6/25/12 7:06 AM, Carsten Eiram wrote:
:
: > Finally, since CVE is not competing with any VDBs, they can as far as
: > I'm concerned rely quite a bit on VDBs to pick up vulnerabilities
: > from random sources instead of doing it themselves. Also, if no VDBs
: > or major sources cover a specific vulnerability report, how important
: > is it then for it to have a CVE identifier assigned? If a critical
: > vulnerability in a popular product, then the VDBs have failed, but
: > will likely pick it up eventually (and CVE can then catch it from
: > there) - I don't consider it to be the responsibility of the CVE team
: > to uncover it.
:
: I have a vague future vision of more qualified and trained CNAs covering
: segments of the public vulnerability disclosure market (JPCERT for
: Japan, ICS-CERT for control systems, Red Hat for Red Hat, etc), with CVE
: being the CNA of last resort, as well as the conflict resolver and CNA
: grey-bearded guru. In product terms, some CNAs could take
: responsibility for certain products or classes of product. In source
: terms, CVE could monitor a set of current VDBs, and only put in further
: effort if something gets missed or there's a conflict.
^ This, I believe is the wave of CVE's future. This model would
effectively outsource the work to groups already doing all of the heavy
lifting. CVE would spend less time assigning, and more time organizing the
incoming reports of CNA-assigned entries. They would become the auditors
of CNAs doing a bulk of the work.
This would solve both problems; focusing on sources and products.