Date: Wed, 6 May 2009 11:40:16 -0400 (EDT) From: "Steven M. Christey" <coley@...us.mitre.org> To: oss-security@...ts.openwall.com Subject: Re: oss-security CNA On Mon, 27 Apr 2009, Josh Bressers wrote: > I think having an oss-security CNA that is not MITRE would be useful, and > hopefully would alleviate some of the pressure MITRE currently feels. There > would of course be collisions from time to time, but that's likely going to > still cause less pain than the current model provides. > > If this idea is appealing to MITRE, we could start working out some of the > details. I agree that this idea is worth exploring in detail. One complicating factor is that various vulnerability databases have started monitoring this list, so we might create a CVE from our internal db-monitoring stream at the same time that a CNA performs an assignment. Many months ago, I privately conferred with Mark Cox on this challenge for MITRE, and he suggested something like a well-formed request that fills in details that are relevant for CVEs. Such details are often missing from the oss-security requests. (They are often missing from Bugtraq and milw0rm posts too, but those are usually pretty simple bug types.) I don't know if a form-like request would always work, but it would make things more efficient. As one example - the distros all use their own local version numbering schemes, or at least they maintain different versions. This sometimes make it into a CVE description (causing inaccuracies we might have to fix later) or otherwises forces some research to determine the likely upstream version. For Linux kernel issues, I often have to sift through git commit logs to guess that if a patch was committed on date X, and a new kernel was made on X+3, that maybe that's the fixed kernel version - at least for the 2.6 kernel anyway. As Jericho said, open source poses a special challenge because there is often a large amount of details we may want to include in descriptions. Especially for things like the Linux kernel, CVE often has more specific details than any other data source out there. This is expensive to generate, but avoiding such details when they're available potentially leads to duplicates or confusion. My comments of the past few weeks are a reflection of the CVE team's larger efforts for defining a process that's efficient but still fulfills CVE's primary role for its primary audience(s). Thanks all, Steve
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.