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.