Schema Documentation - Schema Version 6.0
Document version: 6.0 Date: 2017-11-08
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 © 2017, 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.
Author: CWE Team
Table of Selected Content
Schema path: AbstractionEnumeration
The AbstractionEnumeration simple type defines the different abstraction levels that apply to a weakness. A "Class" is the most abstract type of weakness, typically described independent of any specific language or technology. A "Base" is a more specific type of weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. A "Variant" is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A "Compound" weakness is a meaningful aggregation of several weaknesses, currently known as either a Chain or Composite.
Schema path: AffectedResourcesType
The AffectedResourcesType complex type is used to identify system resources that can be affected by an exploit of this weakness. If multiple resources could be affected, then each should be defined by its own Affected_Resource element.
Schema path: AlternateTermsType
The AlternateTermsType complex type indicates one or more other names used to describe this weakness. The required Term element contains the actual alternate term. The required Description element provides context for each alternate term by which this weakness may be known.
Schema path: ApplicablePlatformsType
The ApplicablePlatformsType complex type specifies the languages, operating systems, architectures, paradigms, and technologies in which a given weakness could appear. In each case, one can specify either a specific Name or a general Class of platform. The required Prevalence attribute identifies the regularity with which the weakness is applicable to that platform. When providing an operating system name, an optional Common Platform Enumeration (CPE) identifier can be used to a identify a specific OS.
Schema path: ArchitectureClassEnumeration
The ArchitectureClassEnumeration simple type contains a list of values corresponding to known classes of architectures. The value "Architecture-Independent" is used to associate with all architectures.
Schema path: ArchitectureNameEnumeration
The ArchitectureNameEnumeration simple type contains a list of values corresponding to known architectures.
Schema path: AudienceType
The AudienceType complex type provides a reference to the target stakeholders or groups for a view. For each stakeholder, the required Type element specifies the type of members that might be interested in the view. The required Description element provides some text describing what properties of the view this particular stakeholder might find useful.
Schema path: BackgroundDetailsType
The BackgroundDetailsType complex type contains one or more Background_Detail elements, each of which contains information that is relevant but not related to the nature of the weakness itself.
Schema path: CategoryType
A category is a collection of weaknesses based on some common characteristic or attribute. The shared attribute may be any number of things including, but not limited to, environment (J2EE, .NET), functional area (authentication, cryptography) and the relevant resource (credentials management, certificate issues). A Category is used primarily as an organizational mechanism for CWE and should not be mapped to by external sources.
Schema path: CommonConsequencesType
The CommonConsequencesType complex type is used to specify individual consequences associated with a weakness. The required Scope element identifies the security property that is violated. The optional Impact element describes the technical impact that arises if an adversary succeeds in exploiting this weakness. The optional Likelihood element identifies how likely the specific consequence is expected to be seen relative to the other consequences. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact. The optional Note element provides additional commentary about a consequence.
Schema path: ContentHistoryType
The ContentHistoryType complex type provides elements to keep track of the original author of an entry and any subsequent modifications to the content. The optional Submission element is used to identify the submitter, their organization, the date, and any comments related to an entry. The optional Modification element is used to identify a modifier's name, organization, the date, and any related comments. A new Modification element should exist for each change made to the content. Modifications that change the meaning of the entry, or how it might be interpreted, should be marked with an importance of critical to bring it to the attention of anyone previously dependent on the weakness. The optional Contribution element is used to identify a contributor's name, organization, the date, and any related comments. This element has a single Type attribute, which indicates whether the contribution was part of general feedback given or actual content that was donated. The optional Previous_Entry_Name element is used to describe a previous name that was used for the entry. This should be filled out whenever a substantive name change occurs. The required Date attribute lists the date on which this name change was made. A Previous_Entry_Name element should align with a corresponding Modification element.
Schema path: DemonstrativeExamplesType
The DemonstrativeExamplesType complex type contains one or more Demonstrative_Example elements, each of which contains an example illustrating how a weakness may look in actual code. The optional Title_Text element provides a title for the example. The Intro_Text element describes the context and setting in which this code should be viewed, summarizing what the code is attempting to do. The Body_Text and Example_Code elements are a mixture of code and explanatory text about the example. The References element provides additional information.
Schema path: DetectionEffectivenessEnumeration
The DetectionEffectivenessEnumeration simple type defines the different levels of effectiveness that a detection method may have in detecting an associated weakness. The value "High" is used to describe a method that succeeds frequently and does not result in many false reports. The value "Moderate" is used to describe a method that is applicable to multiple circumstances, but it may not have complete coverage of the weakness, or it may result in a number of incorrect reports. The "SOAR Partial" value means that according to SOAR this method can be cost-effective for partial coverage of the objective. The value "Opportunistic" is used to describe a method that does not directly target the weakness but may still succeed by chance, rather than in a reliable manner. The value "Limited" is used to describe a method that may be useful in limited circumstances, only applicable to a subset of potential instances of a given weakness type, requires training/customization, or gives limited visibility. Even in its limited capacity, this may be part of a good defense in depth strategy. The value "None" is used to describe a method that is highly unlikely to work. However, it may be included in an entry to emphasize common, yet incorrect, methods that developers might introduce.
Schema path: DetectionMethodEnumeration
The DetectionMethodEnumeration simple type defines the different methods used to detect a weakness.
Schema path: DetectionMethodsType
The DetectionMethodsType complex type is used to identify methods that may be employed to detect this weakness, including their strengths and limitations. The required Method element identifies the particular detection method being described. The required Description element is intended to provide some context of how this method can be applied to a specific weakness. The optional Effectiveness element says 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 optional Effectiveness_Notes element provides additional discussion of the strengths and shortcomings of this detection method.
Schema path: EffectivenessEnumeration
The EffectivenessEnumeration simple type defines the different values related to how effective a mitigation may be in preventing the weakness. A value of "High" means the mitigation is frequently successful in eliminating the weakness entirely. A value of "Moderate" means the mitigation will prevent the weakness in multiple forms, but it does not have complete coverage of the weakness. A value of "Limited" means the mitigation may be useful in limited circumstances, or it is only applicable to a subset of potential errors of this weakness type. A value of "Incidental" means the mitigation is generally not effective and will only provide protection by chance, rather than in a reliable manner. A value of "Defense in Depth" means the mitigation may not necessarily prevent the weakness, but it may help to minimize the potential impact of an attacker exploiting the weakness.
Schema path: ExploitationFactorsType
The ExploitationFactorsType complex type points out conditions or factors that could increase the likelihood of exploit for this weakness.
Schema path: ExternalReferenceType
The ExternalReferenceType complex type defines a collection of elements that provide a pointer to where more information and deeper insight can be obtained. Examples would be a research paper or an excerpt from a publication.
Schema path: FunctionalAreaEnumeration
The FunctionalAreaEnumeration simple type defines the different functional areas of software in which the weakness may appear. The value "Functional-Area-Independent" is used to associate with all functional areas.
Schema path: FunctionalAreasType
The FunctionalAreasType complex type 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-23: Relative Path Traversal may occur in functional areas of software related to file processing. Each applicable functional area should have a new Functional_Area element, and standard title capitalization should be applied to each area.
Schema path: ImportanceEnumeration
The ImportanceEnumeration simple type lists different values for importance.
Schema path: LanguageClassEnumeration
The LanguageClassEnumeration simple type contains a list of values corresponding to different classes of source code languages. The value "Language-Independent" is used to associate with all operating systems.
Schema path: LanguageNameEnumeration
The LanguageNameEnumeration simple type contains a list of values corresponding to different source code languages.
Schema path: LikelihoodEnumeration
The LikelihoodEnumeration simple type contains a list of values corresponding to different likelihoods. The value "Unknown" should be used when the actual likelihood of something occurring is not known.
Schema path: MitigationStrategyEnumeration
The MitigationStrategyEnumeration simple type lists general strategies for protecting a system to which a mitigation contributes.
Schema path: ModesOfIntroductionType
The ModeOfIntroductionType complex type is used to provide information about how and when a given weakness may be introduced. If there are multiple possible introduction points, then a separate Introduction element should be included for each. The required Phase element identifies the point in the software life cycle at which the weakness may be introduced. The optional Note element identifies the typical scenarios under which the weakness may be introduced during the given phase.
Schema path: NoteTypeEnumeration
The NoteTypeEnumeration simple type defines the different types of notes that can be associated with a weakness. An "Applicable Platform" note provides additional information about the list of applicable platforms for a given weakness. A "Maintenance" note contains significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. A "Relationship" note provides clarifying details regarding the relationships between entities. A "Research Gap" note 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. A "Terminology" note contains a discussion of terminology issues related to this weakness, or clarifications when there is no established terminology, or if there are multiple uses of the same key term. It is different from the Alternate_Terms element, which is focused on specific terms that are commonly used. A "Theoretical" note describes the weakness using vulnerability theory concepts. It should be provided as needed, especially in cases where the application of vulnerability theory is not necessarily obvious for the weakness.
Schema path: NotesType
The NotesType complex type contains one or more Note elements, each of which is used to provide any additional comments about an entry that cannot be captured using other elements.
Schema path: ObservedExampleType
The ObservedExampleType complex type specifies references to a specific observed instance of a weakness in real-world software. Typically this will be a CVE reference. Each Observed_Example element represents a single example. The optional Reference element 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. The required Description element 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 that it is meant to exemplify. It should also be short and easy to understand. The Link element should provide a valid URL where more information regarding this example can be obtained.
Schema path: OperatingSystemClassEnumeration
The OperatingSystemClassEnumeration simple type contains a list of values corresponding to different classes of operating systems. The value "OS-Independent" is used to associate with all operating systems.
Schema path: OperatingSystemNameEnumeration
The OperatingSystemNameEnumeration simple type contains a list of values corresponding to different operating systems.
Schema path: OrdinalEnumeration
The OrdinalEnumeration simple type contains a list of values used to determine if a relationship is the primary relationship for a given weakness entry within a given view. Currently, this attribute can only have the value "Primary".
Schema path: ParadigmClassEnumeration
The ParadigmClassEnumeration simple type contains a list of values corresponding to different classes of paradigms.
Schema path: ParadigmNameEnumeration
The ParadigmNameEnumeration simple type contains a list of values corresponding to different paradigms.
Schema path: PhaseEnumeration
The PhaseEnumeration simple type lists different phases in the software life cycle.
Schema path: PotentialMitigationsType
The PotentialMitigationsType complex type is used to describe potential mitigations associated with a weakness. It contains one or more Mitigation elements, which each represent individual mitigations for the weakness. The Phase element indicates the development life cycle phase during which this particular mitigation may be applied. The Strategy element describes a general strategy for protecting a system to which this mitigation contributes. The Effectiveness element summarizes how effective the mitigation may be in preventing the weakness. The Description element contains a description of this individual mitigation including any strengths and shortcomings of this mitigation for the weakness.
Schema path: PrevalenceEnumeration
The PrevalenceEnumeration simple type defines the different regularities that guide the applicability of platforms.
Schema path: ReferencesType
The ReferencesType complex type contains one or more reference elements, each of which is used to link to an external reference defined within the catalog. The required External_Reference_ID attribute represents the external reference entry being linked to (e.g., REF-1). Text or quotes within the same CWE entity can cite this External_Reference_ID similar to how a footnote is used, and should use the format [REF-1]. The optional Section attribute holds any section title or page number that is specific to this use of the reference.
Schema path: RelatedAttackPatternsType
The RelatedAttackPatternsType complex type contains references to attack patterns associated with this weakness. The association implies those attack patterns may be applicable if an instance of this weakness exists. Each related attack pattern is identified by a CAPEC identifier.
Schema path: RelatedNatureEnumeration
The RelatedNatureEnumeration simple type defines the different values that can be used to define the nature of a related weakness. A ChildOf nature denotes a related weakness at a higher level of abstraction. A ParentOf nature denotes a related weakness at a lower level of abstraction. The StartsWith, CanPrecede, and CanFollow relationships are used to denote weaknesses that are part of a chaining structure. The RequiredBy and Requires relationships are used to denote a weakness that is part of a composite weakness structure. The CanAlsoBe relationship denotes a weakness that, in the proper environment and context, can also be perceived as the target weakness. Note that the CanAlsoBe relationship is not necessarily reciprocal. The PeerOf relationship is used to show some similarity with the target weakness that does not fit any of the other type of relationships.
Schema path: RelatedWeaknessesType
The RelatedWeaknessesType complex type is used to refer to other weaknesses that differ only in their level of abstraction. It contains one or more Related_Weakness elements, each of which is used to link to the CWE identifier of the other Weakness. The nature of the relation is captured by the Nature attribute. Please see the RelatedNatureEnumeration simple type definition for details about the valid value and meanings. The optional Chain_ID attribute specifies the unique ID of a named chain that a CanFollow or CanPrecede relationship pertains to. The optional Ordinal attribute is used to determine if this relationship is the primary ChildOf relationship for this weakness for a given View_ID. This attribute can only have the value "Primary" and should only be included for the primary parent/child relationship. For each unique triple of <Nature, CWE_ID, View_ID>, there should be only one relationship that is given a "Primary" ordinal.
Schema path: RelationshipsType
The RelationshipsType complex type provides elements to show the associated relationships with a given view or category. The Member_Of element is used to denote the individual categories that are included as part of the target view. The Has_Member element is used to define the weaknesses or other categories that are grouped together by a category. In both cases, the required CWE_ID attribute specifies the unique CWE ID that is the target entry of the relationship, while the View_ID specifies which view the given relationship is relevant to.
Schema path: ResourceEnumeration
The ResourceEnumeration simple type defines different resources of a system.
Schema path: ScopeEnumeration
The ScopeEnumeration simple type defines the different areas of software security that can be affected by exploiting a weakness.
Schema path: StakeholderEnumeration
The StakeholderEnumeration simple type defines the different types of users within the CWE community.
Schema path: StatusEnumeration
The StatusEnumeration simple type defines the different status values that an entity (view, category, weakness) can have.
Schema path: StructureEnumeration
The StructureEnumeration simple type lists the different structural natures of a weakness. A Simple structure represents a single weakness whose exploitation is not dependent on the presence of another weakness. A Composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability, while a Chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability.
Schema path: StructuredCodeType
The StructuredCodeType complex type is used to present source code examples. It allows embedded XHTML content to enable formatting of the source code. The required Nature attribute states what type of code the example shows. The optional Language attribute states which source code language is used in the example. This is mostly appropriate when the Nature is "good" or "bad".
Schema path: StructuredTextType
The StructuredTextType complex type is used to allow XHTML content embedded within standard string data. Some common elements are: <BR/> to insert a line break, <UL><LI/></UL> to create a bulleted list, <OL><LI/></OL> to create a numbered list, and <DIV style="margin-left: 40px"></DIV> to create a new indented section.
Schema path: TaxonomyMappingFitEnumeration
The TaxonomyMappingFitEnumeration simple type defines the different values used to describe how close a certain mapping to CWE is.
Schema path: TaxonomyMappingsType
The TaxonomyMappingsType complex type is used to provide a mapping from an entry (Weakness or Category) in CWE to an equivalent entry in a different taxonomy. The required Taxonomy_Name attribute identifies the taxonomy to which the mapping is being made. The Entry_ID and Entry_Name elements identify the ID and name of the entry which is being mapped. The Mapping_Fit element identifies how close the CWE is to the entry in the taxonomy.
Schema path: TaxonomyNameEnumeration
The TaxonomyNameEnumeration simple type lists the different known taxomomies that can be mapped to CWE.
Schema path: TechnicalImpactEnumeration
The TechnicalImpactEnumeration simple type describes the technical impacts that can arise if an adversary successfully exploits a weakness.
Schema path: TechnologyClassEnumeration
The TechnologyClassEnumeration simple type contains a list of values corresponding to different classes of technologies.
Schema path: TechnologyNameEnumeration
The TechnologyNameEnumeration simple type contains a list of values corresponding to different technologies.
Schema path: ViewType
A view represents a perspective with which one might look at the weaknesses in the catalog. There are three different types of views as defined by the type attribute: graphs, explicit slices, and implicit slices. The members of a view are either defined externally through the members element (in the case of a graph or an explicit slice) or by the optional filter element (in the case of an implicit slice).
Schema path: ViewTypeEnumeration
The ViewTypeEnumeration simple type defines the different types of views that can be found within CWE. A graph is a hierarchical representation of weaknesses based on a specific vantage point that a user may take. The hierarchy often starts with a category, followed by a class/base weakness, and ends with a variant weakness. In addition to graphs, a view can be a slice, which is a flat list of entries that does not specify any relationships between those entries. An explicit slice is a subset of weaknesses that are related through some external factor. For example, an explicit slice may be used to represent mappings to external groupings like a Top-N list. An implicit slice is a subset of weaknesses that are related through a specific attribute, as indicated by the Filter element of the View. For example, an implicit slice may refer to all weaknesses in draft status, or all class level weaknesses.
Schema path: WeaknessOrdinalitiesType
The WeaknessOrdinalitiesType complex type indicates potential ordering relationships with other weaknesses. A primary relationship means the weakness exists independent of other weaknesses, while a resultant relationship is when a weakness exists only in the presence of some other weaknesses. The required Ordinality element identifies whether the weakness has a primary or resultant relationship. The optional Description contains the context in which the primary or resultant relationship exists. It is important to note that it is possible for the same entry to be primary in some instances and resultant in others.
Schema path: WeaknessType
A weakness is a mistake or condition that, if left unaddressed, could under the proper conditions contribute to a cyber-enabled capability being vulnerable to attack, allowing an adversary to make items function in unintended ways. This complexType is used to describe a specific type of weakness and provide a variety of information related to it.
Schema path: Weakness Catalog
The Weakness_Catalog root element is used to describe a collection of software security issues known as weaknesses (e.g., flaws, faults, bugs). Each catalog can be organized by optional Views and Categories. The catalog also contains a list of all External_References that may be shared throughout the individual weaknesses. The required Name and Version attributes are used to uniquely identify the catalog. The required Date attribute identifies the date when this catalog was created or last updated.
More information is available — Please select a different filter.