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.
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
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
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
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.
The CWE Researcher Community is strongly encouraged to provide
feedback to the CWE team or the researchers list regarding this
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.
More information is available — Please select a different filter.