This element identifies system resources affected
by this entry. Each resource affected by this weakness should be
given its own Affected_Resource element. For example, CWE-249,
Path Manipulation has both Memory and File/Directory listed in
separate Affected_Resource elements. This should be filled out
in weakness bases and variants where applicable.

This element contains alternate terms by which this
weakness may be known and a description to explain the context in which
the term may be relevant. For example, CWE-181 Incorrect Behavior Order:
Validate Before Filter, has the alternate terms value
"Validate-before-cleanse". This is not required for all entries and
should only be included where appropriate.

This structure contains the Languages, Operating_Systems,
Hardware_Architectures, Architectural_Paradigms, Environments,
Technology_Classes or Common Platforms on which this entry may exist. This
should be filled out as much as possible for all Compound_Element and
Weakness entries.

This element contains background information
regarding the entry or any technologies that are related to it,
where the background information is not related to the nature of
the weakness itself. It should be filled out where appropriate.

This structure contains one or more Background_Detail
elements, each of which holds information regarding the entry or any
technologies that are related to it, where the background information is not
related to the nature of the entry itself. It should be filled out where
appropriate.

This element contains elements describes the
weakness from an external perspective, meaning that the view
includes no knowledge of how the software is processing data
other than what can be inferred from observing the software's
behavior.

This structure contains one or more Black_Box_Definition
elements, each of which describes the weakness from an external perspective,
meaning that the view includes no knowledge of how the software is
processing data other than what can be inferred from observing the
software's behavior.

Block is a Structured_Text element consisting of one of Text_Title,
Text, Code_Example_Language, or Code followed by another Block element.
Structured_Text elements help define whitespace and text segments.

The Categories structure contains zero or more Category
elements. Each Category element represents what used to be referred to
in CWE as a "Grouping" entry. That is, a category is now a collection of
weaknesses based on a common attribute, such as CWE-310 Cryptographic
Issues or CWE-355 User Interface Security Issues.

Each Category element represents what used to be referred to in CWE
as a "Grouping" entry. That is, a category is now a collection of weaknesses sharing
a common attribute, such as CWE-310 Cryptographic Issues or CWE-355 User Interface
Security Issues. The shared attribute may any number of things including, but not
limited to, environment (J2EE, .NET), functional area (authentication, cryptography)
and the relevant resource (credentials management, certificate issues).

This element describes the nature of the underlying cause of
the weakness. Is it an implicit underlying weakness or is it an issue of
behavior on the part of the software developer? Appropriate values are
either Implicit, occurring regardless of developer behavior, or Explicit, an
explicit weakness resulting from behavior of the developer.

The Common_Consequence_ID stores the value for the related
Common_Consequence entry identifier as a string. Only one
Common_Consequence_ID element can exist for each Common_Consequence element
(ex: CC-1). However, Common_Consequences across CWE with the same ID should
only vary in small details.

This element contains the common consequences associated with
this weakness. It is populated by one or more individual Common_Consequence
subelements. This should be included and completed as much as possible for
all weaknesses.

The Common_Platform subelement
identifies a single platform that is associated with
this weakness. Its only child, CPE_ID is required
and identifies the related CPE entry. More than one
Common_Platform_Reference element can exist, but
they must all be contained within a single
Common_Platform_References element.

The Common_Platforms element contains references
to the Common Platform Enumeration, CPE, which will identify
common platforms on which this weakness may occur. It has one or
more Common_Platform elements as children and each child will
point to a single CPE entry which is associated with this
weakness.

The Compound_Element structure represents a meaningful aggregation of
several weaknesses, as in a chain like CWE-690: CWE-252 Unchecked Return Value can
result in CWE-476 NULL Pointer Dereference or as in a composite like CWE-352
Cross-Site Request Forgery.

The Abstraction defines the abstraction level for this
weakness. The abstractions levels for Compound_Elements and Weaknesses are
the same. For example, if the Compound_Element is a chain, and all elements
of the chain are Class level, then the Compound_Element Abstraction
attribute is Class. This is required for all Compound_Elements.

The Compound_Elements structure contains zero or more
Compound_Element elements. Each Compound_Element represents a meaningful
aggregation of several weaknesses, as in a chain like CWE-690: CWE-252
Unchecked Return Value can result in CWE-476 NULL Pointer Dereference or
as in a composite like CWE-352 Cross-Site Request Forgery.

