Switch away from CVE-ID as primary id.

[mveytsman]

I've updated all the advisodies with OSVDB IDs. We now have one advisory in the database (loofah/OSVDB-90945.yml) and several vulnerabilities in the queue that have OSVDB IDs but not CVE IDs. Based on Jericho's comments in the mailing list that is going to continue to be the case.

Would it make sense to switch to OSVDB as the canonical ID?

Alternatively we can implement a RUBYSEC-XXXX ID scheme. The only downside would be with conflicts when multiple people submit the same vulnerability, but I think this is actually non-issue since we have only a few people with commit-rights, we can just quickly resolve RUBYSEC-XXXX ID conflicts over github.

Thoughts?

[tarcieri]

Either CVE or OSVDB would work for me, provided we pick one and stick with it ;)

I thought the plan was to use CVE for everything, and in cases where there aren't CVEs, @kurtseifried could obtain CVEs through RedHat

[mveytsman]

At the moment OSVDB has better coverage, and I don't want @kurtseifried to be a blocker for us since he has better things to do with his time.

Getting more covered of Ruby gem vulnerabilities in CVE/NVD is good, but shouldn't necessarily be a goal of our project. OSVDB is really good at getting this information up themselves...

Only downside is that OSVDB will have several vulnerabilities for things that we may only want to list as one advisory, for instance: http://www.osvdb.org/show/osvdb/91219 http://www.osvdb.org/show/osvdb/91218 http://www.osvdb.org/show/osvdb/91216 are all the same disclosure. On the other hand, having them as separate issues isn't too much of a problem...

[kurtseifried]

On Mon, Apr 1, 2013 at 6:02 PM, Max Veytsman notifications@github.comwrote:

At the moment OSVDB has better coverage, and I don't want @kurtseiferid to
be a blocker for us since he has better things to do with his time.

I wish this were true ;). But more to the point you guys will have security
related issues that end up classified as security hardening so no CVE gets
assigned, a great example of this is the group dropping issue in haproxy
from a few months ago:

http://www.openwall.com/lists/oss-security/2013/01/25/1

So yes it needs to be fixed, but because there is no way to exploit it (see
my email) it gets no CVE. But if this was a ruby component no doubt you'd
want to have this in your database.

Getting more covered of Ruby gem vulnerabilities in CVE/NVD is good, but
shouldn't necessarily be a goal of our project. OSVDB is really good at
getting this information up themselves...

Only downside is that OSVDB will have several vulnerabilities for things
that we may only want to list as one advisory, for instance:
http://www.osvdb.org/show/osvdb/91219
http://www.osvdb.org/show/osvdb/91218
http://www.osvdb.org/show/osvdb/91216 are all the same disclosure. On the
other hand, having them as separate issues isn't too much of a problem...

Sounds like you need some SPLIT/MERGE guidelines =)

http://cve.mitre.org/cve/editorial_policies/cd_abstraction.html

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-15744735
.

Kurt Seifried
kurt@seifried.org

[postmodern]

I think projects like brakeman are better suited for reporting security hardening issues (misconfigurations, lazy defaults, etc).

[brynary]

Brakeman will help you with securing and hardening your app. I suppose this goes to: Is the database intended to cover packages with known exploitable vulnerabilities, or all packages that have security weaknesses that have been disclosed?

[postmodern]

I would say vulnerabilities that are (potentially) exploitable.

[kurtseifried]

You'll get stuff that is worth security fixing/etc but for whatever reason
doesn't qualify for a CVE. e.g. The vulnerable version may be a beta/RC, or
like the haproxy example where it's a security issue, just not exploitable
at that moment. There's a lot of other corner cases too that are more
common than you'd think.

On Mon, Apr 1, 2013 at 7:00 PM, Postmodern notifications@github.com wrote:

I would say vulnerabilities that are (potentially) exploitable.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-15747584
.

Kurt Seifried
kurt@seifried.org

[mveytsman]

So, shall we go with OSVDB with filename? @postmodern, thoughts?

[postmodern]

@mveytsman I don't see why not. If the advisories does not exist in the NVDB, but does exist in OSVDB, why not? Only real change is the prefix of the filen ame.

[tarcieri]

OSVDB seems good... let's just standardize on something ;)