A contextual CvSS scoring system allows opted-in vulnerability disclosure programs to combine the consistency of the industrialised CvSSv3 standard with their respective business context. Since every company has different risk and threat models, the final impact severity of vulnerability can only be determined after thorough examination by the security analysts. While the final severity assessment is made at the discretion of the participating company, the following formula serves as a guideline when suggesting the report’s severity.
CCvSS = CVSSv3 base score + business impact modifier (optional)
Intigriti uses the CVSSv3 industry standard as a baseline for severity scoring. Regardless of the numeric scoring, there can always be escalating or mitigating factors given the provided context.
For example, vulnerability submissions resulting in potential revenue losses can be highly contextual, especially in situations where there is no direct financial gain for the attackers (e.g. bypassing a payment wall). Similarly, a vulnerability in highly sensitive or exposed business components may have some indirect consequences, such as reputational damage. Companies may decide to reclassify a vulnerability when contextual mitigating or escalating factors arise. Whenever a business impact modifier is evoked, this will be clearly and transparently communicated towards the researcher. A business impact modifier can only downgrade the severity score as calculated by the CVSSv3 calculator by maximum one category, but can upgrade the score to any category.
Intigriti strives to provide seamless communication and cooperation between companies and security researchers. In the event of any disputes regarding the outcome of a vulnerability report, the Intigriti mediation team will examine the situation from a neutral point of view and provide advice if needed.
Base score using CVSSv3
The severity of a vulnerability is calculated by using the CVSS v3 calculator. Intigriti uses the base metrics to calculate the CVSS v3 score. The critical to exceptional category is reserved for exceptional issues that reflect a CVSSv3 score of 9.5 - 10.0.
The CVSSv3 score is calculated using the following metrics:
This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base score) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component.
This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. Such conditions may require the collection of more information about the target, the presence of certain system configuration settings, or computational exceptions.
NOTE: These conditions also include the effort required to pull off a successful attack (not finding it). Conditions that make a vulnerability less scalable or convenient to exploit against a larger group of users will have a higher complexity (for example: the need to bruteforce or obtain a certain value such as a non-numeric ID, timing attacks, only works on specific browsers,…).
This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. This metric is greatest if no privileges are required.
NOTE: Accounts obtained through public registration without prior approval are considered non-privileged. This does not apply for leaked or provided credentials.
This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner. This metric value is greatest when no user interaction is required.
NOTE: We consider every action a separate user has to take as user interaction, even if it is just visiting a link or performing an action within the application. An exception can be made for situations in which the attack is automatically triggered within a common user flow (for example: "wormable" stored XSS on the front page) or in a feed or component that is part of the core business case (for example: CSRF by opening an e-mail in an e-mail client). Exceptions are made at the discretion of the program owner.
When the vulnerability of a software component governed by one authorisation scope is able to affect resources governed by another authorisation scope, a scope change has occurred.
NOTE: We consider the scope as changed if the new scope is also indirectly covered by the bug bounty program (for example: if you can leverage a vulnerability in the application layer to gain control over the network layer). We only consider scope changes that result in a higher authorisation level for the attacker (e.g. from the web application to the local file system or network, but not from the web application to the browser).
This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorised users, as well as preventing access by, or disclosure to, unauthorised ones.
There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is constrained. The information disclosure does not cause a direct, serious loss to the impacted component.
There is no loss of confidentiality within the impacted component.
This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.
There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.
Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is constrained. The data modification does not have a direct, serious impact on the impacted component.
There is no loss of integrity within the impacted component.
This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component.
0.1 - 3.9
4.0 - 6.9
7.0 - 8.9
9.0 - 9.4
9.5 - 10.0
A recurrent question when reporting vulnerabilities is whether to group them into a single report or send multiple reports.
Each vulnerability should have its own report, except in the following situations
If the same bug, with the same root cause, affects multiple URLs or assets, send a single report mentioning all vulnerable endpoints. This includes structural issues (asset-wide vulnerabilities such as a CSRF affecting most endpoints of a site).
If you are reporting a bug chain, include everything in the same submission. The impact of the total chain will be taken into account for calculating the bounty.
In the bug bounty industry, duplicate reports are reports where described behaviour, its exact location and cause within the codebase and the security consequences linked to it are already known to the customer/bug bounty vendor in an "open" or "accepted risk" submission. The duplicate report does not raise the priority, severity, or change resolution steps from the initial assessment.
Intigriti highly recommends to request the involved researcher to verify the patch before closing a submission. A bonus can be used to incentivise the researcher to test the fix.
A bypass is found for a previously reported, but fixed issue.
We do not consider this a duplicate. Once the report is closed, it is considered fixed. If a security researcher manages to get around the patch, they will receive a bounty according to its severity.
CSRF protection is missing throughout the whole website, multiple CSRF reports come in.
We consider this a duplicate: this is a structural issue, most to all endpoints are affected, and no extra bounties can be claimed for additional reports. The customer is aware that CSRF protection is missing in general, additional reports provide no extra value and the issue can be fixed with one change (the implementation of CSRF validation in the request controller). The prevalence of the issue may be considered when determining the severity of the initial report.
XSS vulnerabilities have been found on some but not all endpoints throughout the app
We do not consider these reports a duplicate if there is no common root cause: every finding is unique and requires a separate fix. The fix for the initial XSS would not have fixed the other XSS vulnerabilities. The customer can request a timeout to conduct a full assessment by suspending the program temporarily or putting XSS out of scope for the time being.
Excluding chain: A SSRF vulnerability is discovered that utilises an internally known open redirect
We do not consider the SSRF report a duplicate, even though it leverages a known or out of scope behaviour. The SSRF vulnerability itself is useless without the open redirect, but the SSRF leverages its impact and the initial report gets reprioritised. A bounty is paid out according to the severity of the SSRF. No separate bounty is awarded for the open redirect.
We consider this report a duplicate, as the severity of an open redirection issue is lower than the severity of XSS. The severity of the initial report is not changed nor reprioritised.
We do consider this report as a duplicate, but highly recommend to reward a bonus for the raised severity. Since the severity of the XSS is higher than the initial report (open redirection). The difference between the new severity and the old severity gets paid. If a low (€100) issue gets upgraded to a medium (€500), €400 will be paid as a bonus.
Regression: an IDOR was reported. The exact same issue was reported, fixed and closed earlier. Due to a regression, the vulnerability reappears.
We do not consider this report a duplicate, as the initial ticket was closed and would not have been fixed without the new report.
Severities within our platform only reflect the severity in regard to the security impact of a certain behaviour and may not directly reflect the internal prioritisation. As new threats emerge, we will continue to update this standard.
Intigriti’s vulnerability analysis and mediation team will take the guidelines above into consideration when providing advice. The final decision to accept or reject a report, or to set the severity lies with the program owner.