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. 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 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. 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. 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. Catalog_Name is a required attribute of Weakness_Catalog which identifies the collection of Weaknesses, Views, Categories and Compound_Elements represented by this XML document. Catalog_Version is a required attribute of Weakness_Catalog which identifies what version of @Catalog_Name this XML document represents. Catalog_Date is an optional attribute of Weakness_Catalog which identifies the date when this catalog was created or last updated. Each View element represents a perspective with which one might look at the weaknesses in CWE. CWE-699 Development Concepts, CWE-1000 Research Concepts and are two examples of Views. 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. 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. The Status attribute defines the status level for this view. 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 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. 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 Status attribute defines the status level for this category. 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 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 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. 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 Status attribute defines the status level for 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. 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 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 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 Structure attribute defines the structural nature of this compound element - that is, composed of other weaknesses concurrently, as in a composite, or consecutively, as in a chain. The Status attribute defines the status level for this compound element. 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. This element contains a list of the individual Views to which this relationship pertains. Specifies the unique ID of the individual view element to which this relationship pertains. This ID must correspond to a View. 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 a list of the individual Chains this relationship pertains to. This element specifies the unique ID of an individual chain element this relationship pertains to. The Relationship_Target_Form element defines the form of the target of this relationship, such as Category, Weakness, View or Compound_Element. The Relationship_Nature element defines the nature of the relationship between this element and the target element, such as ChildOf, HasMember or Requires to name a few. This Relationship_Nature denotes the specified weakness as a top level member of this View. This value for Relationship_Nature can only be used in Views. The complementary relationship is MemberOf. This Relationship_Nature denotes membership of this weakness in the top level of the View specified in Relationship_Target_ID. The complementary relationship is HasMember. This Relationship_Nature denotes a specified weakness as a parent of this entry. In general, this means that the parent will be a higher level representation of this entry from the perspective of the View provided in Relationship_View_ID. The complementary relationship is ParentOf. This Relationship_Nature denotes a specified weakness as a child of this entry. In general, this means that the child will be a lower level representation of this entry from the perspective of the View provided in Relationship_View_ID. The complementary relationship is ChildOf. This Relationship_Nature denotes a specified entry as having some similarity with this entry which does not fit any of the other Relationship_Nature values. In this case, a Relationship_Note should also be provided explaining the connection. The complementary relationship is itself (PeerOf). This Relationship_Nature denotes a Compound_Element of Compound_Element_Structure="Composite". All entries that a Composite Requires must exist simultaneously in order for the Compound_Element to exist. The complementary relationship is RequiredBy. This Relationship_Nature denotes an entry that is required in order for the Compound_Element specified in Relationship_Target_ID to exist. The complementary relationship is Requires. This Relationship_Nature denotes the starting point in this chain as the entry specified by Relationship_Target_ID. This Relationship_Nature can only be used for Compound_Elements with Compound_Element_Structure="Chain". For named chains, the complementary relationship is StartsChain. This Relationship_Nature denotes this weakness as the starting point in the chain specified in Relationship_Target_ID. For named chains, the complementary relationship is StartsWith. This Relationship_Nature denotes a chain where this entry can precede the entry specified by Relationship_Target_ID in a sequential fashion. It is important to note that not all CanPrecede relationships are captured in a Compound_Element chain, only the most common for now. The complementary relationship is CanFollow. This Relationship_Nature denotes a chain where this entry can follow the entry specified by Relationship_Target_ID in a sequential fashion. It is important to note that not all CanFollow relationships are captured in a Compound_Element chain, only the most common for now. The complementary relationship is CanPrecede. This Relationship_Nature denotes an entry that, in the proper environment and context, can also be perceived as the entry specified by Relationship_Target_ID. This relationship is not necessarily reciprocal. The Relationship_Target_ID specifies the unique ID of the target element of the relationship. The View_Attributes structure is a collection of common elements which might be shared by all Views. 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 View_Objective element describes the perspective from which this View is constructed. The View_Audience element provides a reference to the targeted audiences or groups for this view. The Audience element provides a reference to the target audience or group for this view. The Stakeholder element specifies what types of members of the CWE community might be interested in this view. The Stakeholder_Description element provides some text describing what properties of this View this particular Stakeholder might find useful. 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 View_Filter element holds an XSL query for identifying which elements are members of an implicit slice. This should only be present for implicit slices. The Common_Attributes structure is a collection of common elements which might be shared by a Weakness, Category or Compound_Element. 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. 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 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. This element indicates whether this weakness exists independent of other weaknesses, Primary, or whether it is the result of the presence of some other weaknesses, Resultant. This element describes context in which this entry is either Primary or Resultant, depending on the corresponding value for Ordinality. 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 structure contains one or more Language elements which each represent a language in which this weakness may exist. This element contains one or more Operating_System subelements which each represent an OS in which this weakness is likely to exist. This element identifies a single Operating_System in which this entry may exist and with what frequency on the specified OS. This subelement identifies operating systems in which this weakness is likely to exist. This attribute identifies the prevalence with which this weakness may occur within code that runs on the specified operating system. 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. This subelement identifies families or groups of operating systems in which this weakness is likely to exist. This attribute identifies the prevalence with which this weakness may occur within code that runs on the specified operating system within this operating system class. This element contains one or more Hardware_Architecture subelements which each represent an architecture in which this weakness is likely to exist. This element identifies a single Hardware_Architecture on which this entry may exist and with what frequency on the specified architecture. This subelement identifies architectures on which this weakness is likely to exist. This attribute identifies the prevalence with which this weakness may occur within code that runs on the specified hardware architecture. This element identifies a single class of hardware architectures, specified in Hardware_Architecture_Class_Name, in which this entry may exist. This subelement identifies architectures in which this weakness is likely to exist. This attribute identifies the prevalence with which this weakness may occur within code that runs on the specified hardware architecture within the specified hardware architecture class. This element contains one or more Architectural_Paradigm subelements which each represent an architecture on which this weakness is likely to exist. This element identifies a single Architectural_Paradigm in which this entry may exist and with what frequency in the specified paradigm. This subelement identifies paradigms in which this weakness is likely to exist. This attribute identifies the prevalence with which this weakness may occur within code that runs on the specified paradigm. This element contains one or more Environment subelements which each represent an environment in which this weakness may exist. This element identifies a single Environment in which this entry may exist and with what frequency in the specified environment. This attribute is the name of the Environment we are identifying. This attribute identifies the prevalence with which this weakness may occur within code that runs on the specified environment. This element contains one or more individual Technology_Class subelements which each represent a technology class in which this weakness is likely to exist. This element identifies a single Technology_Class in which this entry may exist and with what frequency in the specified class. This subelement identifies a technology class in which this weakness is likely to exist. This attribute identifies the prevalence with which this weakness may occur within code that runs on the specified technology class. 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 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 CPE_ID stores the value for the related CPE entry identifier as a string. Only one CPE_ID element can exist for each Common_Platform element. This element provides additional information related to the applicable platforms of a weakness if needed. 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 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 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 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. 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. 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 describes the typical scenarios under which this weakness can be introduced into the software. It should be filled out as needed. 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 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 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 a rough estimate at the likelihood of exploitation of an exposed weakness. Many factors can impact this value which is why it should only be regarded as an approximation. 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 Detection_Methods element is comprised of one or more Detection_Method elements which identify methods that may be employed to detect this weakness. 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 Method_Name element identifies the particular weakness detection method to be described. This should be filled out for some weakness classes and bases. The Method_Description element is intended to provide some context of how this Detection_Method can be applied to a specific weakness. This should be filled out for some weakness classes and bases. 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 method is highly unlikely to work. The method may be useful in limited circumstances, only applicable to a subset of potential errors of this weakness type, requires training/customization, or gives limited visibility. The method is not effective in directly identifying the weakness, but it may inadvertently uncover evidence that is related to the weakness. The method is applicable to multiple circumstances, but it may be subject to high false-positive or false-negative rates. The method has well-known, well-understood strengths and limitations; there are reasonable false-positive or false-negative rates; and there is good coverage with respect to other techniques. The Method_Effectiveness_Notes element is intended to discuss the strengths and shortcomings of this detection method. 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 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 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. This structure contains one or more Demonstrative_Examples, each of which should contain an example illustrating the problem being described in this weakness. 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. This element describes the context and setting surrounding the example to add clarity for the reader. This element consists of a Structured_Text element which should hold the code and some explanatory information for the reader. 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. 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. This structure contains one or more Observed_Example elements, each of which is a reference to a specific observed instance of this weakness in the real world; typically this will be a CVE reference. 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 the identifier for the example being cited. For example, if a CVE is being cited it should be of the standard CVE identifier format, such as CVE-2005-1951 or CVE-1999-0046. 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 field should provide a valid URL where more information regarding this example can be obtained. 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. 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 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 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 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 system resources affected by this entry. It is populated by Affected_Resource elements. 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. 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 Taxonomy_Mappings element contains one or more Taxonomy_Mapping structures which provide a mapping from this entry to an entry in a different taxonomy. 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 identifies the name of the entry to which this weakness is being mapped in taxonomy Taxonomy_Name. This element identifies the ID of the entry to which this weakness is being mapped in taxonomy Taxonomy_Name. This element identifies how close to the original taxonomy this node was mapped. This attribute identifies the taxonomy to which this weakness has a similar or equivalent entry. 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. 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 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. 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. 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. 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 CAPEC_ID stores the value for the related CAPEC entry identifier as a string. Only one CAPEC_ID element can exist for each Related_Attack_Pattern element. This attribute identifies which version of CAPEC is being referenced. 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 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 should contain the name of the author for this entry. This element should identify the author's organization. This element should provide the date on which this content was authored in YYYY-MM-DD format. 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 attribute identifies how the initial information for this entry was obtained. 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 should contain the name of the author for this entry. This element should identify the author's organization. This element should provide the date on which this content was authored in YYYY-MM-DD format. 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 attribute indicates whether the contribution was part of feedback given to the CWE team or actual content that was donated. 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 should contain the name of the person modifying this entry. This element should contain the modifier's organization. This element should contain the date of the modifications. 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. This attribute indicates whether this modification was created by a CWE team member or provided by an external party. 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. This element identifies a name that was previously used for this entry. This lists the date on which this name was changed to something else. Typically, this date will be closely aligned with new releases of CWE. This subelement contains a single method for mitigating this weakness. One or more mitigations must be included inside of a Potential_Mitigations element. The Mitigation_Phase element indicates the development life cycle phase during which this particular mitigation may be applied. The general strategy for protecting a system to which this mitigation contributes. This structure contains one or more Language elements which each represent a language in which this mitigation may exist. This subelement contains the description of this individual mitigation. This element summarizes how effective the mitigation may be in preventing the weakness. The mitigation is highly unlikely to work. The mitigation may not necessarily prevent the weakness, but it may help to minimize the potential impact of an attacker exploiting the weakness. The mitigation may be useful in limited circumstances, or it is only applicable to a subset of potential errors of this weakness type. The mitigation is generally not effective and will only provide protection by chance, rather than in a reliable manner. The mitigation will prevent the weakness in multiple forms, but it does not have complete coverage of the weakness. The mitigation is frequently successful in eliminating the weakness entirely. The Mitigation_Effectiveness_Notes element is intended to identify the strengths and shortcomings of this mitigation on a specific weakness. 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 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 subelement contains an individual consequence associated with this weakness. One or more are required for every Common_Consequences element and should exist in all weaknesses. This subelement identifies an individual consequence that may be associated with this weakness. Possible effects are detailed in Consequence_Effect. This subelement describes the technical impacts that can arise if an attacker attempts to exploit this weakness. This attribute identifies how likely an impact is based on the weakness. This subelement provides additional commentary about this consequence. 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. 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. This attribute identifies the nature of the content contained within the Block. Presentation Element: This element is used to define bold-faced title for a subsequent block of text. Presentation Element: This element is used to define a paragraph of text. Presentation Element: This element is used to identify the programming language being used in the following block of Code Presentation Element: This element is used to define a line of code. Presentation Element: This element is used to define a comment in code. Presentation Element: This element is used to define an image. This element provides the location of the image file. This element provides a title for the image. 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 houses one or more Relationship_Note elements, which each contain details regarding the relationships between CWE entries. This element contains a note regarding the relationships between CWE entries. 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 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 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 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 one or more Alternate_Term elements, each of which contains other names used to describe this weakness. 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 element contains the actual term for the Alternate_Term element. Each term should follow the same conventions as the entry Name attribute. This element provides context to each Alternate_Term by which this weakness may be known. 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 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. The Languages_List_Type contains one or more Language elements, each of which provide further reading and insight into the item. This should be filled out as appropriate. This element represents a programming language in which this entry may occur. The language name is specified in the Language_Name attribute. This attribute specifies the name of the programming language in which this entry may occur. This attribute identifies the prevalence with which this weakness may occur within code that is written in the specified language. 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. This attribute identifies the prevalence with which this weakness may occur within code that is written in languages within the specified language class. The References_List_Type contains one or more Reference elements, each of which provide further reading and insight into the item. This should be filled out as appropriate. 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 title of the material being referenced. It is not required if the material does not have a title. 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. This element identifies the edition of the material being referenced in the event that multiple editions of the material exist. This will usually only be useful for book references. This element identifies the publication source of the reference material, if one exists. This element identifies the publisher of the reference material, if one exists. 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. This field describes the date when the reference was published YYYY. This element should hold the URL for the material being referenced, if one exists. This should always be used for web references, and may optionally be used for book and other publication references. 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. 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].