Common Weakness Enumeration

CWE Glossary Definition

The Common Weakness Scoring System (CWSS) provides a mechanism for prioritizing software weaknesses in a consistent, flexible, open manner. It is a collaborative, community-based effort that is addressing the needs of its stakeholders across government, academia, and industry.

Software developers often face hundreds or thousands of individual bug reports for weaknesses that are discovered in their code. In certain circumstances, a software weakness can even lead to an exploitable vulnerability. Due to this high volume of reported weaknesses, stakeholders are often forced to prioritize which issues they should investigate and fix first, often using incomplete information. In short, people need to be able to reason and communicate about the relative importance of different weaknesses. While various scoring methods are used today, they are either ad hoc or inappropriate for application to the still-imprecise evaluation of software security.

Software developers, managers, testers, security vendors and service suppliers, buyers, application vendors, and researchers must identify and assess weaknesses in software that could manifest as vulnerabilities when the software is used. They then need to be able to prioritize these weaknesses and determine which to remediate based on which of them pose the greatest risk. When there are so many weaknesses to fix, with each being scored using different scales, and often operating with incomplete information, the various community members, managers, testers, buyers, and developers are left to their own methodologies to find some way of comparing disparate weaknesses and translating them into actionable information.

Because CWSS standardizes the approach for characterizing weaknesses, users of CWSS can invoke attack surface and environmental metrics to apply contextual information that more accurately reflects the risk to the software capability, given the unique business context it will function within and the unique business capability it is meant to provide. This allows stakeholders to make more informed decisions when trying to mitigate risks posed by weaknesses.

CWSS is distinct from - but not a competitor to - the Common Vulnerability Scoring System (CVSS). These efforts have different roles, and they can be leveraged together.

CWSS offers:

• Quantitative Measurements: CWSS provides a quantitative measurement of the unfixed weaknesses that are present within a software application.
• Common Framework: CWSS provides a common framework for prioritizing security errors ("weaknesses") that are discovered in software applications.
• Customized Prioritization: in conjunction with the Common Weakness Risk Analysis Framework (CWRAF), CWSS can be used by consumers to identify the most important types of weaknesses for their business domains, in order to inform their acquisition and protection activities as one part of the larger process of achieving software assurance.

1.1 What is CWSS?

CWSS is organized into three metric groups: Base Finding, Attack Surface, and Environmental. Each group contains multiple metrics - also known as factors - that are used to compute a CWSS score for a weakness.

• Base Finding metric group: captures the inherent risk of the weakness, confidence in the accuracy of the finding, and strength of controls.
• Attack Surface metric group: the barriers that an attacker must overcome in order to exploit the weakness.
• Environmental metric group: characteristics of the weakness that are specific to a particular environment or operational context.

1.2 Other weakness scoring systems

Various weakness scoring systems have been used or proposed over the years. Automated tools such as source code scanners typically perform their own custom scoring; as a result, multiple tools can produce inconsistent scores for the same weakness.

The Common Vulnerability Scoring System (CVSS) is perhaps the most similar scoring system. However, it has some important limitations that make it difficult to adapt to software security assessment. A more detailed comparison is in Appendix A.

More details on other scoring systems, including adaptations to CVSS, are provided in Appendix B.

1.3 How does CWSS work?

1.3.1 Score Calculation

Each factor in the Base Finding metric group is assigned a value. These values are converted to associated weights, and a Base Finding subscore is calculated. The Base Finding subscore can range between 0 and 100. The same method is applied to the Attack Surface and Environmental metric group; their subscores can range between 0 and 1. Finally, the three subscores are multiplied together, which produces a CWSS score between 0 and 100.

1.3.2 Scoring Methods within CWSS

The stakeholder community is collaborating with MITRE to investigate several different scoring methods that might need to be supported within the CWSS framework.

Note that the current focus for CWSS is on the Targeted scoring method and a framework for context-adjusted scoring. Methods for aggregated scoring will follow. Generalized scoring is being developed separately, primarily as part of the 2011 Top 25 and CWRAF.

1.4 Who performs the scoring?

CWSS scores can be automatically calculated, e.g. by a code analysis tool, or they can be manually calculated by a software security consultant or developer. Since automated analysis is not likely to have certain information available - such as the application's operating environment - CWSS scoring could possibly be conducted in multiple rounds: a tool first automatically calculates CWSS scores, then a human analyst manually adds additional details and recalculates the scores.

1.5 Who owns CWSS?

CWSS is a part of the Common Weakness Enumeration (CWE) project, co-sponsored by the Software Assurance program in the office of Cybersecurity and Communications of the U.S. Department of Homeland Security (DHS).

1.6 Who is using CWSS?

To be most effective, CWSS supports multiple usage scenarios by different stakeholders who all have an interest in a consistent scoring system for prioritizing software weaknesses that could introduce risks to products, systems, networks and services. Some of the primary stakeholders are listed below.

As of July 2014 (when CWSS 0.8 was active), there are several real-world implementations of CWSS. The primary users have been code analysis vendors and software security consultants.

2.1 Metric Group Factors

CWSS contains the following factors, organized based on their metric group:

Each factor is described in more detail in subsequent sections.

2.2 Values for Uncertainty and Flexibility

CWSS can be used in cases where there is little information at first, but the quality of information can improve over time. It is anticipated that in many use-cases, the CWSS score for an individual weakness finding may change frequently, as more information is discovered. Different entities may determine separate factors at different points in time.

As such, every CWSS factor effectively has "environmental" or "temporal" characteristics, so it is not particularly useful to adopt the same types of metric groups as are used in CVSS.

Most factors have these four values in common:

