A brief look at SUSE’s CVE tracking process for automotive

What is a CVE?

When a security vulnerability in a given software package becomes known, a response must be mounted in order to minimize the probability of malicious actors gaining access to protected computer systems and networks. For serious vulnerabilities, the response involves a number of entities working together, motivated by the common interest of keeping their systems and networks free of malicious interference. When a vulnerability affects a package that they ship, operating system vendors are typically involved, since they have a vested interest in maintaining their products free of unpatched serious security vulnerabilities.

Since 1999, publicly-known security vulnerabilities have been tracked by the Common Vulnerabilities and Exposures (CVE) system, which is operated by The MITRE Corporation with funding from the U.S. government. Over time, this system has become a de facto standard. One of the first things that happens when a vulnerability becomes known is that the vulnerability gets assigned a CVE identifier (CVE number). The importance of having a standard, unique identifier for each vulnerability is difficult to overstate, and the CVE system does a good job of providing that. Once assigned, the CVE identifier can be cited in bug reports, threat analyses, etc. to facilitate communication.

The CVE identifier is linked to a description of the vulnerability. In addition to briefly explaining the nature of the vulnerability and how it might be exploited, a good CVE description will make it clear which package(s) the vulnerability affects. Ideally, it will also clearly state which version (or version range) of the package is affected and link to other sources of information regarding the vulnerability.

Each year, thousands of CVE identifiers get assigned to vulnerabilities (and potential vulnerabilities) in various software packages. Operating system vendors such as SUSE need to carefully track CVEs in order to be able to answer questions like: “I have a system running SUSE product xyz. Does CVE such-and-such affect that system?” and “When will the CVE get patched?”

Not all CVEs are created equal

Anoher aspect that customers are very concerned about is the relative severity of each CVE. Certain vulnerabilities (for example, those that can be triggered/exploited remotely) are considered more severe than others and there is a detailed methodology for evaluating that – the Common Vulnerability Scoring System (CVSS), version 3.1. Due to the difficulty of gaining an in-depth understanding of each CVE, of which there are potentially thousands, customers rely on companies like SUSE to judge the relative severity of CVEs by applying the CVSS standard to produce a severity score. Due to the subjective nature of applying CVSS 3.1 to arrive at a severity score, the various entities that publish these scores often arrive at differing scores for a given CVE. SUSE publishes its own severity scores for CVEs and uses these exclusively in its internal decision-making.

How does SUSE track CVEs?

At SUSE, when we learn about a CVE affecting a package that ships as part of one of our products, an internal tool called SMASH (an acronym that stands for “SUSE Maintenance And Security Helper”) picks up the CVE and a security engineer, after analyzing the issue, determines whether the CVE affects any SUSE products. Then, if our products are affected, the engineer continues to investigate which software, software version, products, and codestreams are affected. At this time, the security engineer also determines a CVSS 3.1 rating for the CVE. All of this information is entered into SMASH. At this point, a bug report is opened for the CVE in our bug tracking system, https://bugzilla.suse.com. This bug report gets assigned to the software package’s maintainer, whose job it is to give a second look at the vulnerability, express an opinion on it, and then develop and submit a fix. Finally, the SMASH data is used to create and populate the customer-facing CVE pages under https://www.suse.com/security/cve/index.html.

When it comes to CVEs, the automotive industry is “special”

SUSE’s Automotive team customizes SUSE’s enterprise products for use in embedded systems such as cars. Automotive customers ask the same questions as other enterprise customers. They know which vehicles are running which versions of our operating system, and they want to know whether these versions are affected by CVEs above a certain severity threshold. Some customers are happy to use SUSE’s CVSS scores, but others prefer to use NVD’s scores. In addition, they also need regular reports on outstanding CVEs affecting their vehicles, and they have specific requirements regarding the content and form of said reports.

It is of course possible to answer these questions and prepare these reports manually, by querying SMASH and Bugzilla. However, this is a time-consuming and error-prone process. It is better to track all the CVEs up front, in a CVE database, and maintain tooling that allows us to query the database and generate reports as needed. What we need, then, is an “automotive-specific” view of the CVE data, suitable for quickly answering the questions our customers ask us and generating the reports they require for their compliance efforts. Fortunately, we don’t need to start from scratch because SMASH provides a REST API that we can use to get at the CVE data.

Generating CVE tables and reports with cvetool

The SUSE Automotive Engineering team maintains a tool, called “cvetool”, which crunches the raw CVE data from SMASH, extracts the relevant information and presents it to us in a form that makes it easy to answer customers’ questions regarding CVEs. Since this information needs to be updated continually, automation of the update process is crucial. Some of the information specific to the automotive use case and needed by our customers is not included in what we get from SMASH, so we have to add it, at least for those CVEs whose severity rating is above the customer’s reporting threshold. Thus, with the help of cvetool, selected data obtained from SMASH are combined with the results of our internal investigations to produce a set of CVE tables which are stored in git and uploaded regularly to SUSE’s internal Confluence instance for display and perusal. This also allows various views and exports on the data: CVEs sorted by year, CVEs fixed in given releases, outstanding CVEs by package or severity score, etc. The tool also knows how to generate CVE reports that can be tailored to meet each customer’s individual compliance requirements.

cvetool – Confluence view