Following is a report of each CWE field that identifies its
priority, as well as how often it must be completed, from the
perspective of CWE content maintenance. The CWE community is
encouraged to provide feedback on these priorities.
| Affected_Resource |
| Completeness: |
some Types, some Variants |
| Priority: |
4 |
| Schema: |
possibly small changes, depending on view formalization |
| Community: |
could help define additional resources and populate nodes |
|
| Alternate_Terms |
| Completeness: |
some Types, some Variants, some Categories |
| Priority: |
4 |
|
| Applicable_Platforms |
| Completeness: |
all Types, all Variants, all Categories |
| Priority: |
2 |
| Schema: |
need to handle "All affected, but of greatest concern in
language X"; also need to handle environment/OS information
(e.g. only applies to Windows or Unix)
|
| Community: |
IEEE group (e.g. Jim Moore) could review/contribute. |
|
| Black_Box_Definition |
| Completeness: |
all Types, all Variants |
| Priority: |
5 |
| Content: |
this field was generated as a complement to
White_Box_Definition, but there are currently no plans to populate
this actively. There might be some opportunities to leverage CAPEC.
|
|
| CVEs_Mentioned |
| Completeness: |
most Types, most Variants |
| Priority: |
3 |
| Content: |
identifying CVEs for all types/variants would be very
difficult, due to lack of information; some CWE's haven't yet been
found in public software. Note: This is not an actual field in CWE.
See Observed_Example notes.
|
| Community: |
could help populate nodes |
|
| CWE_ID |
| Completeness: |
All nodes |
| Priority: |
1 |
|
| Causal_Nature |
| Completeness: |
most Types, most Variants |
| Priority: |
5 |
| Content: |
it could be argued that some nodes occur in multiple phases
of the software development lifecycle; for example, path traversal
problems could be introduced in design (if the design is that
detailed) or implementation (if the design was written in a more
general fashion).
|
| Schema: |
might want a better breakdown of implicit/explicit |
| Community: |
could help populate this element |
|
| Common_Consequences |
| Completeness: |
all Types, all Categories, all Variants |
| Priority: |
4 |
| Schema: |
additional structure and a fixed vocabulary might be good |
| Community: |
could help populate nodes |
|
| Common_Methods_of_Exploitation |
| Completeness: |
most Types |
| Priority: |
5 |
| Content: |
close link with CAPEC |
| Schema: |
unknown |
| Community: |
could help populate nodes |
|
| Context_Notes |
| Completeness: |
many Types |
| Priority: |
3 |
| Schema: |
might need to be more clearly merged/distinguished from
Description and Research Gaps.
|
|
| Demonstrative_Example |
| Completeness: |
all Types, all Variants, some Categories |
| Priority: |
3 |
| Content: |
some examples contain unintentional errors or do not
sufficiently illustrate the problem
|
| Schema: |
element might need additional modifications. Might want to
add a "grouping" element for all examples.
|
| Community: |
could contribute good examples |
|
| Description |
| Completeness: |
All nodes |
| Priority: |
1 |
| Content: |
descriptions have varying amounts of information, sometimes
too much. Draft 8 breaks the description down into 2 parts: a
Description_Summary, which is intended to be a single sentence, and
an Extended_Description, which further expands on the issue.
Ideally, this would be a short paragraph with consistent structure
and perspective, and other information could be in other fields.
|
| Community: |
could review existing long descriptions and help with the
split into Description_Summary and Extended_Description.
|
|
| Enabling_Factors_for_Exploitation |
| Completeness: |
most Types |
| Priority: |
5 |
| Content: |
close link with CAPEC |
| Schema: |
unknown |
| Community: |
could help populate nodes |
|
| Functional_Area |
| Completeness: |
all Types, all Variants, all Categories |
| Priority: |
5 |
| Content: |
leftover from PLOVER; need to ensure this addresses a Use
Case (possibly developers).
|
| Schema: |
this might be deleted in future drafts, unless there is
additional work that identifies a fixed, comprehensive set of
functional areas.
|
|
| Likelihood_of_Exploit |
| Completeness: |
all Types, all Variants |
| Priority: |
5 |
| Content: |
close link to CAPEC |
| Community: |
could help populate |
|
| Name |
| Completeness: |
All nodes |
| Priority: |
1 |
| Content: |
need to establish and follow consistent styles, including
capitalization, phrasing and perspective of each name.
|
|
| Node_Relationship |
| Completeness: |
All nodes |
| Priority: |
2 |
| Content: |
might want all variants to have parents/ancestors that are
types; similar for types and categories. Currently unknown how much
needs to be done. Chains and composites might pose special
challenges.
|
| Schema: |
formalization of views might impact this element. Need to
determine meaning/usage of Peer and CanAlsoBe.
|
| Community: |
could review and identify additional relationships,
especially with overlapping nodes, especially with respect to chains
and composites.
|
|
| Observed_Example |
| Completeness: |
most Types, most Variants |
| Priority: |
3 |
| Content: |
identifying real-world occurrences (e.g. CVEs) for all
types/variants would be very difficult, due to lack of detailed
information. It is likely that some CWE's haven't yet been publicly
reported for off-the-shelf software.
|
| Schema: |
element might need additional modifications. Might want to
add a "grouping" element for all examples.
|
| Community: |
could help populate nodes |
|
| Potential_Mitigations |
| Completeness: |
all Types, all Variants |
| Priority: |
4 |
| Schema: |
better formalization might enable analysis of which
mitigations affect the most nodes. Also might want to "share"
mitigations between parents/children.
|
| Community: |
SEI coding guidelines also a possibility (but that might
be better as a separate element).
|
|
| References |
| Completeness: |
all Types, some Variants |
| Priority: |
3 |
| Content: |
a child node is likely to inherit references from its
parent; should this be made explicit? Also might want to introduce
consistency-checking to identify when the same reference has been
specified in different ways.
|
| Community: |
book authors could provide mappings from their
chapters/sections to CWEs.
|
|
| Related_Attack_Patterns |
| Completeness: |
all Types, all Variants, all Categories |
| Priority: |
2 |
| Content: |
this is automatically populated via CAPEC's mappings to CWE
nodes. The CAPEC mappings are regarded as the master list.
|
|
| Research_Gaps |
| Completeness: |
some Types, Categories, Groupings, Variants |
| Priority: |
5 |
|
| Source_Taxonomy |
| Completeness: |
many Types, many Variants, many Categories |
| Priority: |
4 |
| Content: |
not all CWE nodes are derived from other taxonomies |
|
| Time_of_Introduction |
| Completeness: |
all Types, all Variants |
| Priority: |
3 |
| Content: |
some exploratory work was performed by the CWE team, but it
was not integrated into Draft 8.
|
| Schema: |
need to consider relationships with source code scanner
analysis, black/white box testing
|
| Community: |
could help populate nodes |
|
| Type |
| Completeness: |
All nodes |
| Priority: |
1 |
| Content: |
Attribute name changed to "Role" in Draft 8. An initial
effort by the CWE team to clarify roles is in Draft 8. These need
to be viewed collectively to look for errors or inconsistencies,
such as a Category that has no children, or a Variant that has no
Type as a parent. The analysis will help to clean up the gaps in
CWE and clarify the relationships.
|
| Schema: |
need to handle additional types |
|
| Weakness_Ordinality |
| Completeness: |
all Types, all Variants, some Categories |
| Priority: |
4 |
| Schema: |
could be changed to support automatic construction of chains
(but these are handled by CanResultIn/ResultsFrom relationships in
Draft 8). Many nodes are both primary and resultant, but this can't
be handled currently within the Ordinality element.
|
|
| White_Box_Definition |
| Completeness: |
many Types, many Variants |
| Priority: |
2 |
| Content: |
this data is provided by KDM Analytics in support of the
CWE Formalization project. Since the project is dedicated to
weaknesses that can be detected using automated source code
analysis, not all Types or Variants will have a white box
description.
|
|
