Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > Reports > Schema Differences between Version 5.4.4 and Version 6.0  

Schema Differences between Version 5.4.4 and Version 6.0

Version 5.4.4 Schema File: cwe_schema_v5.4.4.xsd -> Version 6.0 Schema File: cwe_schema_v6.0.xsd

Major changes from 5.4.4 --> 6.0:

  1. Make the <Weakness_Catalog> the only valid root element. The previous 5.4.4 schema allows any number of elements to be valid root elements. As part of this change, make the the other children (Weaknesses, Views, Categories, and External_References) become optional. The previous <Weakness_Catalog> requires the existence all of the child element, even if they are empty. For example, the empty element <Views/> is required to produce valid XML in schema 5.4.4.
  2. The <Compound_Element> has been removed. The rationale for this is that named chains and composites are weaknesses themselves and should therefore be defined by <Weakness> elements. To enable the distinction of the compound elements going forward, we will add a new "structure" attribute to <Weakness> element with values of: simple, chain, composite.
  3. Add the <External_References> element to the weakness catalog. In the previous 5.4.4 schema, references were defined inside an individual weakness, but assigned an ID so that they could be reused if the reference was used elsewhere. It is cleaner and easier to understand if there is a central collection of references that individual weaknesses can pull from as needed. As a side benefit, there is no longer a need to have a local reference ID as the main ID can be used.
  4. Tweak the child elements of a <View> :

    Current Elements New Elements Note / Reason
    View_Structuremoved to the "Type" attribute
    View_AudienceAudiencechanged to require description
    RelationshipsMembersonly allowed relationship is <Has_Member>
    Relationship_Notescombined with <Notes>
    Maintenance_Notescombined with <Notes>
    Other_NotesNotesadded "Type" attribute
    Alternate_Termsdoesn't make sense for views
    Research_Gapsdoesn't make sense for views
  5. Tweak the child elements of a <Category> as it currently uses the same Common_Attributes group as weaknesses do. Many of these fields are not applicable to categories. The following set of fields are children of the <Category> element in the 6.0 schema.

    • Summary
    • Relationships (memberOf and hasMember)
    • Taxonomy_Mappings
    • References
    • Notes (with new Type attribute)
    • Content_History

    The removed fields are:

    • Weakness_Ordinalities
    • Applicable_Platforms
    • Background_Details
    • Alternate_Terms
    • Time_of_Introduction
    • Modes_of_Introduction
    • Enabling_Factors_for_Exploitation
    • Likelihood_of_Exploit
    • Common_Consequences
    • Detection_Methods
    • Potential_Mitigations
    • Causal_Nature
    • Demonstrative_Examples
    • Observed_Examples
    • Functional_Areas
    • Relevant_Properties
    • Affected_Resources
    • Research_Gaps
    • White_Box_Definitions
    • Black_Box_Definitions
    • Related_Attack_Patterns
  6. Remove the following child elements of <Weakness> as they are only used in a limited manner and did not hold any unique information.

    • Time_of_Introduction (combined with Mode_of_Introduction)
    • Enabling_Factors_for_Exploitation
    • Causal_Nature
    • Research_Gaps (moved to a Note)
    • Relevant_Properties
    • White_Box_Definitions
    • Black_Box_Definitions
  7. Within the Applicable_Platform element, move the CPE platform reference element to be an optional attribute on <Operating_System>. The reason is that CPE is only applicable for the OS field and not languages, architectures, paradigms, or environments.
  8. For weaknesses, tweak the names of the "Description" elements. Previously there was a <Description> element with two children; the short description was named <Description_Summary>, and the long was named <Extended_Description>. The 6.0.0 schema removes the nested elements and just had two top-level elements: <Description> and <Extended_Description>.
  9. Change the <Relationships> element to only be used for views and categories. Also limit the values to memberOf and hasMember since these are the only ones that are appropriate for views and categories. For weaknesses, add a new <Related_Weaknesses> element that holds all the different types of relationships that weaknesses can have with each other. The reason for this change is to eliminate the incorrect use memberOf and hasMember relationships with weaknesses, and the incorrect use of parentOf and childOf with views and categories.
  10. Combine all the different note elements into a single <Notes> element. Add a type attribute that allows for a distinction between: maintenance, platform, relationship, terminology, theoretical, other. This is done to simplify the schema and the resulting XML by having less elements.
  11. Rewrite the StructuredTextType and add a new StructuredCodeType as the previous Structured_Text_Type was cumbersome and unnecessary. It was in place for two primary reasons: First was to enable the encoding of bulleted lists and indention within text fields. Second was to provide formatting options such as new lines and shading for code examples. The first can be solved easily by leveraging the existing XHTML standard. The new StructuredTextType does this. The second is accomplished by the new StructuredCodeType which also leverages XHTML but includes a couple of existing attributes (language, nature)
Page Last Updated: November 20, 2017