Common Weakness Enumeration

CWE Glossary Definition

QUALITY: Quality Indicators
QUALITY: Quality Indicators

"Quality Indicators" describe properties of code that are relevant to quality and security, but they are not the actual code itself. They have no direct effect on the behavior of the software.

Some examples are:

546 - Suspicious Comments
561 - Dead Code
563 - Unused Variable
547 - Security-relevant Constants (using hard-coded constants)

Conceptually, "Large Attack Surface," or complexity metrics like KLOC or McCabe, would be quality indicators.

Using functions like strcpy() might also be regarded as a quality indicator. While strcpy() can be used safely, its use is often discouraged due to the high vulnerability risks.

Issue 1: Inclusion

Some users might think that CWE nodes should only identify specific security issues as they are found in architecture, design, or implementation. These might include researchers, consumers, and vendors. For these users, Quality Indicators should not be a CWE node. However, they can be very useful for giving consumers a a sense of how well-built and maintained the software can be, and they might also be useful in early analysis stages, where a researcher might use quality indicators to help focus on a particular part of the product. Developers might find the results from security tools to be useful.

Possible Solutions:

1) Deprecate all quality indicators. Note: the mechanisms for node restructuring are still being defined; see the node restructuring page for possible approaches.

2) Preserve any quality indicators that are well-understood to be directly associated with security.

3) Only preserve quality indicators that are in reachable code; for example, "suspicious comments" and possibly "dead code" are not reachable, but "unused variable" is technically reachable.

4) Keep all quality indicator entries and incorporate them under a "Quality Indicator" category, as it can be argued that code quality may be an indicator of programmer skill, so poor quality would be an indicator of a higher probability for weaknesses. Additionally, poor quality code increases the upkeep costs and increases the chance that later maintenance or usage may lead to a problem due to decreased readability.

Relevant Use-Cases

Assessment Vendors: can (and perhaps should) flag various quality indicators, for possible consultation by consumers and third party researchers, not to mention utility to developers.

Assessment Customers: Useful when interpreting potential issues flagged by vendors.

Educators: only vaguely useful in teaching about good programming practices.

Academic Researchers: Not applicable.

Applied Vulnerability Researchers: mixed utility; could be useful in initial analysis for focusing on suspicious portions of the code, but considered much less important than the core issues that are found; not likely to be reported at this level of detail.

Refined Vulnerability Information (RVI) Providers: could be used to establish trends between quality indicators and proximity to exploited expoited vulnerabilities.

Software Customers: useful in helping make product decisions, especially those quality indicators that are useful for metrics.

Software Developers: useful for determining own code "quality", independent of security relevance, to ensure that good development practices are being followed.

Recommendation

The CWE Researcher Community is strongly encouraged to provide feedback to the CWE team or the researchers list regarding this recommendation.

The MITRE CWE team recommends that CWE should only contain quality indicators that have a proven or likely impact on security. CWE should exclude quality indicators that are not linked with security, because doing otherwise could lead to unnecessary bias towards certain practices that have no proven impact on security. However, determining what exactly is security-related is a topic for the researcher list to decide.

Complete List of Examples

All CWE nodes that are affected by this discussion point are listed on a separate page.

Document version: 0.1    Date: September 13, 2007

This is a draft document. It is intended to support maintenance of CWE, and to educate and solicit feedback from a specific technical audience. This document does not reflect any official position of the MITRE Corporation or its sponsors. Copyright © 2007, The MITRE Corporation. All rights reserved. Permission is granted to redistribute this document if this paragraph is not removed. This document is subject to change without notice.