On 2012-03-08 17:17, Tim Keanini wrote:
> Option B- create a more ontological model that considers CVE not the
> primary or root but just another piece of metadata use to reify some
> other assertion. As a vendor, I can only control what I can control and
> that is my own internal ID which are organizationally closed for my own
> data integrity.
> nCircle-ID-667 -has-CVE-ID-> CVE-xxxx-xxxx
> nCircle-ID-667 -has-CVE-v2-ID-> CVE-xxxx-xxxx-withextension-yyyy-for-future-format
> nCircle-ID-667 -has-Secunia-ID-> Unique-Secunia-ID
> nCircle-ID-667 -has-OSVDB-ID-> Unique-OSVDB-ID
> (for those of you who know me, I would rather be working on a standard
> ontological model that any vendor interoperate no matter what the
> resolution or primary identifier. The goal of interoperability should
> be to compute syntactic or semantic equivalence )
> Call me pragmatic but this is an example of what I have done, not asking
> for anyone else to follow. Just needed an example where CVE was not
> primary but one of the inverse-functional-properties that can be used
> for saying that this is the same as that (compute equivalence)
This is my favorite approach, particularly as it doesn't require CVE or
anybody else to change much (at least not their internal data structures
and processes). The focus could be on an agreed vocabulary and ontology
of vulnerability information.
But, this doesn't make CVE ID issuance any faster.
- Art