The Open-Source Vulnerabilities, OSV, database is a new, open source,  project from Google that goes beyond the current state of CVE tracking.

Avoiding the introduction of vulnerabilities in a project is nothing short of science. Most projects use SAST scanning at the final stage in order to find and fix them. One great tool used in this way is Semgrep which combines the convenience of grep with the correctness of syntactical and semantic search and can be categorized as something between grep and a SAST tool. For the lowdown check my detailed article Semgrep - More Than Just a Glorified Grep.

Of course, checking for security vulnerabilities should not be an afterthought but a process built into the software's development cycle. Acknowledging this fact,the Linux Foundation set up the Open Source Security Foundation (OpenSSF), with the aim of educating us on the latest security best practices and vulnerability disclosures.

The OpenSSF then launched three brand new courses in Secure Software Development Fundamentals, targeted at software developers, DevOps professionals, software engineers, web application developers, and others interested in learning how to develop secure software and how to consider security as part of the requirements of a system.This includes various secure design principles that will help to avoid bad designs and embrace good ones, while it also discusses how to go about securing your software supply chain.

These courses focus on practical steps that can be taken even with limited resources.Pay attention to "limited resources",exactly those scarce ones that most open source projects have to live with.

But despite all the help, what if both SAST tools and teaching best practices can't still close the gap and the final product does ship with unforeseen vulnerabilities? Here comes the CVE tracking at the end of the pipeline.Still,not the panacea since it comes with it's own bag of problems;mainly that for consumers it is often difficult to map a vulnerability entry to the package versions they are using, plus for the package maintainers it is time consuming to determine an accurate list of affected versions or commits across all their branches for downstream consumers after a vulnerability is fixed, in addition to the process required for publication.

This resonates with most open source projects,under resourced and overworked, especialy the ones that are critical to modern infrastructure.An alternative funding to provide such resources was sponsored by the EU,which I examined in EU Bug Bounty - Software Security as a Civil Right.

So to address those shortcomings, Google has introduced OSV in order to: 

"provide precise data on where a vulnerability was introduced and where it got fixed".

OSV complements CVEs by extending them with precise vulnerability metadata, making it easier to query (using either package versions or commits).Furthermore it describes bugs according to a cleaner vulnerability schema.

For OSV to be of value, it requires the package maintainer to submit both the commits that introduced the bugs and the ones that provide the fix. For example, checking the "Heap-use-after-free in sampled_data_sample" bug of ghostscript, codified under OSV-2021-237 and available at https://osv.dev/vulnerability/OSV-2021-237 we gather the following details: the hashes of the commits the bug was introduced in, the commits that it was fixed in and the affected versions.

And here comes the novelty. If that info is not available then:

OSV requires providing a reproduction test case and steps to generate an application build, to then perform the bisection to find these commits in an automated fashion.OSV takes care of the rest of the analysis to figure out impacted commit ranges (accounting for cherry picks) and versions/tags.

As such, each vulnerability undergoes automated bisection and impact analysis to determine precisely affected commit and version ranges.

Going a step further, OSV also provides an API to search for vulnerabilities that lets users query whether or not their versions are impacted.

curl -X POST -d \
'{"commit": "6879efc2c1596d11a6a6ad296f80063b558d5e0f"}' \
"https://api.osv.dev/v1/query?key=$API_KEY"

Currently the database is hosting information on about 380 mission critical open source projects, with vulnerabilities identified by Google's fuzzy testing tool, OSS-Fuzz.

The full list of the projects supported can be found here:
https://github.com/google/oss-fuzz/tree/master/projects, but some of the eye-catching ones tracked are: 

• libressl
• libpcap
• kubernetes
• imagemagick
• gitea
• firefox
• ffmpeg
• expat
• django 

OSV's main website and documentation are available at https://osv.dev.

More Information

OSV main 

OSV Github

Related Articles

The State Of Secure Software Development - Three OpenSSF Courses

Semgrep - More Than Just a Glorified Grep

EU Bug Bounty - Software Security as a Civil Right 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info