Vulnerability Scoring Systems

AttackForge empowers security teams to prioritise and score vulnerabilities using any existing industry framework like CVSS, DREAD, OWASP Risk Rating Methodology; or a custom framework tailored to the needs of the organization; or multiple frameworks on the same project and vulnerability - for a complete perspective.

Using multiple vulnerability scoring systems together provides several important advantages in security assessments:

  • Complementary perspectives. Each system emphasizes different aspects of risk. CVSS focuses heavily on the technical characteristics of a vulnerability - exploitability, impact on confidentiality/integrity/availability. DREAD brings in factors like discoverability and the number of affected users, which CVSS doesn't directly address. The OWASP Risk Rating Methodology layers in business impact and threat agent factors, tying vulnerabilities more closely to organizational context. Together, they paint a fuller picture than any single system alone.

  • Better prioritization. A vulnerability might score high on CVSS due to its technical severity but rank lower when DREAD or OWASP factors reveal it's hard to discover, affects few users, or has minimal business impact. Conversely, a technically moderate vulnerability might become urgent when business context shows it affects a revenue-critical system. Cross-referencing scores helps teams avoid both over-reacting and under-reacting.

  • Audience-appropriate communication. CVSS scores are widely recognized and useful for communicating with technical teams and in compliance contexts. OWASP's business-impact dimension makes it easier to explain risk to executives and stakeholders. DREAD's intuitive categories (how reproducible is it? how exploitable?) can be useful in quick triage discussions. Having multiple frameworks lets you speak the right language to each audience.

  • Reduced bias and blind spots. Every scoring system has limitations. CVSS, for example, has been criticized for score inflation and for not accounting for environmental context well in its base score. DREAD is sometimes seen as too subjective. Using multiple systems creates a check against the weaknesses of any single one - if all three frameworks agree a vulnerability is critical, you can have higher confidence in that assessment.

  • Flexibility across contexts. Some systems work better for certain situations. CVSS is standard for published CVEs and vendor advisories. OWASP's methodology suits application-level risk assessments during development. DREAD can be useful for rapid internal triage. Having fluency in all three lets a security team pick the right tool for the situation or combine them as needed.

The main trade-off is additional effort - maintaining multiple scoring workflows takes more time and can introduce confusion if scores conflict without clear guidance on how to reconcile them. Most mature security programs address this by designating a primary system (often CVSS for its industry adoption) and using the others as supplementary lenses during prioritization discussions.

Default Scoring Systems

AttackForge includes the following vulnerability scoring systems out-of-the-box on new deployments:

Creating a Custom Scoring System

You can create and manage your vulnerability scoring systems in Administration > Vulnerabilities > Scoring:

Start by clicking on Add Custom Scoring System.

The Scoring System is made up of the following components:

  • Name

    • This is the name of the scoring system

  • Key

    • This is the unique identifier for the scoring system, which is used in scripts, APIs, etc.

  • Info

    • This is an optional field to help describe the purpose and function of the scoring system.

  • Form

    • This is where you can create your own Sections and Fields which relate to your scoring system.

    • These fields will show when a vulnerability is getting scored during vulnerability creation or modification.

    • These fields may optionally show when viewing a vulnerability, to provide context on how the vulnerability was scored.

  • Priority Script

    • This is the logic used to calculate the vulnerability priority.

Form

The Scoring Form is made up of Sections and Fields which are presented to users to help them score vulnerabilities, and to help understand the context for how the vulnerability was scored.

Priority Script

The Priority Script is where you configure the logic to calculate the vulnerability priority.

The Priority Script can factor in context from the following locations:

  • Current scoring system

  • Other scoring systems in use on the same project

  • Vulnerability system fields and custom fields

  • Writeup fields

  • Affected Asset fields

  • Project system fields and custom fields

The Priority Script must return one of the following values:

  • Critical

  • High

  • Medium

  • Low

  • Info

Applying Scoring Systems to Projects

When creating or modifying a project - you can select from the available scoring systems:

Projects can have as many scoring systems assigned as desired.

Scoring systems can be marked as Required. This means the person scoring vulnerabilities must use that scoring system.

Scoring systems can also be ordered from top to bottom, which controls the order in which the scoring systems are presented and also the relevance to the Priority on the vulnerability. In the event where multiple scoring systems have conflicting ratings, the highest ordered scoring system takes precedence.

Access to Scoring Systems

Every Custom Scoring System assigned to the project can have an access level applied to it. This determines whether a user viewing the vulnerability can see how the vulnerability was scored.

In some cases, you may choose to withhold the details on how the vulnerability was scored using the custom scoring systems. In these cases, you can adjust the Access Level and Roles on the scoring system which sets the lowest project access level that has access to the scoring system.

Using Scoring Systems on Vulnerabilities

When creating or modifying a vulnerability, the assigned scoring systems to the project will become accessible on the vulnerability form:

Mandatory scoring systems will have a red dot indicating a score is required.

When you click on any of the scoring systems, the relevent form will be presented where you can enter in the scoring values:

After you fill in the scoring details, the Priority will be updated. You can override the Priority manually. AttackForge will indicate where a Priority does not align with existing scoring systems:

Scoring System Priority Scripts

DREAD Threat Model

This example assumes that you have the following fields configured on this scoring system:

Each field is a SELECT field which has a value of 1 to 10.

OWASP Risk Rating Methodology

This example assumes that you have the following sections and fields configured on this scoring system:

Likelihood Factors:

Impact Factors:

Each field is a SELECT field which has a value of 0 to 9.

Custom 4x4 Risk Scoring

This example is based on a standard 4x4 risk matrix:

This example assumes that you have the following fields configured on this scoring system:

Last updated