2.3 Base Finding Metric Group

The Base Finding metric group consists of the following factors:

• Technical Impact (TI)
• Acquired Privilege (AP)
• Acquired Privilege Layer (AL)
• Internal Control Effectiveness (IC)
• Finding Confidence (FC)

The combination of values from Technical Impact, Acquired Privilege, and Acquired Privilege Layer gives the user some expressive power. For example, the user can characterize "High" Technical Impact with "Administrator" privilege at the "Application" layer.

2.3.1 Technical Impact (TI)

Technical Impact is the potential result that can be produced by the weakness, assuming that the weakness can be successfully reached and exploited. This is expressed in terms that are more fine-grained than confidentiality, integrity, and availability.

The Technical Impact should be evaluated relative to the Acquired Privilege (AP) and Acquired Privilege Layer (AL).

If this set of values is not precise enough, CWSS users can use their own Quantified methods to derive a subscore. One such method involves using the Common Weakness Risk Analysis Framework (CWRAF) to define a vignette and a Technical Impact Scorecard. The Impact weight is calculated using vignette-specific Importance ratings for different technical impacts that could arise from exploitation of the weakness, such as modification of sensitive data, gaining privileges, resource consumption, etc.

2.3.2 Acquired Privilege (AP)

The Acquired Privilege identifies the type of privileges that are obtained by an attacker who can successfully exploit the weakness.

Notice that the values are the same as those for Required Privilege, but the weights are different.

In some cases, the value for Acquired Privileges may be the same as for Required Privileges, which implies either (1) "horizontal" privilege escalation (e.g. from one unprivileged user to another) or (2) privilege escalation within a sandbox, such as an FTP-only user who can escape to the shell.

2.3.3 Acquired Privilege Layer (AL)

The Acquired Privilege Layer identifies the operational layer to which the attacker gains privileges by successfully exploiting the weakness.

2.3.4 Internal Control Effectiveness (IC)

An Internal Control is a control, protection mechanism, or mitigation that has been explicitly built into the software (whether through architecture, design, or implementation). Internal Control Effectiveness measures the ability of the control to render the weakness unable to be exploited by an attacker. For example, an input validation routine that restricts input length to 15 characters might be moderately effective against XSS attacks by reducing the size of the XSS exploit that can be attempted.

When there are multiple internal controls, or multiple code paths that can reach the same weakness, then the following guidance applies:

• For each code path, analyze each internal control that exists along the code path, and choose the Value with the lowest weight (i.e., the strongest internal control along the code path). This is called the Code Path Value.
• Collect all Code Path Values.
• Select the Code Path Value that has the highest weight (i.e., is the weakest control).

This method evaluates each code path in terms of the code path's strongest control (since an attacker would have to bypass that control), then selects the weakest code path (i.e., the easiest route for the attacker to take).

2.3.5 Finding Confidence (FC)

Finding Confidence is the confidence that the reported issue:

1. is a weakness, and
2. can be triggered or utilized by an attacker

2.4 Attack Surface Metric Group

The Attack Surface metric group consists of the following factors:

• Required Privilege (RP)
• Required Privilege Layer (RL)
• Access Vector (AV)
• Authentication Strength (AS)
• Level of Interaction (IN)
• Deployment Scope (SC)

2.4.1 Required Privilege (RP)

The Required Privilege identifies the type of privileges that an attacker must already have in order to reach the code/functionality that contains the weakness.

2.4.2 Required Privilege Layer (RL)

The Required Privilege Layer identifies the operational layer to which the attacker must have privileges in order to attempt to attack the weakness.

2.4.3 Access Vector (AV)

The Access Vector identifies the channel through which an attacker must communicate to reach the code or functionality that contains the weakness. Note that these values are very similar to the ones used in CVSS, except CWSS distinguishes between physical access and local (shell/account) access.

While there is a close relationship between Access Vector and Required Privilege Layer, the two are distinct. For example, an attacker with "physical" access to a router might be able to affect the Network or Enterprise layer.

2.4.4 Authentication Strength (AS)

The Authentication Strength covers the strength of the authentication routine that protects the code/functionality that contains the weakness.

When more than one authentication routine is in use, or if two or more code paths exist, the scoring should be performed as follows:

When there are multiple authentication routine, or multiple code paths that can reach the same weakness, then the following guidance applies:

• For each code path, analyze each authentication routine that exists along the code path, and choose the Value with the lowest weight (i.e., the strongest authentication routine along the code path). This is called the Code Path Value.
• Collect all Code Path Values.
• Select the Code Path Value that has the highest weight (i.e., contains the weakest routine).

This method evaluates each code path in terms of the code path's strongest authentication routine (since an attacker would have to bypass that control), then selects the weakest code path (i.e., the easiest route for the attacker to take).

2.4.5 Level of Interaction (IN)

The Level of Interaction covers the actions that are required by the human victim(s) to enable a successful attack to take place.

2.4.6 Deployment Scope (SC)

Deployment Scope identifies whether the weakness is present in all deployable instances of the software, or if it is limited to a subset of platforms and/or configurations. For example, a numeric calculation error might only be applicable for software that is running under a particular OS and a 64-bit architecture, or a path traversal issue might only affect operating systems for which "\" is treated as a directory separator.

2.5 Environmental Metric Group

The Environmental metric group consists of the following factors:

• Business Impact (BI)
• Likelihood of Discovery (DI)
• Likelihood of Exploit (EX)
• External Control Effectiveness (EC)
• Prevalence (P)

2.5.1 Business Impact (BI)

Business Impact describes the potential impact to the business or mission if the weakness can be successfully exploited.*

2.5.2 Likelihood of Discovery (DI)

