Using CWE and CVSS scores to get more context on a security advisory

Security vulnerabilities can be unpleasant to address, and that only gets worse the more you have. When you’re dealing with a large volume of vulnerabilities, you need to be able to easily understand, compare, and prioritize them.

Security Advisories and GitHub Advisory Database now support Common Weakness Enumeration (CWE) and Common Vulnerability Scoring System (CVSS) information, letting you make a more informed decision on how to react to a vulnerability. In this post, we’ll dig into what these are, how they’re surfaced on GitHub, and how you can use them as part of your vulnerability response process.

CWE and CVSS are a common language to refer to weaknesses, exploitability, and impact

Publicly-known vulnerabilities have identification numbers, known as Common Vulnerabilities and Exposures (CVEs), that are issued by MITRE or other authorized bodies. Having a common identification format allows the security industry to talk about a vulnerability consistently, so that everyone is on the same page. CVEs are published in the National Vulnerability Database (NVD). GitHub’s Advisory Database contains information on vulnerabilities that affect open source software hosted on GitHub, with information coming from the NVD but also directly from maintainers who disclose security issues in their own projects via security advisories.

With the addition of CWEs and CVSS scores, each entry in the Advisory Database has more information to help you evaluate your risk if you’re impacted by that vulnerability, for example, if you receive a Dependabot alert for a vulnerable dependency. CWEs provide a consistent way of referring to software weaknesses, such as cross-site scripting or improper input validation. Basically, a CWE gives you more detail on the type of vulnerability that you’re dealing with.

In addition to maintainer-submitted advisories, we ingest data into the GitHub Advisory Database to power Dependabot alerts. For the ecosystems for which we curate vulnerability data, where available, the most common CWEs we’re seeing in open source packages on GitHub today are missing encryption of sensitive data and path traversal. See the top 25 CWE overall for comparison.

Table 1: Most common CWEs in GitHub Advisory Database

CVSS scores provide more detail as to why a vulnerability is considered to have a given severity (such as, critical, high, medium, or low), with a numerical score from 0.0 to 10.0. This looks at individual dimensions of the vulnerability itself, to see how easy it would be to exploit, and what the potential impact of exploiting it would be on the application. For example, a vulnerability that leads to remote code execution, one of the worst potential impacts, would have a high CVSS score and therefore a high severity. GitHub uses CVSSv3.1 to calculate CVSS scores.

Enter and view information as part of Security Advisories

To view information on an advisory, navigate to its entry in the Advisory Database. In the right hand bar, you can see the CWEs and CVSS score string. You can also search advisories by CWE.

If you’re a maintainer disclosing a vulnerability in your project, when you create a Security Advisory to disclose a vulnerability in your repository, you can now include the CWE and the CVSS score of the vulnerability, in addition to severity. You can use dropdowns to select relevant CWEs. If you’re already familiar with CVSS scores, you can input a CVSS vector string, and if you’re not, use the calculator to figure it out. If you’re less experienced in security, don’t worry. Just enter a severity, and our curation team will take a look.

Next time you receive a Dependabot alert and want to learn more, click through to the vulnerability in the Advisory Database to see CWE and CVSS information.

Written by

Maya Kaczorowski

@mayakacz