Blog
2024 has been an even more eventful year for OSV.
We’re excited to announce that OSV.dev’s API now allows you to query all our supported Linux distributions! From now on, any new Linux distribution adopting the OSV Schema will be instantly available for querying as soon as it’s imported by OSV.dev!
OSV’s mission is to enable developers to reduce security risk arising from known vulnerabilities in open source components they use.
Part of the strategy to accomplish that mission is to provide a comprehensive, accurate and timely database of known vulnerabilities covering both language ecosystems and OS package distributions.
Today, OSV.dev’s coverage is fast approaching 30 ecosystems, while also importing records from almost as many disparate “home databases”. As this number of federated data sources continues to grow, so does the prospect of OSV records being expressed in ways that are detrimental to them being effectively utilized in aggregate.
To ensure the accuracy and usability of OSV.dev’s data at scale we have initiated a program of work to prevent future regression in data quality as the ecosystem of data contributions continues to grow.
Chainguard has recently started publishing their security advisories in OSV, and these are now feeding into the OSV.dev database. This expands OSV.dev’s coverage of Linux distributions, by including security advisories for Wolfi.
We are excited to announce that OSV-Scanner now supports transitive dependency scanning for Maven pom.xml.
This highly requested feature empowers you to detect vulnerabilities in both your direct and indirect dependencies in the Maven ecosystem, giving you a complete picture of your Maven-based project’s known vulnerable dependencies. With this feature, OSV-Scanner fixes one out of two ecosystems/formats when it comes to transitive scanning capabilities.
Addressing vulnerabilities in project dependencies can often be overwhelming for software developers. OSV-Scanner’s new Guided Remediation feature aims to simplify this process by prioritizing and fixing the vulnerabilities that matter most in your projects.
As part of OSV’s strategy to be a comprehensive, accurate and timely database of known vulnerabilities, we’re excited to announce that we now support CURL advisories in the OSV database, thanks to REST API contribution support. CURL has been providing vulnerability records in the OSV format for a while, but they haven’t been able to be imported until now.
2023 has been a very eventful year for OSV.
OSV is committed to bringing our users comprehensive, accurate and timely open source vulnerability information. Over the last year, we’ve released a number of new features in pursuit of this goal including:
- OSV-Scanner’s call graph analysis for Go and Rust
- Adding six new ecosystems to the database
- The determineversion API, which expanded access to C/C++ vulnerabilities for OSS-Fuzz projects
Today we are announcing that OSV advisories now include vulnerable commit ranges. Vulnerable commit ranges, along with the previously announced experimental determineversion API, will enable vulnerability management for software with C and C++ dependencies, which has been one of the last gaps in coverage in OSV.dev’s database. Additionally OSV-Scanner is now compatible with C and C++ projects.
With the increasing incidence of software supply chain attacks, it is more important than ever for developers to understand the known vulnerabilities in their open source dependencies, regardless of the ecosystem of origin. The determineversion API is OSV’s newest tool that will help C/C++ developers match their dependencies to known vulnerabilities.
Within the C/C++ ecosystem it is difficult to match dependencies to vulnerabilities for a few reasons:
- C/C++ does not have a centralized package manager like npm or pyPI
- Software projects typically pull in C/C++ by submodules or vendoring
- Source code identifiers (e.g. git hashes) are the best way to identify libraries, but vulnerabilities are typically associated to versions, not git hashes
OSV has had C/C++ vulnerability data from OSS-Fuzz keyed on git hashes from day 1. However, a remaining challenge for C/C++ users is being able to accurately identify the closest upstream git hash of their C/C++ dependencies in order to make use of this vulnerability data. The OSV team is committed to bridging the gap between what C/C++ users need and the constraints of the ecosystem and the determineversion API is part of our plan for comprehensive C/C++ support.
Two new Linux distributions have been added to the OSV database. With the addition of AlmaLinux and Rocky Linux, the OSV database is now made up of advisories from 18 sources, including language ecosystems and Linux distributions.
We are excited to announce that OSV has published our new service level objectives (SLOs).
If you’ve recently been in the space of vulnerability management and the discussions around the White House Executive Order on Improving the Nation’s Cybersecurity (EO), you’re probably familiar with concepts such as Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX).
A VEX document/statement—a form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities—provides a great starting point in prioritizing vulnerability response and automating risk evaluation of software, especially for software consumers. There has already been a lot of coverage on consuming and using VEX for vulnerability management. However, there has not been much conversation around the generation of VEX documents. For producers, the process of creating a VEX statement today is largely a manual and cost-intensive process.
We are pleased to announce that Renovate has incorporated an OSV database check as an experimental feature.
We’re excited to launch our own OSV blog, where we’ll be posting project news and technical blog posts related to vulnerability management.