Likelihood of Discovery* is the likelihood that an attacker can discover the weakness.

2.5.3 Likelihood of Exploit (EX)

Likelihood of Exploit is the likelihood that, if the weakness is discovered, an attacker with the required privileges/authentication/access would be able to successfully exploit it.

2.5.4 External Control Effectiveness (EC)

External Control Effectiveness is the capability of controls or mitigations outside of the software that may render the weakness more difficult for an attacker to reach and/or trigger. For example, Address Space Layout Randomization (ASLR) and similar technologies reduce, but do not eliminate, the chances of success for a buffer overflow attack. However, ASLR is not directly instantiated within the software itself.

When there are multiple external controls, or multiple code paths that can reach the same weakness, then the following guidance applies:

• For each code path, analyze each external control that exists along the code path, and choose the Value with the lowest weight (i.e., the strongest external control along the code path). This is called the Code Path Value.
• Collect all Code Path Values.
• Select the Code Path Value that has the highest weight (i.e., is the weakest control).

This method evaluates each code path in terms of the code path's strongest control (since an attacker would have to bypass that control), then selects the weakest code path (i.e., the easiest route for the attacker to take).

2.5.5 Prevalence (P)

The Prevalence* of a finding identifies how frequently this type of weakness appears in software.

This factor is intended for use in Generalized scoring of classes of weaknesses, such as the development of custom Top-N weakness lists. When scoring an individual weakness finding in an automated-scanning context, this factor is likely to use a "Not Applicable" value.

A CWSS 1.0 score can range between 0 and 100. It is calculated as follows:

BaseFindingSubscore * AttackSurfaceSubscore * EnvironmentSubscore

The BaseFindingSubscore supports values between 0 and 100. Both the AttackSurfaceSubscore and EnvironmentSubscore support values between 0 and 1.

3.1 Base Finding Subscore

The Base Finding subscore (BaseFindingSubscore) is calculated as follows:

Base = [ (10 * TechnicalImpact + 5*(AcquiredPrivilege + AcquiredPrivilegeLayer) + 5*FindingConfidence) * f(TechnicalImpact) * InternalControlEffectiveness ] * 4.0

f(TechnicalImpact) = 0 if TechnicalImpact = 0; otherwise f(TechnicalImpact) = 1.

The maximum potential BaseFindingSubscore is 100.

The definition of f(TechnicalImpact) has an equivalent in CVSS. It is used to ensure that if the Technical Impact is 0, that the other added factors do not inadvertently generate a non-zero score.

TechnicalImpact and the AcquiredPrivilege/AcquiredPrivilegeLayer combination are given equal weight, each accounting for 40% of the BaseFindingSubscore. (Each generate a sub-value with a maximum of 10). There is some adjustment for Finding Confidence, which accounts for 20% of the Base (maximum of 5). The InternalControlEffectiveness can adjust the score downward, perhaps to 0, depending on the strength of any internal controls that have been applied to the issue. After application of InternalControlEffectiveness, the possible range of results is between 0 and 25, so the 4.0 coefficient is used to adjust the BaseFindingSubscore to a range between 0 and 100.

3.2 Attack Surface Subscore

The AttackSurfaceSubscore is calculated as:

[ 20*(RequiredPrivilege + RequiredPrivilegeLayer + AccessVector) + 20*DeploymentScope + 15*LevelOfInteraction + 5*AuthenticationStrength ] / 100.0

The combination of required privileges / access makes up 60% of the Attack Surface subscore; deployment scope, another 20%; interaction, 10%; and authentication, 10%. The authentication requirements are not given much focus, under the assumption that strong proof of identity will not significantly deter an attacker from attempting to exploit the vulnerability.

This generates a range of values between 0 and 100, which are then divided by 100.

3.3 Environmental Subscore

The EnvironmentalSubscore is calculated as:

[ (10*BusinessImpact + 3*LikelihoodOfDiscovery + 4*LikelihoodOfExploit) + 3*Prevalence) * f(BusinessImpact) * ExternalControlEffectiveness ] / 20.0

f(BusinessImpact) = 0 if BusinessImpact == 0; otherwise f(BusinessImpact) = 1

BusinessImpact accounts for 50% of the environmental score, and it can move the final score to 0. ExternalControlEffectiveness is always non-zero (to account for the risk that it can be inadvertently removed if the environment changes), but otherwise it can have major impact on the final score. The combination of LikelihoodOfDiscovery and LikelihoodOfExploit accounts for 35% of the score, and Prevalence at 15%.

3.4 Additional Features of the Formula

There is significant diversity in the kinds of scores that can be represented, although the use of multiplication of many different factors, combined with multiple weights with small values, means that the range of potential scores is somewhat skewed towards lower values.

Since "Not Applicable" values have a weight of 1, the formula always has a potential maximum score of 100.0. In extremely rare cases in which certain factors are treated as Not Applicable (e.g., Technical Impact, Business Impact, and Internal Control Effectiveness), then the minimum possible score could be non-zero.

When default values are used for a large number of factors for a single score, using the median weights as defined in CWSS 1.0, the scores will skew heavily to the low side. The median weight for a factor does not necessarily reflect the most likely value that could be used, so the selection of Default weights may be changed in future versions. Ideally, the formula would have a property in which the use of many default values produces a score that is relatively close to 50; the selection of non-default values would adjust the final score upward or downward, thereby increasing precision.

The use of "Unknown" values also generally produces scores that skew to the low side. This might be a useful feature, since scores will be higher if they have more specific information.

Using the Codes as specified for each factor, a CWSS score can be stored in a compact, machine-parsable, human-readable format that provides the details for how the score was generated. This is very similar to how CVSS vectors are constructed.

