Awesome

Victims CVE Database

This database contains information regarding CVE(s) that affect various language modules. We currently store version information corresponding to respective modules as understood by select sources.

This project is inspired by the great work done by the people at RubySec.

Notes on CVE(s)

If you already have a CVE assigned to your project and would like us to create an entry for it with the correct coordinates, you can send us a pull request or create an issue here with CVE details and affected components. For more details refer to the Contributing section of this document.

If you are a project owner/maintainer wanting to request for a CVE, a good resource regarding this is available here.

Contributing

We are always looking for contributors. If you would like to submit a new entry or make an update to an existing entry, feel free to send a pull request or create an issue here on GitHub.

Please do refer to the Database Internals section when making contributions.

Validating changes/submissions

You can validate your commits on your branch or local repository by:

# Validates all changes *.yaml files in database compared to upstream/master
bash validation/git-change-validate.sh

If you just want to validate a YAML file, you can run the provided python script:

# This requires PyYAML, all requirements are listed in validation/requirements.txt
# pip install -r validation/requirements.txt

# The validation script
python validation/validate_yaml.py <language> file1 [file2 ... fileN]

Database Internals

Each CVE entry in the database is stored as a YAML file.

Database File Storage Structure

The following structure is employed to store entries:

victims-cve-db/database/<language>/<year>/<cve-id>.yaml

As an example, the entry for CVE-2012-1150 would be:

victims-cve-db/database/python/2012/1150.yaml

The YAML Document

The document requires all required fields in the Common Content Schema.

Common Content Schema

package_url

The package_url field currently supports a templated http string. There will be future supported added for real package-urls. In the meantime the template string supports a few fields which are generated from the victims-cve-db entry itself:

Example package_url templates include:

http://repo.maven.apache.org/maven2/HTTPClient/HTTPClient/{version}/HTTPClient-{version}.jar

http://repo.spring.io/release/org/aspectj/{name}/{version}/{name}-{version}.jar  

This will be expanded when doing package hashing for each affected version in the victims-cve-db entry. As an example if http://example.org/{name}-{version}.jar had a name of test a single affected of <=2.18.2,2.18 the hashing would expand to pull down

• http://example.org/test-2.18.2.jar
• http://example.org/test-2.18.1.jar
• http://example.org/test-2.18.0.jar

You can generate package-urls using a legacy victims-cve-db formatted yaml. The legacy format did not contain package-urls, and only contained version-string. Use the victims-db-builder project to generate package-urls.

Note: Java archives will have their name pulled from artifactId.

version-string: common

The version strings across all languages are expecte to match the regex:

^(?P<condition>[><=]=)(?P<version>[^, ]+)(?:,(?P<series>[^, ]+)){0,1}$

Examples: <=2.6.1,2.6, ==2.7.0, >=1.0.1_Beta

Which enforces the format <condition><version>[,<series>]. Commas (,) and spaces ( ) are considered illegal in <version> and <series> strings.

The <series> string is optional and only used to set boundaries for version ranges. For example, in <=2.6.1,2.6, the series is 2.6 and indicates that only versions in the 2.6.x series with x<=1 is captured.

language-module: python

language-module: java