It’s one thing to know that a security vulnerability exists within an API you use. It’s quite another to know how serious the risk is, and how likely it is to cause a breach in your environment. One of the most important API security tools you’ll ever use? Simple: learn your score in the CVSS.

What is CVSS? Understanding the Common Vulnerability Scoring System

The Common Vulnerability Scoring System (CVSS) is a public information repository that assigns a score to known software vulnerabilities based on their severity and scope. The goal of the scores is to help developers, IT admins and other stakeholders easily determine which vulnerabilities require urgent attention, and which are less critical. Review previous real-world API security breaches and you’ll see they can spring from a wide range of vulnerabilities. It’s your job to use the CVSS to identify where you’re most vulnerable.

"It’s designed to provide open and universally standard severity ratings of software vulnerabilities," notes the National Infrastructure Advisory Council. You can use it to inform your API security tools and better understand the metrics that determine your overall security score. The scores are based on three main metrics: Base, temporal and environment:

CVSS assigns overall scores to each vulnerability by assessing these metrics in tandem.

The most important set of metrics for CVSS score calculation are those in the base category:

• Attack vector: How the vulnerability can be exploited.
• Attack complexity: The difficulty of achieving the condition that must exist in order to exploit the vulnerability.
• Privileges required: The level of privilege an attacker must possess in order to exploit the vulnerability.
• User interaction: The requirement for a human user other than the attacker to participate in the exploitation of a vulnerable component.
• Scope: The number of resources impacted by the vulnerability (in other words, whether the vulnerability impacts just one part of an application or environment, or many).
• Confidentiality: The impact of the amount of confidential information that the vulnerability places at risk.
• Integrity: The extent to which the vulnerability disrupts the integrity and health of an environment.
• Availability: The degree to which the vulnerability may cause a resource to become unavailable.

For example, consider an API vulnerability that can be exploited by any user on the Internet to access highly sensitive data or cause a total disruption to a critical system. This type of vulnerability would receive a high CVSS score given its ease of exploitation, its scope and the confidentiality and availability risks it poses. The infamous remote code execution (RCE) vulnerability in Log4Shell is one example of this, its CVSS score was 10/10. On the other hand, an API vulnerability that can only be exploited by privileged users under very specific environment configurations would receive a relatively low CVSS score. So would a vulnerability that doesn’t place critical information at risk, or that only impacts a non-critical component of a system.

Additional CVSS metrics

The temporal and environment metrics are considered non-mandatory when calculating CVSS scores, but they are often used to provide additional context for score calculation. In the temporal category, these additional calculation factors include:

• Exploit code maturity: An assessment of how likely it is that the vulnerability will be exploited by real-world threat actors.
• Remediation level: How difficult it is to remediate the risk.
• Report confidence: The level of confidence that security researchers have in the accuracy of their vulnerability assessment.

There are also non-mandatory metrics in the environment group category:

• Confidentiality requirement: Whether confidential information is necessary to exploit the vulnerability.
• Integrity requirement: The risk that environmental integrity will be lost during an exploit. Availability requirement: The risk that environment availability will be lost during an exploit.

• Modified attack vector: Whether the environment can be modified to enable the exploit.

• Modified attack complexity: When the environment can be modified to simplify vulnerability exploitation.
• Modified privileges required: Whether attackers can modify privileges to exploit a vulnerability that they otherwise would not have privileges to exploit.

• Modified user interaction: Whether attackers can manipulate user interactions to simplify attack.

• Modified scope: Whether attackers can extend the scope of an attack beyond the base components it affects.
• Modified confidentiality: Whether the attacks can be modified to access additional confidential information.
• Modified integrity: Whether the exploit can affect the integrity of the environment in additional ways when the environment is modified.
• Modified availability: Whether the exploit can cause a greater disruption to environment availability in a modified environment.

The environment metrics allow analysts to adjust scores by considering how a vulnerability could be exploited, and which impact it could have, based on different environment configurations. This refers to types of operating systems, software libraries, access control frameworks, and so on. Once you have your score, you can better assess how you’re using your API security tools—or if you’re not using them enough.

Vulnerability assessment scoring in Panoptica

Panoptica, Cisco’s cloud application security solution, uses data from the Common Vulnerability Scoring System (CVSS) to not only identify API vulnerabilities but also to score and assess them to provide deep visibility into the severity of the threat. (Note: vulnerability scanning is also a chief feature of KubeClarity, which you can read about on our blog.)

You can access CVSS scores on the Web. But with Panoptica, there’s no need to hunt down this information in your browser. Panoptica displays CVSS data right alongside information about API vulnerabilities that Panoptica discovers. For each image, you’ll see a list of vulnerabilities, along with a score:

In addition to displaying the CVSS score, Panoptica breaks it down so you know why the vulnerability received the score it did.

This data is based on CVSS scores, but it’s more than that. Panoptica also identifies the variables used in your environment to provide the most accurate score assessment possible. For example, Panoptica considers factors like attack complexity based on your configuration. If attack complexity is low, the vulnerability score will be higher. Attacks that are more complex, and therefore harder to execute, will receive lower scores.

As another example, take an attack vector, which identifies how a given vulnerability can be exploited. If the attack vector is present in your configuration, the vulnerability will receive a higher score than it would if the attack couldn’t actually be executed in your environment. 

Likewise, attack scores will be higher if the privileges required to execute the attack are available to attackers based on your configuration. In total, Panoptica relies on eight variables to determine how vulnerable each API is in your setup. With this information, you can make informed decisions for yourself about how to handle each vulnerability. For vulnerabilities with high scores, you’ll probably want to act urgently by blocking vulnerable requests. Lower-scored vulnerabilities may not require immediate action.

Winning the battle with API security tools

Knowing which API security vulnerabilities exist in your environment is only half the battle. What really matters is gaining the visibility and clarity necessary to determine how serious a given vulnerability is. Panpptica makes this easy to do. By leveraging CVSS data and customized assessments of your environment, Panoptica delivers tailored vulnerability scoring to help you react as effectively as possible to whichever risks may arise in your environment. Learn more by requesting a Panoptica trial.