Last call - Planned Changes to the CWE Development View (CWE-699)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Last call - Planned Changes to the CWE Development View (CWE-699)

Christey, Steven M.



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.


Thank you,

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

software development.


The graph structure of this view can be seen at; 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

  for more.)


- 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.



Thank you,

Steve and Drew



To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].