Unlike CVSS, not all CWSS factors can be described symbolically with discrete values. Any factor can be quantified with continuous weights that override the originally-defined default discrete values, using the "Q" value. When calculated using CWRAF, the Impact factor is effectively an expression of 32 separate Technical Impacts and layers, many of which would not be applicable to a particular weakness. Treating each impact as a separate factor would roughly double the number of factors required to calculate a CWSS score. In addition, CWRAF's use of Business Value Context (BVC) to adjust scores for business-specific concerns also means that a CWSS score and its vector may appear to be inconsistent if they are "transported" to other domains or vignettes.

With this concern in mind, a CWSS 1.0 vector should explicitly list the weights for each factor, even though it increases the size of the vector representation.

The format of a single factor in a CWSS vector is:

FactorName:Value,Weight

For example, "P:NA,1.0" specifies a "Not Applicable" value for Prevalence with a weight of 1.0. A specifier of "AV:P,0.2" indicates the "Physical" value for Access Vector with a weight of 0.2.

Factors are separated by forward slash characters, such as:

AV:I,1.0/RP:G,0.9/AS:N,1.0

which lists values and weights for "AV" (Access Vector), "RP" (Required Privilege Level), and "AS" (Authentication Strength).

If a CWSS vector is provided that does not list the actual weights for a value, then an implementation should report a possible error or inconsistency, try to infer the CWSS version based on the vector's factors and values, re-calculate the CWSS score based on the inferred version, and compare this to the original score. If the scores are inconsistent, the implementation should report a possible error or inconsistency.

4.1 Example: Business-critical application

Consider a reported weakness in which an application is the primary source of income for a company, thus has critical business value. The application allows arbitrary Internet users to sign up for an account using only an email address. A user can then exploit the weakness to obtain administrator privileges for the application, but the attack cannot succeed until the administrator views a report of recent user activities - a common occurrence. The attacker cannot take complete control over the application, but can delete its users and data. Suppose further that there are no controls to prevent the weakness, but the fix for the issue is simple, and limited to a few lines of code.

This situation could be captured in the following CWSS vector:

(TI:H,0.9/AP:A,1.0/AL:A,1.0/IC:N,1.0/FC:T,1.0/

RP:G,0.9/RL:A,1.0/AV:I,1.0/AS:N,1.0/IN:T,0.9/SC:A,1.0/

BI:C/0.9,DI:H,1.0/EX:H,1.0/EC:N,1.0/P:NA,1.0)

The vector has been split into multiple lines for readability. Each line represents a metric group.

The factors and values are as follows:

The CWSS score for this vector is 92.6, derived as follows:

• BaseSubscore:
• [ (10 * TI + 5*(AP + AL) + 5*FC) * f(TI) * IC ] * 4.0
• f(TI) = 1
• = [ (10 * 0.9 + 5*(1.0 + 1.0) + 5*1.0) * 1 * 1.0 ] * 4.0
• = [ (9.0 + 10.0 + 5.0) * 1.0 ] * 4.0
• = 24.0 * 4.0
• = 96.0
• AttackSurfaceSubscore:
• [ 20*(RP + RL + AV) + 20*SC + 15*IN + 5*AS ] / 100.0
• = [ 20*(0.9 + 1.0 + 1.0) + 20*1.0 + 15*0.9 + 5*1.0 ] / 100.0
• = [ 58.0 + 20.0 + 13.5 + 5.0 ] / 100.0
• = 96.5 / 100.0
• = 0.965
• EnvironmentSubscore:
• [ (10*BI + 3*DI + 4*EX + 3*P) * f(BI) * EC ] / 20.0
• f(BI) = 1
• = [ (10*1.0 + 3*1.0 + 4*1.0 + 3*1.0) * 1 * 1.0 ] / 20.0
• = [ (10.0 + 3.0 + 4.0 + 3.0) * 1.0 ] / 20.0
• = 20.0 / 20.0
• = 1.0

The final score is:

96.0 * 0.965 * 1.0 = 92.64 == 92.6

4.2 Example: Wiki with limited business criticality

Consider this CWSS vector. Suppose the software is a wiki that is used for tracking social events for a mid-size business. Some of the most important characteristics are that there is medium technical impact to an application administrator from a regular user of the application, but the application is not business-critical, so the overall business impact is low. Also note that most of the environment factors are set to "Not Applicable."

(TI:M,0.6/AP:A,1/AL:A,1/IC:N,1/FC:T,1/

RP:RU,0.7/RL:A,1/AV:N,1/AS:L,0.9/IN:A,1/SC:NA,1/

BI:L/0.3,DI:NA,1/EX:NA,1/EC:N,1/RE:NA,1/P:NA,1)

The CWSS score for this vector is 51.1, derived as follows:

• BaseSubscore:
• [ (10 * TI + 5*(AP + AL) + 5*FC) * f(TI) * IC ] * 4.0
• f(TI) = 1
• = [ (10 * 0.6 + 5*(1 + 1) + 5*1) * f(TI) * 1 ] * 4.0
• = 84.0
• AttackSurfaceSubscore:
• [ 20*(RP + RL + AV) + 20*SC + 15*IN + 5*AS ] / 100.0
• = [ 20*(0.7 + 1 + 1) + 20*1.0 + 15*1.0 + 5*0.9 ] / 100.0
• = [ 54.0 + 20.0 + 15.0 + 4.5 ] / 100.0
• = 93.5 / 100.0
• = 0.94 (0.935)
• EnvironmentSubscore:
• [ (10*BI + 3*DI + 4*EX + 3*P) * f(BI) * EC ] / 20.0
• f(BI) = 1
• = [ (10*0.3 + 3*1.0 + 4*1.0 + 3*1.0) * f(BI) * 1 ] / 20.0
• = [ (3.0 + 3.0 + 4.0 + 3.0) * 1.0 * 1.0 ] / 20.0
• = [ 13.0 * 1.0 ] / 20.0
• = 0.65

