Skip to main content

CVE Tracker: A New Motional Open-Source Tool for Tracking Common Vulnerabilities and Exposures

June 08, 2022 Garth Scheidemantel, Senior Specialist, Cybersecurity Cybersecurity

The moment a product is released, it is exposed to a world that will test its security posture.

After the product has been released, malicious actors can spend as much time as they want looking for ways to exploit it. One way that a product’s security can be undermined is by vulnerabilities in dependent components.

If we care about the security of the product, it is not good enough to just build it using common security engineering practices. We must also actively be on the lookout for new vulnerabilities so that we can take appropriate actions to address these weaknesses.

To help us stay aware of vulnerabilities in our products, Motional has created — and is making publicly available — an open-source tool called the CVE Tracker [1], which tracks emerging Common Vulnerabilities and Exposures, known as CVEs. By identifying emerging issues, we can plan and prioritize a response that preserves the integrity of the product.

There are tools on the market to track CVEs that cover the most common cases, often by scanning binaries or build files. While we do use some of these tools, we found blind spots due to the specific niche we live in within the embedded and self-driving domains. We created CVE Tracker to fill in those gaps. Having said that, CVE Tracker can fill in many kinds of CVE tracking gaps, and not just those related to the AV space.

What are CVEs?

CVEs are published by the MITRE Corporation to CVE List, after which they are analyzed by the National Institute of Standards and Technology and added, along with the institute’s analysis results, to the National Vulnerability Database (NVD) [2]. Each CVE describes a known vulnerability in a software component. Published CVEs could affect a wide variety of systems including servers, IoT devices, and airplanes. Of course there are also published CVEs pertaining to cars. For example, CVE-2022–27254 [3] describes a vulnerability in one popular consumer vehicle’s remote entry system. This vulnerability allows an attacker to intercept the RF signals normally sent from a remote key fob to the car and re-send these at a later time to unlock the car [7]. It’s clear that cyber-based attackers are interested in targeting consumer vehicles. In order to protect our products and our customers, we need to be aware of these potential threats so that they can be addressed.

But staying on top of all potentially significant CVEs isn’t easy. New vulnerabilities are discovered and documented frequently against a wide variety of public and private systems. Given the increasing pervasiveness of computers and the increasing complexity of the software systems running on them, it should come as no surprise that the list of CVEs has grown explosively over the years. With thousands of vulnerabilities published each year, finding and managing CVEs that are relevant to our products is a challenge.

A chart showing how the number of CVEs has increased in recent years

From 2015 to 2020, the number of CVEs reported by MITRE grew 183%.

Each CVE follows a standard format to make it easy for humans and automated tools to read and manage. As you can see in the example below, each CVE contains the following fields (not exhaustive):

  • Description — Summarizes the finding so a human reader can quickly get a sense of what the CVE is about.
  • Severity — Provides a numerical assessment that attempts to convey the potential impact of the vulnerability.
  • References — Additional information from external sources that provide more information about the vulnerability. This can include news sources, bulletins, advisories, etc.
  • Affected Software Configurations — Includes a non-exhaustive list of software that is known to contain the vulnerability.

Example CVE

An image showing what a CVE looks like

A sample CVE as pulled from the National Vulnerability Database

What do we do with CVEs?

Searching the NVD database manually for new CVEs relevant to all of your products and all of their dependencies can be a lot of effort.

Motional has built CVE Tracker to help make this easier. CVE Tracker is an open-source, non-proprietary tool that will scan a project looking for files that define project dependencies for common package managers and build systems. Once all the dependent components are collected, the tool connects to the NVD database and looks for any CVEs pertaining to these components. The tracker then creates a report of any relevant CVEs that the user can reference to triage and fix any potential threats.

A sample CVE tracker report

A Motional CVE Tracker vulnerability report HTML header

The CVE Tracker supports parsing dependency files in multiple formats, creates reports in HTML and JSON, and has an optional email notifier that can alert your team when new CVEs are found.

As stated above, the list of CVEs continues to grow. This means that subsequent runs of the tool might return additional CVEs. In order to highlight new, unhandled CVEs and avoid inundating engineers with noisy, unhelpful results, the CVE Tracker maintains a database of previously discovered CVEs. On subsequent runs of the tool, it will check each CVE against the database and only report those that have not been seen already.

Example session

Here’s an example of how the CVE Tracker could help.

Before we blindly go installing dependencies from a public repository, it’s important to know if that repository contains any known vulnerabilities. For this example will be analyzing the vulnerability_files GitHub repository [4]. Note: this is a fake project created for this demo, it has no functionality, and the dependencies were picked solely to show examples of what one might monitor. Vulnerability_files is structured as follows:

The structure of our mock vulnerability_files repository

The structure of our mock vulnerability_files repository

Using the CVE Tracker we can scan the vulnerability_files repository to see if there are any CVEs associated with its dependencies. This is a hypothetical example of what a report identifying CVEs associated with the GitHub repository would look like:

A hypothetical example of what a report identifying CVEs associated with the GitHub repository would look like

As you can see CVE Tracker found the following CVEs in vulnerability_files:

FFmpeg 4.3.1

  • CVE-2022–1475

Elasticsearch 7.10.0

  • CVE-2021–22132
  • CVE-2021–22144
  • CVE-2021–22134
  • CVE-2021–22145

Opencv 4.1.0

  • CVE-2019–5064

Once the CVEs have been found, they need to be triaged and addressed. If this were one of Motional’s projects, we would create triage tickets for each of these issues and assign them to our engineering team if we determine they need to be addressed. Each CVE entry would have to be carefully assessed to determine its potential impact on the system and what remediations are available to us.

Here are some actions that we might take (keeping in mind that these are fictional examples):


CVE-2022–1475 [5] pertains to the FFmpeg library version 5.0.1 and earlier, the issue is in the file g729_parser.c where the function g729_parse() has an integer overflow vulnerability. After investigating, it may be determined that the project can never trigger this vulnerability. It would therefore be safe to ignore this CVE, in order to avoid the risk of unnecessarily introducing changes to vulnerability_files.

A hypothetical sample CVE action report


CVE-2021–22132 [6] pertains to Elasticsearch versions 7.7.0 to 7.10.1 and describes an information disclosure vulnerability in the async search API. After investigating, it is determined that vulnerability_files is indeed affected by this vulnerability, meaning that it may be possible for an attacker to leverage this vulnerability to gain some advantage not intended by the application design. The Elasticsearch dependency may be updated to the latest version (7.10.14 as of the time of this writing) in order to address this vulnerability.

A hypothetical example of what a report identifying CVEs associated with the GitHub repository would look like

And so on… Each CVE would be triaged, assessed, and resolved.

Collaborating Together

Hopefully you can see how CVE Tracker can be a useful tool to help ensure that our project teams are fully aware of any known security risks in our products, so that these can be addressed in a timely manner.

Motional has made this CVE Tracker available for public use because we believe combating cyber threats requires a collaborative effort. It also aligns with previous initiatives by Motional to make datasets and tools public to help advance AV research that would benefit us all.