Re: Discussion point: CONSPEC - Context-specific Issues

On Tue, 18 Sep 2007, pmeunier wrote:

> I think it would be very useful to have a "view" of the
> CWE that branches out on the language used, or that is filtered based on
> language (I'm getting ahead of #5).

We definitely see this too; in fact, a language-specific view is the first
one listed here:

  http://cwe.mitre.org/community/research/views.html



> I could also see a case made for a "language-independent" node.

My hope would be that most nodes would have a language-independent aspect
to them, perhaps as a parent.  It's not necessarily CWE's job to try to
determine what these parents would be (see some of the CONSPEC change
notes, e.g. CWE-568 and CWE-484) but it would be good, not to mention
educational, to do this where we can.

>  IMO the major reasons to do this are:
>
> i. Many people are interested in the issue of comparing languages.  How
> a language fares in not placing unnecessary pitfalls and traps, or
> unwieldy to use securely, is of interest.

I've been thinking a little bit about what a language-specific view might
be like in the context of comparing languages.  It seems to me that you
don't want to ignore the language-independent issues.  For example, "OS
Command Injection" is language-independent, but shell metacharacter
injection is more "naturally" avoided in Visual C on Windows than it is in
C on Unix, because (as I understand it) CreateProcess(), which is heavily
used in Windows, only executes a single command.

That said, at least being able to identify the differences between
languages would be a good start.

> iii. It would be less confusing for programmers trying to learn secure
> programming best practices, for example when adopting a different
> language, or when trying to identify issues in their programs.

Do you mean something like this: "I'm learning a new language.  What are
the specific things I need to worry about?"  That's one of the
applications we see for a language-specific view.

> There is also a 5th possibility:
>
> 5) Use tags.  CWE issues could be tagged with language names that are
> affected and not affected by the issues.

We currently have a poorly-named attribute "Platform" which mostly lists
different languages, although it's not as well-populated as we'd like.
We think this attribute might need to be changed in the future to handle
similar concepts.

> Having both lists of affected and not affected would make it clear if a
> specific language has not been evaluated for that CWE issue.  The tag
> mechanism could be also used for other means, such as a primitive
> mechanism for generating CWE "views", and for searching of course.  For
> example, "prune branches not containing tag XYZ" or "remove CWE nodes
> (collapsing the tree) not containing tag XYZ".  In addition, MITRE could
> allow user-defined tags.

We're not yet sure how exactly we'll be "implementing" views.  It would be
nice to do it in a well-structured fashion to facilitate as much automatic
data handling as possible, but in the early stages, it might be more
lightweight to implement less-structured tags.  Thanks for the ideas!

- Steve