The Common Vulnerability Scoring System (CVSS) is an open standard for assessing the severity of security vulnerabilities. “Common” being the keyword, indicating that CVSS is designed to not only be independent to a specific vendor or industry, but also interoperable across systems that vary in size and scope. This is not only a great initiative but it also attempts to provide an open scoring standard which is understood and actively contributed by the security community—making it effective and efficient to use in many different fields and industries.

A CVSS score classifies a vulnerability based on the potential impact inflicted on the host where the vulnerability resides. This takes into consideration the nature of data that may be compromised by evaluating a series of metrics such as Attack Vector, Attack Complexity and also Privileges Required which is a new metric available in CVSS version 3.

Network vulnerabilities were far more common in the past, and CVSS v2 did a very good job at classifying these. Over the years there has been a rise in web application vulnerabilities which demanded a more granular and accurate scoring system to accurately reflect the severity of both network and web application vulnerabilities.

Since June 2012, FIRST (Forum of Incident Response and Security Teams) have been working on the newer version of CVSS—CVSS version 3 which became available on June 10th 2015. CVSS version 3 aims to provide clearer, consistent and accurate scores for modern day vulnerabilities.

As an example, let’s look at the OpenSSL Heartbleed Vulnerability (CVE-2014-0160)—a vulnerability that took the Internet by storm. Heartbleed’s CVSS v2 Base Score is that of 5.0 out of 10. Such a score was deemed too low for a vulnerability that could potentially disclose sensitive or secret information from a vulnerable server’s memory.

With the change in score interpretation from CVSS v2 to CVSS v3, as well as the new CVSS v3 metrics (namely, Privileges Required and Scope); vulnerabilities such as Heartbleed, now score a more accurate Base Score of 7.5 out of 10, in contrast to its 5.0 out of 10 Base Score in CVSS v2 score.

Other examples would include a Cross-site Request Forgery vulnerability in SearchBlox (CVE-2015-0970) which has a CVSS v2 score of 6.8 and a CVSS v3 score of 8.8 as well as a Stored SQL Injection vulnerability in MySQL (CVE-2013-0375) scoring 5.5 in CVSS v2 and 6.4 in CVSS v3.

This goes to show that CVSS version 3 improves the accuracy and consistency of web application related vulnerabilities which makes it more relevant to a web application scanner, such as Acunetix.

Acunetix provides CVSS as a scoring guideline for professionals who need to use CVSS for Compliance or when the vulnerabilities identified by Acunetix need to be prioritised with bugs identified by other vulnerability management systems. Acunetix Web Vulnerability Scanner v10.5 ships with support for CVSS v3 to allow users to better categorise web vulnerabilities identified by Acunetix.

Juxhin Dyrmishi Brigjaj

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.

  • Hi,

    I have a some what different question and idea’s regarding the integration of Acunetix in a building environment. I was hoping to find some better support in version 10.5 but…..

    Would it be possible to implement:

    1. An API with unlimited API keys:

    The idea is to use Acunetix’s API within our building environment. Each application is required to be able to identify themselves using a unique API key. Using the API, a nightly scan can be performed for all of our applications.

    The next step brings me to the following idea.

    2. Integration with Threadfix

    It would be nice to see an option to configure a Threadfix URL (like the Burp plugin) that once a scan has been performed, the results can automatically be uploaded in Threadfix.

    I think for larger organisation, the above described idea’s will be a great addon.

    • Hi,

      Thanks for your comments.

      1. Our current API does not use API keys. This feature is on the roadmap, and will probably be available in the upcoming version.

      2. Acunetix is already integrated in Threadfix, as in users can upload the saved scan XML results to Threadfix for further processing. However this needs to be done manually at the moment. I will look into this further, and will let you know if we identify a way to automate it.

      I would be interested in knowing how you are performing the scans i.e. are you scanning from the Acunetix UI, or via CLI or API?

  • Comments are closed.