rvlsoft - Fotolia
Ten years after it went live for public use, the Open Source Vulnerability Database announced it would shut down due to a lack of support and leaves questions over the viability of open source security programs and how to improve vulnerability databases.
In a blog post, Brian Martin, former content manager of the Open Sourced Vulnerability Database (OSVDB) and president of the Richmond, Va.-based Open Security Foundation, said that OSVDB would not be resurrected and was closing because "the industry simply did not want to contribute and support such an effort."
Martin told SearchSecurity that when he announced OSVDB would be shutting down, people failed to understand how much work is required for such a project.
"The real disconnect is when a project like OSVDB shuts down and hundreds mourn the loss. Then there is the wave of 'let someone else take over it!'" Martin said. "No, it doesn't work that way. Why are people so willing to take it over now, meaning they will have to spend 40 hours a week on it, when they wouldn't volunteer 15 minutes a week before?"
Art Manion, technical manager for vulnerability analysis at CERT, called OSVDB a "grand and noble experiment," but said that support petered out over the years and eventually too many people were scraping data without contributing. Manion noted that VulnDB from Risk Based Security was a potential commercial version of a "spiritual successor" to OSVDB and Distributed Weakness Filing (DWF -- so named to be one letter away from Common Vulnerabilities and Exposures (CVE)) and might also take over to a certain extent.
Martin bristled at the idea.
"Passing it on to someone like that is just a false hope as there is initial excitement a project will continue, as it dies a quick death under the new reins," Martin said. "Worse, very few people in the industry have an idea of how involved a vulnerability database is, and that it requires a certain level of expertise. On the surface they seem simple. If you run one and it continues to be simple, you are doing it wrong."
Martin said the value of DWF would more likely come from being a testing ground for a new CVE ID scheme that MITRE considered but didn't implement.
"DWF is first and foremost a numbering scheme to step in where CVE is failing in one area. That seeks to provide IDs for tracking purposes pre-disclosure, and post-disclosure, to help vendors identify an issue and cut down on confusion," Martin said. "This has been a huge area of failure for MITRE over the last few years and is desperately needed."
Manion said that although MITRE claims CVE is "not a vulnerability database," he sees it as such but noted that it is incomplete because it doesn't include this type of numbering scheme. He said there was a need for security researchers to be able to talk about vulnerabilities that aren't included in the CVE.
Manion said MITRE had "fundamentally chosen a narrow scope of what will be a CVE" in order to create a higher fidelity vulnerability database. Because of this, researchers and security professionals don't have an easy way to reference vulnerabilities that haven't been verified or published in CVE.
Martin, who has criticized how vulnerabilities are counted in the past, said this way of publishing vulnerabilities is a holdover from "the late 90s and early 00s.
"This notion that there can't be duplicate assignments at the cost of not having any presence in the database until it is figured out is wrong," Martin said. "Vulnerabilities should be added, and any concerns expressed clearly. That can be as simple as 'this is still under evaluation' or more complex breaking down the technical reasons why it may not be a valid issue."
Manion said he thinks "CVEs should be assigned more broadly and rapidly," and DWF could fill that gap.
"DWF could become the experiment of the new CVE ID scheme that MITRE didn't implement. There's clearly a need for talking about vulnerabilities, finding out if it was patched, making sure it was caught by the scanner, et cetera." Manion said. "We all need this thing, but no one is putting the time and money into it to make it work."
Martin said vulnerabilities need to be classified quickly because waiting to publish vulnerabilities is a practice that needs to change.
"Users of the vulnerability database should make the ultimate decision if a vulnerability is important to them, and if it poses a risk to their organization. Waiting days, weeks, or even months for a vulnerability to appear in CVE because it might not be exactly as advertised is ridiculous and shortsighted," Martin said. "Mature [vulnerability databases] will add the entries sooner than later, tack on a disclaimer, and monitor the issue moving forward. If it ultimately is determined not to be an issue, they can flag it as 'not a vuln' or some other designation. If your vulnerability database of choice isn't doing that, reconsider the notion that they are the experts."
Learn the difference between CAN and CVE numbers.
Learn whether CVEs can protect applications.
Learn more about sourcing threat intelligence services.