This element is used to keep track of the author of the weakness
entry and anyone who has made modifications to the content. This provides a means of
contacting the authors and modifiers for clarifying ambiguities, merging overlapping
contributions, etc. This should be filled out for all entries.

This element houses the subelements which identify the
contributor and contributor's comments related to this entry. This
element has a single attribute, Contribution_Mode, which indicates
whether the contribution was part of feedback given to the CWE team or
actual content that was donated.

This element provides the author with a place
to store any comments regarding the content of this weakness
entry, such as assumptions made, reasons for omitting
elements, contact information, pending questions, etc.

This element illustrates how this weakness may
look in actual code. It contains an Intro_Text element
describing the context in which this code should be viewed, an
Example_Body element which is a mixture of code and explanatory
text, and Demonstrative_Example_References that provide
additional information.

The Demonstrative_Example_ID stores the
value for the related Demonstrative_Example entry
identifier as a string. Only one
Demonstrative_Example_ID element can exist for each
Demonstrative_Example element (ex: DX-1). However,
Demonstrative_Examples across CWE with the same ID
should only vary in small details.

The Demonstrative_Example_References
element contains one or more Reference elements,
each of which provide further reading and insight
into this demonstrative example. This should be
filled out when appropriate.

This field provides a description of this Structure, whether
it is a Weakness, Category or Compound Element. Its primary subelement is
Description_Summary which is intended to serve as a minimalistic description
which provides the information necessary to understand the primary focus of
this entry. Additionally, it has the subelement Extended_Description which
is optional and is used to provide further information pertaining to this
weakness.

This description should be short and should limit
itself to describing the key points that define this entry.
Further explanation can be included in the extended description
element. This is required for all entries.

The Detection_Method element is intended to
provide information on different techniques that can be used to
detect a weakness, including their strengths and limitations.
This should be filled out for some weakness classes and bases.

The Detection_Method_ID stores the value
for the related Detection_Method entry identifier as a
string. Only one Detection_Method_ID element can exist
for each Detection_Method element (ex: DM-1). However,
Detection_Methods across CWE with the same ID should
only vary in small details.

This element identifies a condition or factor
that could increase the likelihood of exploit for this weakness.
This element should contain structured text with enough detail
to make the enabling factor clear. This should be filled out for
most weakness bases.

This element contains one or more
Enabling_Factor_for_Exploitation, each of which points out conditions or
factors that could increase the likelihood of exploit for this weakness.
This should be filled out for most weakness bases.

This element provides a place for details
important to the description of this entry to be included that
are not necessary to convey the fundamental concept behind the
entry. This is not required for all entries and should only be
included where appropriate.

This element identifies the functional area of
the software in which the weakness is most likely to occur. For
example, CWE-178 Failure to Resolve Case Sensitivity is likely
to occur in functional areas of software related to file
processing and credentials. Each applicable functional area
should have a new Functional_Area element and standard title
capitalization should be applied to each area.

This structure contains one or more Functional_Area elements,
each of which identifies the functional area of the software in which the
weakness is most likely to occur. For example, CWE-178 Failure to Resolve
Case Sensitivity is likely to occur in functional areas of software related
to file processing and credentials.

This attribute provides a unique identifier for the entry. It
will be static for the lifetime of the entry. In the event that this entry
becomes deprecated, the ID will not be reused and a pointer will be left in
this entry to the replacement. This is required for all Categories.

This attribute provides a unique identifier for the entry. It
will be static for the lifetime of the entry. In the event that this entry
becomes deprecated, the ID will not be reused and a pointer will be left in
this entry to the replacement. This is required for all Compound_Elements.

The ID attribute provides a unique identifier for the entry.
It will be static for the lifetime of the entry. In the event that this
entry becomes deprecated, the ID will not be reused and a pointer will be
left in this entry to the replacement. This is required for all Views.

This attribute provides a unique identifier for the entry. It
will be static for the lifetime of the entry. In the event that this entry
becomes deprecated, the ID will not be reused and a pointer will be left in
this entry to the replacement. This is required for all Weaknesses.

This element identifies the point of time in the
software life cycle at which the weakness may be introduced.
Possible values are Architecture and Design, Implementation and
Operational to name a few. If there are multiple points of time
at which the weakness may be introduced, then separate
Introductory_Phase elements should be included for each. This
element should be populated for all weakness bases and variants.

This element houses the description of a type of
language in which this entry is likely to exist and its likely
frequency of occurrence in that language. The type may be specified
by a common property, such as Languages with Automated Memory
Management or Languages which support Format Strings, or it may
describe a more general class of language such as All Interpreted
Languages or Pseudo Code.

