Comment OSVDB Concerns (Score 1) 142
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 OSVDB, but otherwise allow the information to be freely used In addition, GPL would not allow private companies to use because of the Derivative works sections which could impact their products.
* Concerns over OSVDB complying with DMCA requests..
- One DMCA injunction can not shut down the entire database. If information contained in it is in dispute, it may be removed until the issue is resolved, but the database as a whole remains in tact and available.
* Sponsored by a security company and non-biased?
- Yes. The current sponsor (Digital Defense) provides bandwidth and hosting for the OSVDB project. They have no say in the OSVDB process nor the ability to manipulate the information in the database to their own ends. If at any point a sponsor tries to influence the project in any way that would be inappropriate or compromise the integrity of the database, OSVDB will find a new home.
* "They don't provide an easy way fo downloading the database.."
- Yes, we do. A user only has to agree to the license in order to download the entire database. The only person who should find this troublesome is the person who plans to use the information for their own profit, while not returning anything back to the project. If this isn't you, download away!
* "Why they don't use the CVE numbers?"
- We do, every single chance we get. In fact, we do our best to cross reference our entries with CVE, ISS X-Force, SecurityFocus, Secunia, SecuritryTracker and more. The lack of a CVE entry on an OSVDB entry indicates we either missed it (please mail us so we can add it) or there wasn't a corresponding CVE entry. There are literally hundreds of entries in OSVDB already that aren't in other databases and will have no cross reference.
The folks at Mitre are well aware of our project and have been following it. If any entry appears in OSVDB they can determine if it should be a CVE entry. For a wide variety of reasons, several VDBs (such as ISS and BID) have many entries not covered by CVE.
* Why don't you give credit to the bug finder?
- We do! The creditee field was added fairly recent so some stable entries may not have it, but new entries are being created with proper credit. In time we will revisit the current stable entries and add in missing fields that were not available when the entry was first created.
* 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 OSVDB, but otherwise allow the information to be freely used In addition, GPL would not allow private companies to use because of the Derivative works sections which could impact their products.
* Concerns over OSVDB complying with DMCA requests..
- One DMCA injunction can not shut down the entire database. If information contained in it is in dispute, it may be removed until the issue is resolved, but the database as a whole remains in tact and available.
* Sponsored by a security company and non-biased?
- Yes. The current sponsor (Digital Defense) provides bandwidth and hosting for the OSVDB project. They have no say in the OSVDB process nor the ability to manipulate the information in the database to their own ends. If at any point a sponsor tries to influence the project in any way that would be inappropriate or compromise the integrity of the database, OSVDB will find a new home.
* "They don't provide an easy way fo downloading the database.."
- Yes, we do. A user only has to agree to the license in order to download the entire database. The only person who should find this troublesome is the person who plans to use the information for their own profit, while not returning anything back to the project. If this isn't you, download away!
* "Why they don't use the CVE numbers?"
- We do, every single chance we get. In fact, we do our best to cross reference our entries with CVE, ISS X-Force, SecurityFocus, Secunia, SecuritryTracker and more. The lack of a CVE entry on an OSVDB entry indicates we either missed it (please mail us so we can add it) or there wasn't a corresponding CVE entry. There are literally hundreds of entries in OSVDB already that aren't in other databases and will have no cross reference.
The folks at Mitre are well aware of our project and have been following it. If any entry appears in OSVDB they can determine if it should be a CVE entry. For a wide variety of reasons, several VDBs (such as ISS and BID) have many entries not covered by CVE.
* Why don't you give credit to the bug finder?
- We do! The creditee field was added fairly recent so some stable entries may not have it, but new entries are being created with proper credit. In time we will revisit the current stable entries and add in missing fields that were not available when the entry was first created.
