The database exports contain all stable data from the database, and are created every morning at 1:00 AM Eastern Standard Time. The database exports are available from the following links.
New: Importing CSV Export into a Database:
The current CSV exports contain a SQL script to import the data into a MySQL database. See the README file for details. At present, that is the only database we support. If someone would like to contribute a Postgresql, Access, or any other import script, please let us know.
New: SQLite file:
We now provide a SQLite database for download.
New: MySQL Dump file:
We now provide a MySQL Dump file for download.
Importing XML Export into a Database:
Currently, there are NO supported XML import scripts. They are all deprecated. The XML dumps remain though, and continue to be updated.
Viewing the XML Export Directly:
The database may also be accessed through the XML export file directly. The XML export was designed such that all database integrity is stored within the structure of the XML file. This means that instead of exporting the OSVDB database table by table, it is exported vulnerability by vulnerability. By using this method, we hope to provide a means by which anyone can keep a local copy of the current OSVDB snapshot, even in the absence of a local database such as PostgreSQL. Another feature of the chosen formatting is the ease in which this XML export can be integrated into products using tools such as XPath to pull all the information about a specific vulnerability straight from the XML file.
Click a link to download.
Vulnerabilities listed in OSDVB can be referenced by their OSVDB ID, which is a unique number assigned to each vulnerability in the database.
Further information on each vulnerability is available via either of the following URLs (Where XXXX is the OSVDB ID):
http://www.osvdb.org/show/osvdb/XXXX
http://www.osvdb.org/XXXX
- External Reference - An External Reference is a piece of information that contains information about the vulnerability but exists outside the scope of the database--for example, a link to the original advisory, a link to a vendor advisory, a Nessus Script ID, or a Snort Signature ID.
CSV/MySQL Dump/SQLite Export Tables:
- vulnerabilities - The vulnerabilities table is the main table in the schema. It's where the OSVDB IDs live, as well as the descriptions and dates.
- authors - This table adds support for identifying contributors for vulnerability credit.
- ext_references - This table is binds external values to OSVDB IDs. It allows for an infinite number of bindings between the two. Other than this, it doesn't store any significant data.
- ext_reference_types - This table holds information and descriptions of short external references. Since not all external references belong in a blob this table along with ext_ref were created. This allows things like Nessus IDs or Snort Signature IDs to be stored in more sane manner.
- classification_items - This table links vulnerabilities to classifications.
- classifications - This table describes all the various classifications
- classification_types - This table categorizes and grounds classifications
- object_links - This table stores product information as it is related to the osvdb_id. The name "object" might seem vague, but it refers to the object that the vulnerability exists within.
- object_correlations - This table binds vendor, base, version and vulnerability together.
- object_affect_types - This table stores the different degrees of affectedness, such as "might be affected".
- object_products - This table contains product names--for example, Windows, Exchange, Apache, and MySQL.
- object_vendors - This table contains the vendor names--for example, Microsoft, Sun Microsystems, and Apache Software Foundation.
- object_versions - This table contains the version names--for example, 1.0, 2.0, 0.1, XP, 2000, and 95.
- credits - This table adds support for identifying credit for discovering a vulnerability. Instead of storing author like information, we just reference the author table, as the data is extremely similar.
XML Export Tables:
- vuln - The vuln table is the main table in the schema. It's where the OSVDB IDs live. Other information stored in this table includes various dates and vulnerability classification data.
- ext_txt_type - This table defines the types of texts we are storing in the ext_txt reference table--for example, Vulnerability Description, Solution Description, Technical Description, Manual Testing Notes.
- language - This table adds support for multiple language external text types in the database. This table stores language names.
- author - This table adds support for identifying contributors for anything in ext_txt table. It is not an all-encompassing table for every small contribution and does not allow for complete identification of every text an author contributes. All it allows for is the addition of a contributor's line to each OSVDB ID. The authors are used to track the external text authors, as well as the researcher credited for each vulnerability.
- ext_ref - This table is binds external values to OSVDB IDs. It allows for an infinite number of bindings between the two. Other than this, it doesn't store any significant data.
- ext_ref_type - This table holds information and descriptions of short external references. Since not all external references belong in a blob this table along with ext_ref were created. This allows things like Nessus IDs or Snort Signature IDs to be stored in more sane manner.
- ext_ref_value - This table was created to keep the number of ext_ref values collisions to a minimum. Now it is possible to bind a single value to multiple osvdb_ids. This table contains the actual external reference data, along with the external reference type.
- ext_txt - This tables stores the external text blobs for any type of text that is larger than 1024 characters. Other information stored includes the language, type, author, and revision. When the texts are updated/fixed/modified the new text is reinserted into this table and the revision number is incremented.
- object - This table stores product information as it is related to the osvdb_id. The name "object" might seem vague, but it refers to the object that the vulnerability exists within.
- object_correlation - This table binds vendor, base, version and vulnerability together.
- object_affect_type - This table stores the different degrees of affectedness, such as "might be affected".
- object_base - This table contains product names--for example, Windows, Exchange, Apache, and MySQL.
- object_vendor - This table contains the vendor names--for example, Microsoft, Sun Microsystems, and Apache Software Foundation.
- object_version - This table contains the version names--for example, 1.0, 2.0, 0.1, XP, 2000, and 95.
- Score - This table is used to bind a scoring weight to a vulnerability. It was intended to allow every vulnerability in the database to be associated with one scoring weight. Currently this table is not used, but will be used in the future. Also, this could be used by other organizations to store vulnerability scores without having to modify the core OSVDB tables.
- score_weight - This table is not used by the OSVDB development team. It was added so other organizations using this database have a place to store scoring information without having to modify the core OSVDB tables. The weight field is a small field to store any type of scoring information needed for scoring calculations (20%, .20, 5*2) etc.
- credit - This table adds support for identifying credit for discovering a vulnerability. Instead of storing author like information, we just reference the author table, as the data is extremely similar.
