CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > Community > Software Assurance > Prioritizing Common Weaknesses Based Upon Your Environment  
ID

Prioritizing Common Weaknesses Based Upon Your Environment

There are a wide variety of ways software and hardware can become exploitable to an attacker, allowing them to make use of the software/hardware in ways that was never intended. The CWE Program offers several approaches for prioritizing the weaknesses so that you can focus on the appropriate subset and have the most improvement in the resilience, reliability, and integrity of your software/hardware as soon as possible.

If you do not have the time to do a deeper analysis of how certain weaknesses would impact your software (as it is in use for a particular mission of your organization) you can make use of the CWE Top 25 list of the most widespread and critical CWEs. If you have some time and resources to focus on a specific subset of weaknesses (by looking at their technical impacts and the ways you can detect them), you should explore our Technical Impact & Detection Method approach.

Finally, if you would like to use a consistent risk scoring methodology that was created out of the investigation of these first two approaches, look into the Common Weakness Scoring System (CWSS) for scoring CWEs and Common Weakness Risk Analysis Framework (CWRAF). This last approach allows one to prioritize CWEs most relevant to the organization's business, mission, and deployed technologies by applying CWSS using specialized scenarios, or "vignettes".

Technical Impact & Detection Methods

While there are a large number of weaknesses in CWE, there appear to be only eight different consequences or technical impacts to which these failures lead (see the table below). In other words, if a weakness manifests itself in a product in an exploitable manner and an attacker successfully exploits it, then there will be one of eight technical impacts or consequences from that weakness.

Technical Impacts of Software Weaknesses:

  • Read data
  • Modify data
  • Denial-of-Service: unreliable execution
  • Denial-of-Service: resource consumption
  • Execute unauthorized code or commands
  • Gain privileges / assume identity
  • Bypass protection mechanism
  • Hide activities

Within each CWE entry the "common consequences" field lists the "technical impacts" that can result from each weakness in CWE. The technical impact and its translation into an impact to the mission are important criteria that can be useful to any organization needing reasonable assurance that their software-based capabilities do what is intended and nothing more.

The collapsing of the hundreds of types of errors into a small set of technical impacts offers a simplification to the question, "What should my organization focus on to gain assurance in our software?". Instead of trying to remove all weaknesses, you can decide which of the eight impacts are either more or less dangerous to you, given what the software product is doing for your organization.

For example, a public website utilizing distributed hosting/mirroring to provide information may not worry about weaknesses that lead to resource consumption/denial-of-service exploits, but could be extremely concerned about weaknesses that can lead to someone modifying the data. Using this approach assurance activities can be focused on weaknesses that can lead to this unacceptable failure mode. This Technical Impact information can be leveraged in combination with the Detection Methods information in CWE entries to make a second simplification where weaknesses can be matched against assessment activities that can detect them. This exercise may improve insights into whether that weakness is still an issue, or whether it has been mitigated or removed.

Common Weakness Scoring System (CWSS™)

When a security analysis of a software application is performed, such as when using an automated code auditing tool, 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 lead to an exploitable vulnerability. For example, a buffer overflow vulnerability might arise from a weakness in which the programmer does not properly validate the length of an input buffer. This weakness only contributes to a vulnerability if the input can be influenced by a malicious party, and if that malicious input can copied to an output buffer that is smaller than the input.

Due to the high volume of reported weaknesses, developers are forced into a situation in which they must prioritize which issues they should investigate and fix first. Similarly, when assessing design and architecture choices and their weaknesses, there needs to be a method for prioritizing them relative to each other and with the other issues of the application. Finally, software consumers want to know what they should worry about the most, and what to ask for to get a more secure product from their vendors and suppliers.

Further complicating the problem, the importance of a weakness may vary depending on business or mission needs, the kinds of technologies in use, and the threat environment.

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.

CWSS provides a mechanism for scoring weaknesses in a consistent, flexible, open manner while accommodating context for the various business domains. It is a collaborative, community-based effort that is addressing the needs of its stakeholders across government, academia, and industry.

CWSS:

  • Provides a common framework for prioritizing security errors ("weaknesses") that are discovered in software applications
  • Provides a quantitative measurement of the unfixed weaknesses that are present within a software application
  • Can be used by developers to prioritize unfixed weaknesses within their own software
  • In conjunction with the Common Weakness Risk Analysis Framework (CWRAF) described below, can be used by consumers to identify the most important 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.

Common Weakness Risk Analysis Framework (CWRAF™)

CWRAF, used in conjunction with CWSS, will provide your organization with a tailored "Top XX" list of common weaknesses. The list generated for your environment can be further decomposed into three groups:

  • A set of common weaknesses that are easily detected by external software tools/programs.
  • A set of common weaknesses that are difficult to detect with external tools/software.
  • A set of common weaknesses that cannot be detected with external tools/software.

Looking first at group one (above), there is no single software tool/program that can identify all of the common weaknesses. You will need several tools working together in order to cover the set of weaknesses identified in this group. Several available tools are inexpensive while others are very expensive. As a general rule of thumb, the more expensive tools provide a more comprehensive look at your software.

If you are looking for an inexpensive quick "first steps":

  • Turn on your entire set of compiler warning levels, recompile your code, and then work through the list of identified issues.
  • Follow the step above with a complete set of Unit Tests to ensure proper functionality of your software.

Properly embracing Software Assurance within your organization will require a culture shift. This culture shift entails the understanding that software weaknesses will be exploited at some time and that new weaknesses may be discovered at any time. Build new rules into your software development processes to educate developers, testers, and contractors that software assurance is 5 parts software quality and 2 parts software security — and that software assurance is everybody's job.

To begin with, compiler "warnings" should not be turned off or ignored.

  • Add rules that your in-house developers must follow: All code checked into the configuration management system, or source control, must be shown to be free of basic quality defects.
  • Add rules or contract language that contracting development organizations must adhere to: All code delivered must be free of software weaknesses as identified by [the company]'s Top XX Software Weaknesses as determined by [the company's] own CWRAF and CWSS or they will forfeit some percentage of the value of the contract.

    As a domain expert, the contracted software development companies should already be producing quality and secure code. If the contracted software development companies are not producing quality and secure code, they are not domain experts. Both quality and security need to be built into a product from the beginning and be part of the development culture. Unfortunately, there is a lot of software already developed that needs to be both high quality and secure, but sadly is neither.

    The enormity of the problem is visible here: How can you afford to bring production applications back into development to apply software quality and software assurance to them? How can you afford not to?

Page Last Updated: June 06, 2023