Date: Sat, 5 Mar 2016 14:43:06 -0800 From: Tim <tim-security@...tinelchicken.org> To: oss-security@...ts.openwall.com Subject: Re: Concerns about CVE coverage shrinking - direct impact to researchers/companies > Of course, the information will need to be available to those > third-party databases from somewhere - but this can be the researcher's > or the vendor's disclosure, as you say. Until such disclosure, a > customer would not even be aware of the ID, let alone want to look it up. The trouble with third-party databases is that they aren't a reliable archive of information. I can't tell you how many times I've found a vulnerability scanner detecting an issue, and I go back to get more details to understand the risk, only to find all the technical details have been taken offline. It is a major gap in the security community's (and IT industry's) tool set that we don't have a reliable, single archive of vulnerability information. It is a huge waste of time looking up every bug. And when I say "reliable" I merely mean the information won't go away tomorrow (like the old FD did so suddenly). I don't mean the information must always be true or validated, just available. Providing something like this is clearly a significant undertaking and isn't something most security companies can make any real money at. *Maybe* a well-thought-out non-profit could accomplish this and still make ends meet by providing bulk feeds for a small subscription fee. Obviously a government has the resources to do this, if not always the competence. Currently my government is just "letting the Internet burn", as they say, so I'm not optimistic that DHS or whatever is going to step up. > A drawback is that such requests become somewhat security-sensitive, if > for yet unpublished issues. This is already a major concern with CVE, > where information may be subject to unjustified risk for the purpose of > merely getting an ID assigned. That's a good point. As a researcher, I want an ID very early in the process (before going public) so I can refer to it when interacting with a vendor and draft my advisory in advance. One *could* accept submissions "to be released on date ...", but then any database like that will become a target. So instead, this hypothetical web app could require only basic information about the products affected up front, and then allow arbitrary additions of content later. (Note I said additions, not changes). I think it should also allow anonymous submission, perhaps only with validation of email addresses (which could be burners). It's all too easy for researchers to become victim of idiotic libel lawsuits. (Which then leads one to wonder what legal defenses the hosting org needs...) Cheers, tim
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.