The final score is:

84.0 * 0.935 * 0.65 = 51.051 == 51.1

4.3 Other Approaches to CWSS Score Portability

Instead of recording each individual weight within a CWSS vector, several other methods could be adopted.

One possibility is to extend the CWSS vectors to record additional metadata that does not affect the score but reflects the version or other important information. The metadata portion would not necessarily need to capture weights, per se. For example, the CWSS version could be recorded by using a "factor" name such as "V" along with a value that represents the CWSS version, e.g. "V:1.1". This would add approximately 4 bytes to each CWSS vector. However, if the version is encoded within a vector, then the assigned weights would no longer need to be recorded (except for Quantified values), so the resulting vectors could be much shorter.

A different approach would be to attach metadata to a set of generated CWSS scores (such as the Technical Impact Scorecard if CWRAF is used), but it could be too easy for this metadata to become detached from the scores/vectors. Quantified factors would still need to be represented within a vector, since they could vary for each weakness finding.

Another approach is that when CWSS scores are transferred from one party to the other, then the receiving party could re-calculate the scores from the given CWSS vectors, then compare the re-calculated scores with the original scores. A difference in scores would suggest that different mechanisms are in use between the provider and receiverd, possibly a different CWSS version.

For future versions, the following should be considered.

5.1 Current Limitations of the Scoring Method

5.1.1 Score Weight and Distribution

The formula still needs to be refined to ensure that the range of potential scores is more evenly distibuted. There are probably unexpected interactions between factors that must be identified and resolved. CVSS scoring contains built-in adjustments that prevent many factors from affecting the score too much, while also giving some preference to impact over exploitability; similar built-in adjustments may need to be performed for CWSS.

5.1.2 Raising the Priority of Design or Architectural Flaws

CWSS 1.0 does not provide any clear mechanism to give higher priority to design or architecture flaws versus implementation vulnerabilities. This can be an important distinction, because compromise of a design flaw could potentially compromise the entire software package, but a single CWSS score for such a design flaw could become "buried" if there are many different implementation bugs. For example, a single report of the lack of an input validation framework might be expected to carry more weight than multiple individual XSS and SQL injection bugs. This issuee can be exacerbated if aggregated scores are used.

It might be possible to use the Business Impact factor, but this factor might already be in use for its originally-intended purpose.

A "Weakness Scope" factor could be used to cover the following scenario. Within CWSS 1.0, design and architecture flaws receive the same relative priority as implementation issues, even though they may lead to a complete compromise of the software. It may be reasonable to use a separate factor in order to give design/architecture flaws a larger weight, e.g. so that the lack of an input validation framework (one "finding") can be given higher priority than hundreds of individual findings for XSS or SQL injection.*

5.1.3 Compound Elements (Chains, Etc.)

There are also some challenges for scoring findings that combine multiple weaknesses. By their nature, compound elements such as chains and composites involve interactions between multiple reported weaknesses. With some detection techniques such as automated code scanning, multiple CWE entries might be reported as separate findings for a single chain or composite. If individual scores within each link of the chain are counted separately, this could wind up artificially inflating any aggregate scores. However, sometimes the compound element is more than the sum of its parts, and the combination of multiple weaknesses has a higher impact than the maximum impact of any individual weakness. This is not well-handled in the current CWSS scheme; however, it should be noted that CVSSv3 is likely to include guidance for scoring chains as their own independent entities, so future versions of CWSS might follow suit.

5.1.4 Other Types of Software Assessments

It is anticipated that CWSS may be considered for use in other types of software assessments, such as safety, reliability, and quality. Weaknesses or other issues related to code quality might receive higher prioritization within a CWRAF vignette-oriented scheme, since safety, compliance, or maintainability might be important. This usage is not explicitly supported with CWSS 1.0. However, such quality-related issues could be scored in which the Required Privilege is the same as Acquired Privilege, and the Required Privilege Layer is the same as the Acquired Privilege Layer; the Business Impact could also be used.

5.2 Community Review and Validation of Factors

Pending community review, future versions of CWSS might modify, remove, or add factors to the methodology.

As long as there are enough stakeholders or use-cases for whom a factor is important, then it is a strong argument for keeping the factor within CWSS, even if it is not essential for everyone. Others could use the "Not Applicable" value when the factor is not relevant to their own environment. However, the more factors in the metric, the more complexity.

5.3 Impact of CWSS and CWE Version Changes to Scoring

The values for the factors involved in scoring could change frequently based on industry trends. For example, the likelihood of discovery of a particular weakness may change - rising if detection techniques improve (or if there is a shift in focus because of increases in attacks), or falling if enough developers have methods for avoiding the weakness, and/or if automatic protection mechanisms reach wide-scale adoption.

In the future, default values for some factors might be directly obtained from CWE data. However, new CWE versions are released on a regular basis, approximately 4 or 5 times a year. If a CWE entry is modified in a way that affects CWSS-related factors, then the resulting CWSS score for a weakness might differ depending on which version of CWE is used. Theoretically, however, this could be automatically detected by observing inconsistencies in the weights used for "Default" values in CWSS vectors.

Because of these underlying changes, there is a significant risk that CWSS scores will not be comparable across organizations or assessments if they were calculated using different versions of CWSS, vignettes, or CWE.

