We haven’t seen many responses regarding our planned changes to CWE, which we had sent out last week. We expect to implement the proposed changes in the coming days. Please let us know ASAP if you have any questions or concerns about the proposed changes.
Our hard deadline is Tuesday, December 13.
The original message is included below for your convenience.
Steve and Drew
In the coming months, the CWE team is planning to reorganize certain
portions of the Development Concepts view (CWE-699), which is used to
organize weaknesses around concepts that are frequently encountered in
The graph structure of this view can be seen at
https://cwe.mitre.org/data/graphs/699.html; other presentations are
available in the tabs on the upper right, just under the view's name.
Our primary goal is to simplify navigation across the hierarchy for
users, while reducing noise.
We would like your input on the following suggested changes. Please
respond by Thursday, December 8; we plan to implement some of these
changes in the next CWE version, which we hope to release later in
We plan to:
- remove several high-level entries that introduce inaccuracies and
make the view unnecessarily deep and/or inaccurate, e.g. the
"Location" / "Code" / "Source Code" categories and similar
sub-categories. These might also lead to deprecation of such
entries (but, if we do so, we would want to ensure that any
necessary information from those entries is properly represented,
e.g. within particular schema elements such as "time of
We probably have to make special accomodations to preserve CWE-16
("Configuration"), which is a category used by NIST's NVD (and
probably others) to map configuration-related issues. While we
discourage CWE users from mapping to categories, we recognize that
sometimes there is no suitable CWE weakness available (see
- remove "child views" from the CWE-699 development hierarchy, such as
CWE-629 (2007 OWASP Top Ten). We believe that such "child views"
create unnecessary complexity and "noise" for users who are
traversing the CWE-699 hierarchy. Note that we do not necessarily
plan to remove or deprecate these "child views" from CWE itself; we
only plan to disassociate them from the Development view.
- identify and resolve duplicate or near-duplicate entries. While we
have actively sought and eliminated duplicates in the past, we have
concentrated primarily on weakness-oriented entries. But within the
Development view, sometimes there is a category-oriented CWE entry
that also has a separate, equivalent weakness-oriented entry. For
example, CWE-264 (Permissions, Privileges, and Access Control) - a
category - is arguably equivalent to CWE-284 (Improper Access
Control), a weakness class.
- align the abstraction of children so that it is more consistent.
This is especially problematic with the Development view. For
example, CWE-20 (improper input validation) is at the Class level,
but its immediate children include variants, bases, and other
classes. The "Injection" class (CWE-74) is at the same level as
improper address validation in an IOCTL (CWE-781), which is a
variant. We believe that such inconsistencies may cause unnecessary
confusion and noise.
We are looking forward to any feedback that you may have.
Steve and Drew
|Free forum by Nabble||Edit this page|