This element is the description of a type of
language in which this entry is likely to exist. The type
may be specified by a common property, such as Languages
with Automated Memory Management or Languages which support
Format Strings, or it may describe a more general class of
language such as All Interpreted Languages or Pseudo
Code.

The Local_Reference_ID is an optional value for the related Local
Reference entry identifier as a string. Only one Local_Reference_ID element can
exist for each Reference element (ex: R.78.1). Text citing this reference should
use the format [R.78.1].

This element describes a significant maintenance task
within this entry that still need to be addressed, such as clarifying
the concepts involved or improving relationships. It should be filled
out in any entry that is still undergoing significant review by the CWE
team.

This element contains one or more Maintenance_Note elements which
each contain significant maintenance tasks within this entry that still need to be
addressed, such as clarifying the concepts involved or improving relationships. It
should be filled out in any entry that is still undergoing significant review by the
CWE team.

This element summarizes how effective
the detection method may be in detecting the
associated weakness. This assumes the use of
best-of-breed tools, analysts, and methods. There is
limited consideration for financial costs, labor, or
time.

The Mitigation_ID stores the value for the related Mitigation
entry identifier as a string. Only one Mitigation_ID element can exist for
each Mitigation element (ex: MIT-1). However, Mitigations across CWE with
the same ID should only vary in small details.

This element identifies the mode by which the
weakness may be introduced. If there are multiple ways in which
the weakness may be introduced, then separate
Mode_of_Introduction elements should be included for each. This
element should be populated for all weakness bases and variants.

This element houses the subelements which identify the
modifier and modifier's comments related to this entry. A new
Modification element should exist for each modification of the entry
content. This element has a single attribute, Modification_Source, which
indicates whether this modification was made by a CWE team member or an
external party.

This element provides the modifier with a
place to store any comments regarding the content of this
weakness entry, such as assumptions made, reasons for
omitting elements, contact information, pending questions,
etc.

This attribute identifies how significant the
modification is to the weakness with regard to the meaning and
interpretation of the weakness. If a modification has a value of
Critical, then the meaning of the entry or how it might be
interpreted has changed and requires attention from anyone
previously dependent on the weakness.

The Name is a descriptive name used to give the reader an
idea of what the commonality is amongst the children of this category. All
words in the name should be capitalized except for articles and prepositions
unless they begin or end the name. Subsequent words in a hyphenated chain
are also not capitalized. This is required for all Categories.

The Name is a descriptive name used to give the reader an
idea of the meaning behind the compound weakness structure. All words in the
name should be capitalized except for articles and prepositions unless they
begin or end the name. Subsequent words in a hyphenated chain are also not
capitalized. This is required for all Compound_Elements.

The Name is a descriptive attribute used to give the reader
an idea of what perspective this view represents. All words in the name
should be capitalized except for articles and prepositions unless they begin
or end the name. Subsequent words in a hyphenated chain are also not
capitalized. This is required for all Views.

This attribute is the string which identifies the entry. The
name should focus on the weakness being described in the entry and should
avoid focusing on the attack which exploits the weakness or the consequences
of exploiting the weakness. All words in the entry name should be
capitalized except for articles and prepositions unless they begin or end
the name. Subsequent words in a hyphenated chain are also not capitalized.
This is required for all Weaknesses.

This element contains any additional notes or comments
that cannot be captured using other elements. New elements might be
defined in the future to contain this information. It should be filled
out where needed.

This element specifies a reference to a specific
observed instance of this weakness in the real-world; Typically
this will be a CVE reference. Each Observed_Example element
represents a single example. This element should be filled out
for as many entries as possible.

This field should contain a product
independent description of the example being cited.
The description should present an unambiguous
correlation between the example being described and
the weakness which it is meant to exemplify. It
should also be short and easy to understand.

This element identifies a single
class of operating systems, specified in
Operating_System_Class_Description, in which this
entry may exist. Suggested values include: Linux,
Windows, UNIX, BSD, and Mac OS.

The ordinal attribute is used
to determine if this relationship is the primary
ChildOf relationship for this weakness entry for a
given Relationship_View_ID element.. This
attribute can only have the value "Primary" and
should only be included for the primary
parent/child relationship.

This element contains one or more Note elements, each of which
provide any additional notes or comments that cannot be captured using other
elements. New elements might be defined in the future to contain this information.
It should be filled out where needed.