In anticipation of such changes, CWSS design should consider including CWE and/or CWSS version numbers in the CWSS vector representation (or associated metadata).

Finally, these changes should not occur too frequently, since each change could cause CWSS scores to change unpredictably, causing confusion and possibly interfering with strategic efforts to fix weaknesses whose importance has suddenly been reduced.* Although this may be inevitable for CWSS as a natural result of growth, the community should attempt to prevent this from happening where possible.

While scores may change as CWSS and CWE evolve, there is not necessarily a requirement for an organization to re-score whenever a new version is released, especially if the organization is using CWSS for internal purposes only. The variability of scores is largely a problem for sharing scores between organizations. For example, a software developer may have its own internally-defined vignettes and BVC, so the developer may not have a need (or willingness) to share CWSS scores outside the organization.

After the release of CWSS 1.0, the schedule for future development is uncertain. However, future plans might include:

• Continue to obtain stakeholder validation or feedback for the existing factors, values, and weights. Now that CWSS is seeing some real-world use, these stakeholders will have valuable input to improve the metric.
• Continue to modify the scoring method and formula so that there is less bias towards low scores, and incomplete or non-applicable data does not adversely affect the scores.
• Refine and evaluate aggregated scoring techniques.
• Define a data exchange representation for CWSS scores and vectors, e.g. XML/XSD.
• The values for Authentication Strength (AS) might need to be defined more clearly. It might be reasonable to adopt approaches such as the four levels outlined in NIST Special Publication 800-63 ("Electronic Authentication Guideline") and OMB Memo 04-04. However, since the strength of an authentication mechanism may degrade over time due to advances in attack techniques or computing power, it might be useful to select values that are effectively "future-proof." (On the other hand, this might make it difficult to compare CWSS scores if they were assigned at different times.)
• It is not clear whether the SANE model of privilege layers is sufficiently expressive or useful. Once CVSSv3 is released and independently validated, CVSS' model should be revisited.

Currently, members of the software assurance community can participate in the development of CWSS in the following ways:

• Provide feedback on this document.
• Review the factors that are currently defined; suggest modifications to the current factors, and any additional factors that would be useful.
• Evaluate the scoring formula and the relative importance of factors within that formula.
• Define specific use cases for CWSS.

A.1 CVSS Overview

The Common Vulnerability Scoring System (CVSS) is commonly used when ranking vulnerabilities as they appear in deployed software. CVSS provides a common framework for consistently scoring vulnerabilities.

Conceptually, CVSS and CWSS are very similar. There are some important strengths and limitations with CVSS, however.

One of CVSS' strengths lies in its simplicity. CVSS divides the overall score into 14 separate characteristics within three metric groups: Base, Temporal, and Environmental. Each characteristic is decomposed into two or more distinct values. For example, the Access Vector reflects the location from which an attacker must exploit a vulnerability, with possible values of Local (authenticated to the local system), Remote (across the network), or Network Adjacent (on the same physical or logical network). Typically, in addition to the CVSS score, a vector is provided that identifies the selected values for each characteristic.

With the associated documentation, CVSS scoring is fairly repeatable, i.e., different analysts will typically generate the same score for a vulnerability. However, different scores can be generated when information is incomplete, and significant variation is possible if an analyst does not closely follow documentation. While the simplified Confidentiality/Integrity/Availability model does not provide the depth and flexibility desired by some security experts, CVSS does provide the consistency that is useful for non-expert system and network administrators for prioritizing vulnerabilities.

CVSS has been widely adopted, especially the use of base scores from the Base metric group. Some organizations use the Temporal and Environmental portions of CVSS, but this is relatively rare, so these metric groups may not have been sufficiently vetted in the real world.

A.2 Usage Scenarios for CWSS versus CVSS

• CVSS assumes that a vulnerability has already been discovered and verified; CWSS can be applied earlier in the process, before any vulnerabilities have been proven. CVSS is not scalable to the security assessment of a single software package. A detailed assessment, such as an automated code scan, may report thousands of weakness findings. Because of the high volume, these findings often need to be scored and prioritized before they can be more closely examined to determine if they lead to vulnerabilities. CWSS explicitly supports "unknown" values when there is incomplete information.
• CVSS scoring does not account for incomplete information, but CWSS scoring has built-in support for incomplete information. Within CWSS, scoring may be necessary before the weakness is even known to contribute to a vulnerability. For example, the scoring entity - whether a human or machine - might not know the expected operating environment or authentication requirements during initial CWSS scoring. In CVSS, incomplete information is sometimes a problem because many vulnerability reports do not contain all the relevant details needed for scoring. When information is missing, a conservative approach is to select values that will generate the largest CVSS score. This approach is used by the National Vulnerability Database and others, but it can artificially inflate scores. Conservative scoring is viable, as long as most vulnerability reports contain sufficient information. Within a weakness-scoring context, a high percentage of weakness findings will be missing a critical piece of information, since some detection techniques will not be able to reliably determine if a weakness can be exploited by an attacker without further analysis. As a result, CWSS provides a way to explicitly record when information is unavailable.
• CVSSv2 scoring has a large bias towards the impact on the physical system; CWSS has a small bias in favor of the application containing the weakness. In some contexts, users may strongly prefer to score issues based on their impact to business-critical data or functionality, which might have limited implications for the impact to the overall physical system. For example, the maximum possible score for CVSS is often 7.0 for Oracle products, since these products typically run with limited privileges. CVSSv3 will remove this bias toward the system, but its model still differs from the model that CWSS uses.

Early CWSS development sought to preserve the strengths of CVSS while also attempting to avoid some of the associated limitations.

A.3 Comparison of CVSSv2 Factors with CWSS Factors

