Chains and Composites
This report lists several chains and composites, as represented by various relationships within CWE. They help to illustrate how weaknesses can be combined to create software vulnerabilities, and they help to expose existing problems with classification and terminology.
A Chain is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. For example, if an integer overflow (CWE-190) occurs when calculating the amount of memory to allocate, an undersized buffer will be created, which can lead to a buffer overflow (CWE-120). In this case, the integer overflow would be primary to the buffer overflow. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.
While CWE primarily contains "implicit" chaining relationships, there are several chains that are so common that they were assigned their own CWE identifiers. These are called Named Chains. For example, CWE-690 covers the integer-overflow-to-buffer-overflow chain in the previous paragraph.
In the schema for CWE 1.0 and later, the CanPrecede relationship is used to identify when the weakness is primary to others, and CanFollow is used to identify when a weakness is resultant from others. These relationships are mostly found within the Research Concepts view (CWE-1000).
A Composite is a combination of two or more separate weaknesses that can create a vulnerability, but only if they all occur all the same time. One weakness, X, can be "broken down" into component weaknesses Y and Z. For example, Symlink Following (CWE-61) is only possible through a combination of several component weaknesses, including predictability (CWE-340), inadequate permissions (CWE-275), and race conditions (CWE-362). By eliminating any single component, a developer can prevent the composite from becoming exploitable. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability; for example, NUL byte interaction errors (CWE-626) can widen the scope of path traversal weaknesses (CWE-22), which often limit which files could be accessed due to idiosyncracies in filename generation.
In the schema for CWE 1.0 and later, the Requires relationship is used by a composite to identify its component weaknesses, and the RequiredBy relationship is used by the components of that composite. In Draft 9, the component relationship was called IsRequiredBy.
Both chains and composites might explain some of the existing differences in security code scanners. For example, one scanner might report the primary part of a chain, and a different scanner might report the resultant part. Both scanners would be correct, but they would be reporting different CWE identifiers in different portions of the code. It is suspected that chains have a correspondence to some aspects of artifact labels as used in vulnerability theory (primarily in crossover and trigger points), but this has not been actively explored.
In general, both chains and composites pose challenges for vulnerability classification and terminology. Sometimes a researcher is only focusing on one weakness in the chain, or one component of the composite. Attempts to create a hierarchical organization of "vulnerabilities" can be complicated, because vulnerabilities can contain multiple weaknesses. The CWE team is actively researching these concepts. Some early discussion is found in the CWE Research List archives.
More information is available — Please select a different filter.