With the public exposure of the Open Source Vulnerability Database (OSVDB.org), there have been a few concerns and fallacies voiced about the project. This reply is to clear up a few points and address some of the issues posted on
various forums.
* The name "Open Source" Vulnerability Database implies it will catalog open source software, not closed systems such as Windows.
- While the name may imply that, the database will catalog all types of vulnerabities regardless of operating system or vendor. The name was chosen to show that the information contained in it would be open source itself,
and to reflect the contributors.
* Why are old vulnerabilities on the top of the list?
- The 10 most recent vulnerabilities displayed on the main page show the recent entries that were approved for the publicly viewable database.
This list is not designed to show the last 10 vulnerabilities made public. On the "todo soon" list is to have an xmlrpc and RSS feed to
distribute truly new entries.
- Yes and no. CVE is "Dictionary, NOT a Database" and "CVE should not be considered as a vulnerability database on its own merit" according to their site. While SecurityFocus, CERT and ISS both maintain VDBs, OSVDB intends to do things differently. This should provide another free resource for security professionals.
At this time, the database content is significantly less than other databases, but this is a long term project. The time it takes to sort through roughly 10,000 vulnerabilities, put them in a standard format and ensure the accuracy of the information is immense. OSVDB is looking for more volunteers who would like to help this process. Even now, the OSVDB contains hundreds
of vulnerabilities that aren't found in any others. We strive to be as thorough as we are accurate.
Now that the technical details have been worked out, the process established, and we're ready to support public use, the database content is the immediate concern.
* Can't this database be used by hackers and crackers?
- Yes, but no more so than an archive of the Bugtraq or Full-Disclosure mail list (or a number of other mail lists). Vulnerability information
is already public, and easy to access with search engines such as Google. Every vendor that maintains an archive of security advisories for their own product offers attackers the type of information to hackers. The information is not inherently evil, the person who uses it incorrectly is.
* VBDs "like this one have a habit of publicising vulnerabilities without telling the software authors first".
- While vulnerability researchers may not warn vendors, any unpublished vulnerability
information obtained by OSVDB will be handled within a responsible disclosure policy. At no time will we publish information that has not been disclosed to the vendor and reasonable time provided for a solution.
* "I sure hope they will provide nice charts with statistics.."
- Generating detailed statistics on vulnerabilities is one of our short term goals. These statistics will hopefully help people to learn more about the types of vulnerabilities, their history and help better evaluate risk for deployed platforms.
* Why isn't the OSVDB licensed under GPL or another more commonly used license?
- The short answer is that we want to avoid having a commercial entity use the work of a volunteer staff to profit. GPL would not allow credit to be required and extensive research showed that we needed to create our own license
for now. Hopefully, the project will gain some funding to seek legal counsel or a nice lawyer will donate time to consult on the license. The point is we want the data to be free, however, to ensure that proper credit is given to OSVDB and its contributors. The licensing we have established is designed to protect us from this scenario by requiring branding of the data as
having come from OS
Slashdot Mirror
With the public exposure of the Open Source Vulnerability Database (OSVDB.org), there have been a few concerns and fallacies voiced about the project. This reply is to clear up a few points and address some of the issues posted on various forums.
* The name "Open Source" Vulnerability Database implies it will catalog open source software, not closed systems such as Windows.
- While the name may imply that, the database will catalog all types of vulnerabities regardless of operating system or vendor. The name was chosen to show that the information contained in it would be open source itself, and to reflect the contributors.
* Why are old vulnerabilities on the top of the list?
- The 10 most recent vulnerabilities displayed on the main page show the recent entries that were approved for the publicly viewable database. This list is not designed to show the last 10 vulnerabilities made public. On the "todo soon" list is to have an xmlrpc and RSS feed to distribute truly new entries.
* Isn't SecurityFocus/CERT/CVE/ISS already doing this?
- Yes and no. CVE is "Dictionary, NOT a Database" and "CVE should not be considered as a vulnerability database on its own merit" according to their site. While SecurityFocus, CERT and ISS both maintain VDBs, OSVDB intends to do things differently. This should provide another free resource for security professionals.
At this time, the database content is significantly less than other databases, but this is a long term project. The time it takes to sort through roughly 10,000 vulnerabilities, put them in a standard format and ensure the accuracy of the information is immense. OSVDB is looking for more volunteers who would like to help this process. Even now, the OSVDB contains hundreds of vulnerabilities that aren't found in any others. We strive to be as thorough as we are accurate.
Now that the technical details have been worked out, the process established, and we're ready to support public use, the database content is the immediate concern.
* Can't this database be used by hackers and crackers?
- Yes, but no more so than an archive of the Bugtraq or Full-Disclosure mail list (or a number of other mail lists). Vulnerability information is already public, and easy to access with search engines such as Google. Every vendor that maintains an archive of security advisories for their own product offers attackers the type of information to hackers. The information is not inherently evil, the person who uses it incorrectly is.
* VBDs "like this one have a habit of publicising vulnerabilities without telling the software authors first".
- While vulnerability researchers may not warn vendors, any unpublished vulnerability information obtained by OSVDB will be handled within a responsible disclosure policy. At no time will we publish information that has not been disclosed to the vendor and reasonable time provided for a solution.
* "I sure hope they will provide nice charts with statistics.."
- Generating detailed statistics on vulnerabilities is one of our short term goals. These statistics will hopefully help people to learn more about the types of vulnerabilities, their history and help better evaluate risk for deployed platforms.
* Why isn't the OSVDB licensed under GPL or another more commonly used license?
- The short answer is that we want to avoid having a commercial entity use the work of a volunteer staff to profit. GPL would not allow credit to be required and extensive research showed that we needed to create our own license for now. Hopefully, the project will gain some funding to seek legal counsel or a nice lawyer will donate time to consult on the license. The point is we want the data to be free, however, to ensure that proper credit is given to OSVDB and its contributors. The licensing we have established is designed to protect us from this scenario by requiring branding of the data as having come from OS