Note that in CVSS, the Access Complexity (AC) value combines multiple characteristics that are split into distinct factors within CWSS, such as Required Privilege Level and Level of Interaction.

A.4 Other Differences between CVSS and CWSS

CWSS scores and CVSS scores are not necessarily comparable. Even if CWSS scores (with a maximum of 100) are "normalized" to a CVSS range by dividing by 10 (which would produce CVSS-equivalent scores within the range of 0 to 10), this does not mean that a CWSS score of 7 is equivalent to a CVSS 7. This might be a desirable feature by some consumers, but since CWSS is often measuring completely different characteristics than CVSS does, scoring equivalence might not be feasible. In addition, in practice, CVSS scores do not follow a regular distribution, generally with a skew towards high scores; it is possible that CWSS might have better distribution.

Some organizations attempted to modify CVSS in order to address some of the unique requirements of software security analysis; these modifications are mentioned in Appendix B.

The metric groups in CWSS are different than those in CVSS, by design. Some reviewers of early CWSS versions suggested that CWSS adopt the same set of metric groups that are used by CVSS - Base, Temporal, and Environmental. However, since CWSS scores can be calculated in early, low-information scenarios, many factors are "temporal" in nature, regardless of which group they are in; also, these scores are likely to change as further analysis yields more information about the weakness. CWSS supports the use of values such as "Unknown" or "Default", which can be filled in at a later time.

One aspect of CVSS that is not explicitly modeled in CWSS is the notion of "partial" impacts. However, the acquired privileges, privilege layer, technical impact, and business impact are roughly equivalent, with more expressive power.

B.1 2008 CWSS Kickoff Meeting

In October 2008, a single-day kickoff meeting for CWSS was held. Several participants described their scoring approaches:

Veracode reported an adaptation of CVSS to evaluate detected weaknesses/vulnerabilities. Each issue is given weights for Confidentiality, Integrity, and Availability, based on its associated CWE entry. The weighting considers the average likely severity to occur. For example, a buffer overflow could allow an attacker to cause a crash, but it is not always exploitable for code execution.

For aggregated scores, Veracode has several "VERAFIED Security Marks" that are based on a calculated Security Quality Score (SQS), which ranges from 0 to 100. The "VerAfied" security mark is used to indicate software that Veracode has assessed to be free of "very high," "high," or "medium" severity vulnerabilities, and free of automatically-detectable vulnerabilities from the CWE/SANS Top 25 or OWASP Top Ten. Two "High Assurance" variations of the mark include a manual assessment step that covers the remainder of the CWE/SANS Top 25 or OWASP Top Ten that could not be identified by automatic detection.

The Veracode Rating System uses a three-letter rating system (with grades of "A", "B", "C", "D", and "F"). The first letter is used for the results from binary analysis, the second for automated dynamic analysis, and the third for human testing.

Cigital described a feasibility study of CVSSv2 with respect to weaknesses. Some attributes such as "Target Distribution" did not fit well. Other attributes were extended to add more granularity. A polynomial scoring method was recommended. It was also regarded as important to model the distinction between the likelihood and the impact.

Cenzic provided details of the Hailstorm Application Risk Metric (HARM). It is a quantitative score that is utilized by black box analysis of web applications. The goal of the metric was to provide a scalable approach to focus remediation efforts. The metric was split into 4 impact areas relevant to web application security: the browser, the session, the web application, and the server. The benefit to this approach was that it was easily consumable.

CERT/SEI presented its approach to scoring the C Secure Coding Rules. The FMECA metric, an ISO standard, was used. It characterizes items in terms of Severity, Likelihood (of leading to a vulnerability), and Remediation Cost.

B.2 2010 SANS/CWE Top 25

The 2010 SANS/CWE Top 25 Most Dangerous Software Errors list attempted to perform quantitative prioritization of CWE entries using a combination of Prevalence and Importance, which became the basis of CWSS 0.1 later in the year. A survey approach was taken in which respondents performed their own individual evaluation of Prevalence and Importance for 41 candidate weaknesses, from which the final scores were determined. To reflect the diverse opinions and use cases of the respondents for the general Top 25 list, the Importance factor was used instead of Impact. In an attempt to force consensus, respondents were restricted to 4 selections of the highest value for Importance ("Critical") and Prevalence ("Widespread"), although this forced choice was not popular; it will probably be abandoned in future versions of the Top 25. Many respondents used high-level rollup data, or a rough consensus of opinion with the organization, sometimes covering multiple teams or functions. Very few respondents had real-world data at the low level of granularity used by the Top 25 (typically the "Base" level of abstraction for CWE). An evaluation by PlexLogic later found that the two variables were not entirely independent. This discovery makes some sense, because the vulnerability research community tends to focus on vulnerabilities/weaknesses with the highest impact. When reliable attack techniques are devised for a particular weakness/vulnerability, it becomes easier for more researchers to find them, which can lead to widespread exploitation. Consequently, this raises the relative Importance of a weakness.

The 2010 Top 25 was structured in a way to support multiple points of view that could reflect different prioritizations of the weaknesses. The creation of separate focus profiles stemmed from some critiques of the original 2009 Top 25, in which a generalized Top 25 list would not necessarily be useful to all audiences, and that a customized prioritization would be ideal. Eight focus profiles were provided with the 2010 Top 25. For example, the Educational Emphasis focus profile evaluated weaknesses that are regarded as important from an educational perspective within a school or university context. It emphasized the CWE entries that graduating students should know, including weaknesses that were historically important or increased the breadth of coverage. A separate focus profile ranked weaknesses based solely on their evaluated Importance, which would be useful to software customers who want the most serious issues removed, without consideration for how frequently they occur or how resource-intensive it is to fix. These ranking-oriented focus profiles made the Top 25 more useful to certain audiences, and their construction and management have served as a useful predecessor to CWSS and vignettes.

