Common Weakness Enumeration

CWE Glossary Definition

Schema Differences between Draft 9 and Version 1.0

Schema Differences between Draft 9 and Version 1.0

Draft 9 Schema File: cwe_schema_v3.0.xsd -> Version 1.0 Schema File: cwe_schema_v4.0.xsd

With version 1.0 of CWE, we hope to move to a generally stable version of the schema. Future releases may make slight alterations or additions, but in general this structure is what we hope to use for the foreseeable future.

We have added the Structured_Text_Type construct as a means to format text in which whitespace, linebreaks, and other formatting may be meaningful but otherwise lost in the xml. This feature has helped us to significantly simplify the way data such as code examples and structured text descriptions are stored.

We have also added grouping tags to repeatable fields so that they are all contained within one construct so that the structure was consistent across the schema. For example, there is now a Weakness_Ordinalities tag to encompass multiple Weakness_Ordinality elements.

Another change of note is that we have reorganized the way the data is stored in accordance with the schema to make the most frequently used fields easier for researchers to access while editing the XML. The biggest change to the organization of data was the movement of commonly used fields, such as relationships, to the top portion of each entry.

The motivation behind this was to increase accessibility to the most frequently evolving data in an effort to maximize maintenance efficiency. We also realized that trying to optimize the layout for all users would be very difficult since the variety of use cases for CWE is so wide and frequency of access for any field will vary. We are investigating ways to alter web site presentation on a user-specific basis for the future.

We have broken down fields that contained either too broad a range of data or redundant data to minimize overlap and increase the specificity of each field. This primarily applies to the Context_Notes tag, which has been split up into things like Maintenance_Notes and Relationship_Notes.

Context_Notes was previously used as a sort of "catch-all" for data that had no other logical place to record within the schema. By dividing Context_Notes into more specific elements, the data becomes more useful and allows us to break off smaller tasks for future maintenance and improvements. We're still processing the data that used to be in the Context_Notes field, but we've transitioned what is left into a new field called Other_Notes and removed Context_Notes altogether to avoid confusion and ambiguity. In the future, Other_Notes will remain as a catch-all for new content that has no other location within the schema, but we do not expect this field to be used very often.

Similar breakdowns have also been made in the Applicable_Platforms field to now allow for identification of the specific language or language class, operating system, or hardware architecture in which the weakness may occur, just to name a few. We also added the capability of tagging with what frequency the weakness may occur on the specified language / OS / architecture etc. Since we went from a generic labeling here in the past, the Applicable_Platforms field is not filled in thoroughly across all of CWE, but we hope to improve on this in future updates and we think the schema structure for this will accommodate a much more accurate, usable method for capturing this information.

Additionally, we have added a descriptive field for formerly-simple elements to allow us to capture more specific context around the field. For example, we now have structured text field for discussing the circumstances in which a Weakness_Ordinality might be primary or resultant. This is a vast improvement over previous drafts where the Weakness_Ordinality field was required to have only one of two static values since many weaknesses can be primary to other weaknesses in some circumstances and resultant in a different context.

Finally, we reduced the depth of the schema by changing Common_Attributes to be a grouping tag that no longer needs to be traversed when extracting data via your XML mechanism of choice. This saves in time, complexity and reduces confounding of the data.

We also have some future improvements we would like to make for navigating relationships. Currently, CWE is perceived from a particular View. The View specifies who its root entries are with the HasMember relationship, and from there all weaknesses capture who their parents are using the ChildOf relationship.

The motivation behind this is to make content maintenance easier since we only have to change relationships in one place and it significantly simplifies maintenance of views that are slices; however we realize that this can make navigating the tree more difficult. To remedy this problem, we will be releasing the public XML in the future with relationships completed bi-directionally.