This element contains the potential mitigations associated
with this weakness. It contains one or more mitigation subelements which
each represent individual mitigations for this weakness. This should be
included and completed to the extent possible for all weakness bases and
variants.

This structure contains one or more Previous_Entry_Name
elements, each of which describes a previous name that was used for this
entry. This should be filled out whenever a substantive name change
occurs.

Each Reference subelement should provide a single source from
which more information and deeper insight can be obtained, such as a
research paper or an excerpt from a publication. Multiple Reference
subelements can exist. The sole attribute of this element is the id. The id
is optional and translates to a preceding footnote below the context notes
if the author of the entry wants to cite a reference. Not all subelements
need to be completed, since some are designed for web references and others
are designed for book references. The fields Reference_Author and
Reference_Title should be filled out for all references if possible.
Reference_Section and Reference_Date can be included for either book
references or online references. Reference_Edition, Reference_Publication,
Reference_Publisher, and Reference_PubDate are intended for book references,
however they can be included where appropriate for other types of
references. Reference_Link is intended for web references, however it can be
included for book references as well if applicable.

This element identifies an individual author of the material
being referenced. It is not required, but may be repeated sequentially in
order to identify multiple authors for a single piece of material.

This element identifies the date when the reference was
included in the entry. This provides the reader with a time line for when
the material in the reference, usually the link, was valid. The date should
be of the format YYYY-MM-DD.

The Reference_ID is an optional value for the related Reference
entry identifier as a string. Only one Reference_ID element can exist for each
Reference element (ex: REF-1). However, References across CWE with the same ID
should only vary in small details. Text citing this reference should use the
local reference ID, as this ID is only for reference library related consistency
checking and maintenance.

This element is intended to provide a means of identifying
the exact location of the material inside of the publication source, such as
the relevant pages of a research paper, the appropriate chapters from a
book, etc. This is useful for both book references and internet references.

The References element contains one or more Reference
elements, each of which provide further reading and insight into this
weakness. This may include an alternate interpretation of this weakness, a
deeper technical breakdown of this weakness such as a research paper, deeper
information on mitigations, or background details on this technical area.
This should be filled out for all weakness bases and some variants.

The References element contains one or more Reference
elements, each of which provide further reading and insight into this
view. This should be filled out when the view is based on sources or
projects that are external to the CWE project.

The References element contains one or more Reference
elements, each of which provide further reading and insight into this view.
This should be filled out when the view is based on sources or projects that
are external to the CWE project.

The Related_Attack_Pattern subelement identifies
a single attack pattern that is associated with this weakness.
Its only child, CAPEC_ID is required and identifies the related
CAPEC entry. It also has a required attribute, CAPEC_Version,
which identifies which version of CAPEC is being referenced.
More than one Related _Attack_Pattern element can exist, but
they must all be contained within a single
Related_Attack_Patterns element.

The Related_Attack_Patterns element contains all references
to CAPEC which will identify related attack patterns to this weakness. It
has one or more Related_Attack_Pattern elements as children and each child
will point to a single CAPEC entry which is associated with this weakness.
This should be filled out to the extent possible for most weaknesses.

Each Relationship identifies an association between this structure,
whether it is a Weakness, Category, or Compound_Element and another structure. The
relationship also identifies the views under which the relationship is applicable.

The Relationships structure contains one or more Relationship
elements, each of which identifies an association between this structure, whether it
is a Weakness, Category, or Compound_Element and another structure.

This structure contains one or more Relevant_Property
elements. Each Relevant_Property element identifies a property that is
required by the code or a resource in order to function as specified.
Correctly labeling all of the relevant properties can help to figure out
what the root cause of a vulnerability might be.

Each Relevant_Property element identifies a
property that is required by the code or a resource in order to
function as specified. Correctly labeling all of the relevant
properties can help to figure out what the root cause of a
vulnerability might be.

This element identifies potential opportunities for the
vulnerability research community to conduct further exploration of
issues related to this weakness. It is intended to highlight parts of
CWE that have not received sufficient attention from researchers. This
should be filled out where appropriate for weaknesses and categories.

This structure contains one or more Research gap elements, each of
which identifies potential opportunities for the vulnerability research community to
conduct further exploration of issues related to this weakness. It is intended to
highlight parts of CWE that have not received sufficient attention from researchers.
This should be filled out where appropriate for weaknesses and categories.