While the 2009 Top 25 did not rank items, several factors were presented that were thought to be relevant to an audience: attack frequency, impact or consequences, prevalence, and ease of detection. Other considerations included remediation cost, amount of public knowledge, and the likelihood that the weakness discovery would increase in the future.

B.3 2010 OWASP Top Ten

In contrast to previous versions, the 2010 OWASP Top Ten shifted focus from weaknesses/vulnerabilities to risks, which typically caused each OWASP Top Ten entry to cover multiple related weakness types that posed the same risk. Factors for prioritization included Ease of Exploit, Prevalence, Detectability, and Technical Impact. Input from contributors was solicited to determine the values for these factors, but the final decision for each factor was made by the Top Ten editorial staff based on trend information from several real-world data sources. A metric was developed that used these factors to prioritize the final Top Ten list.

B.4 Other Models

Microsoft's STRIDE model characterizes issues in terms of Spoofing Identity, Tampering with Data, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. The DREAD scheme evaluates issues based on Damage Potential, Reproducibility of the issue, Exploitability, Affected Users, and Discoverability. Many of these attributes have equivalent factors in CWSS.

For CWSS to be most effective to its stakeholders, several aspects of the problem area were considered when designing the framework and metrics.

• Flexibility: CWSS should be automatable and flexible wherever possible, but support human input as well.
• Selected Automation: It is assumed that portions of CWSS scores can be automatically generated. For example, some factors may be dependent on the type of weakness being scored; potentially, the resulting subscores could be derived from CWE data. As another example, a web script might only be accessible by an administrator, so all weaknesses may be interpreted in light of this required privilege.
• Scalability: Some usage scenarios may require the scoring of thousands of weaknesses, such as defect reports from an automated code scanning tool. When such a high volume is encountered, there are too many issues to analyze manually. As a result, automated scoring must be supported.
• Stakeholder Analysis: The potential CWSS stakeholders, their needs, and associated use cases should be analyzed to understand their individual requirements. This might require support for multiple scoring techniques or methods.
• Usability vs. Completeness: Associated metrics must balance usability with completeness, i.e., they cannot be too complex.
• Prioritization Flexibility: Environmental conditions and business/mission priorities should impact how scores are generated and interpreted.

While CWSS 1.0 is focused on targeted scoring, it could be further adapted for scoring weaknesses in a general fashion, e.g. to develop a relative prioritization of issues such as buffer overflows, XSS, and SQL injection, independent of any specific software package.

A generalized scoring approach could account for:

• Prevalence: how often does this appear at least once within a software package?
• Frequency: in a software package in which this weakness occurs, how often does it occur? (perhaps summarized as "diffusion")
• Likelihood of Discovery
• Likelihood of Exploit
• Technical Impact

In the earlier CWSS 0.1, the formula was:

Prevalence x Importance

This formula was a characterization of the metric used for the 2010 CWE/SANS Top 25. Importance was derived from the vignette-specific subscores for Technical Impacts of the CWE entry. Prevalence could be obtained from general information (derived from CWE content, or from other sources), with the possibility of vignette-specific specifications of prevalence. For example, XSS or SQL injection might occur more frequently in a web-based retail context than in embedded software.

D.1 Prevalence Assessment

In the earlier CWSS version 0.1, prevalence scores for the 2010 Top 25 were obtained by re-using raw voting data from the 2010 Top 25 participants. The original 1-4 scale (with discrete values) was extended to use values between 1 and 10. When using real-world prevalence data, this artificial normalization might not be necessary.

The following table summarizes the prevalence scores for some of the Top 25 entries. Notice the high prevalence value for XSS; this reflects the fact that nearly all of the voting members scored XSS as "Widespread." Complete details are available on a separate page.

For years, software consumers have wanted clear guidance on how secure a software package is, but the only available methods have been proprietary, crude, or indirect, such as:

• Crude methods, such as counting the number and/or severity of publicly reported vulnerabilities
• Proprietary methods developed by consultants or tool developers
• Indirect methods, such as the attack surface metric, which likely has a strong association with overall software security, although this has not necessarily been empirically proven.

A software package could be evaluated in light of the number and importance of weaknesses that have been detected, whether from automated or manual techniques. The results from these individual weaknesses could be aggregated to develop a single score, tentatively called the "Weakness Surface." This could move the software assurance community one step closer to consumer-friendly software security indicators such as the Software Facts Label concept, as originally proposed by Jeff Williams (Aspect Security) and Paul Black (NIST).

When there is a set of targeted weaknesses for a single software package, there are several possible aggregated scoring methods, including but not necessarily limited to:

• Compute the sum of all individual weakness scores
• Choose the highest of all individual weakness scores
• Select a subset of individual weakness scores exceeding a stated minimum, and add the scores together
• Compute the sum of all individual weakness scores, then normalize these scores according to KLOC or other metrics that reflect code size, i.e., "defect density."
• Normalize the results on a per-executable basis.
• Normalize the results to a point scale between 0 (no assurance) and 100 (high assurance).

Early CWSS implementations have typically aggregated based on either the sum of all scores, or by choosing the highest of all scores.

Some methods from the 2008 CWSS kickoff workshop may be adaptable or applicable; see Appendix B. In addition, some SCAP users have begun creating aggregated metrics for a host system by aggregating CVSS scores for the individual CVE vulnerabilities that are detected on the host. These users may have some useful guidance for the CWSS approach to aggregate scoring.