This element houses the subelements which identify the
submitter and the submitter's comments related to this entry. This
element has a single attribute, Submission_Source, which provides a
general idea of how the initial information for this entry was obtained,
whether internal to MITRE, external, donated, etc.

This element provides the author with a place
to store any comments regarding the content of this weakness
entry, such as assumptions made, reasons for omitting
elements, contact information, pending questions, etc.

This structure describes mappings to nodes of
other taxonomies that are similar in meaning to this node.
Although this may sound similar to Source_Taxonomy,
Source_Taxonomy is designed to provide a history and pedigree
for the entry, whereas Taxonomy_Mapping allows similar nodes in
other collections to be identified as matching concepts with
this weakness. For example, Taxonomy_Mapping should be used to
map the CWE entries to their OWASP Top 10 equivalents. The sole
attribute is "Mapped_Taxonomy_Name" which is used to identify
the taxonomy to which this weakness is being mapped.

This element is used for general discussion of
terminology issues associated with this weakness. It is
different from the Alternate_Terms element, which is focused on
discussion of specific terms that are commonly used. It should
be filled out in any entry for which there is no established
terminology, or if there are multiple uses of the same key
term.

This element contains one or more Terminology_Note elements
that each contain a discussion of terminology issues related to this
weakness. It is different from the Alternate_Terms element, which is focused
on discussion of specific terms that are commonly used. It should be filled
out in any entry for which there is no established terminology, or if there
are multiple uses of the same key term.

This element is used to describe the weakness
using vulnerability theory concepts, which can be useful in
understanding the Research view. It should be filled out as
needed, especially in cases where the application of
vulnerability theory is not necessarily obvious for the
weakness.

This element contains one or more Theoretical_Note elements
that each describe the weakness using vulnerability theory concepts. It
should be filled out as needed, especially in cases where the application of
vulnerability theory is not necessarily obvious for the
weakness.

The Time_of_Introduction element contains the points of time
in the software life cycle at which the weakness may be introduced. If there
are multiple points of time at which the weakness may be introduced, then
separate Introduction elements should be included for each. This element
should be populated for all weakness bases and variants.

The View_Structure element describes how this view is being
constructed. Valid values are: Implicit Slice = a slice based on a filter
criteria; Explicit Slice = a slice based on arbitrary membership, as defined
by specific relationships between entries; Graph = a bounded graphical slice
based on ChildOf relationships.

The Views structure contains zero or more View elements.
Each View element represents a perspective with which one might look at
the weaknesses in CWE. CWE-699 Development View and CWE-1000 Research
View are two examples of Views.

The Weakness_Abstraction attribute defines the abstraction
level for this weakness. Acceptable values are "Class", which is the most
abstract type of Weakness such as CWE-362 Race Conditions, "Base" which is a
more specific type of weakness that is still mostly independent of a
specific resource or technology such as CWE-567 Unsynchronized Access to
Shared Data, and "Variant" which is a weakness specific to a particular
resource, technology or context.

The Weakness_Catalog structure represents a collection of software
security issues (flaws, faults, bugs, vulnerabilities, weaknesses, etc). The name
used by CWE is usually "CWE". However, if this collection is a subset of CWE, then a
more appropriate name should be used. It has two required attributes: Catalog_Name
and Catalog_Version.

This element contains one or more Weakness_Ordinality
elements, each of which describes when this entry is primary - where the
weakness exists independent of other weaknesses, or when this entry might be
resultant - where the weakness is typically related to the presence of some
other weaknesses. This should be filled out for all Weakness Base and
Variant entries.

This element describes when this entry is primary
- where the weakness exists independent of other weaknesses, or
when this entry might be resultant - where the weakness is
typically related to the presence of some other weaknesses. The
Ordinality subelement identifies whether or not we are providing
context around when this entry is primary, or resultant. The
Ordinality_Description contains the description of the context
in which this entry is primary or resultant. It is important to
note that it is possible for the same entry to be primary in
some instances and resultant in others.

The Weaknesses structure contains zero or more Weakness
elements. Each Weakness element represents an actual weakness entry in
CWE, such as CWE-311 Failure to Encrypt Sensitive Data or CWE-326 Weak
Encryption.

This element describes the weakness from a white
box perspective, meaning that the view includes the knowledge of
control flow, data flow, and all other inner workings of the
software in which the weakness exists.

This structure contains one or more White_Box_Definition
elements, each of which describes the weakness from a white box perspective,
meaning that the view includes the knowledge of control flow, data flow, and
all other inner workings of the software in which the weakness exists.