« Return to Thread: Discussion point: CONSPEC - Context-specific Issues
Re: Discussion point: CONSPEC - Context-specific Issues
by Pascal Meunier-3
::
Rate this Message:
Steven M. Christey wrote:
>
> Possible Solutions
> ------------------
>
> 1) Abstract all context-dependent issues under a context-dependent
> parent to indicate the potential problems when dealing with these
> weaknesses, making the current CWEs its children.
>
> 2) Treat these as a case of language-specific issues.
>
I'd like best a combination of 1 & 2, but I also see a 5th possibility
(see below). 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). I could also see a case made for a
"language-independent" node. 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. Many best practices issues
are language dependent, if not caused by syntactic or semantic issues
within the language. Language-independent issues should be emphasized
in secure programming courses, as covering these will likely have the
greatest ROI.
ii. It would reduce false positives, or make it easier to filter reports
based on the language used.
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. This
means that the CWE would be easier to use, more practical and relevant.
For example, there are other popular languages besides Python in which
== is the proper operator for string comparison.
It wouldn't bother me to find the same CWE node as a child of two
different problematic languages at the same time.
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. 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.
Cheers,
Pascal
>
> Possible Solutions
> ------------------
>
> 1) Abstract all context-dependent issues under a context-dependent
> parent to indicate the potential problems when dealing with these
> weaknesses, making the current CWEs its children.
>
> 2) Treat these as a case of language-specific issues.
>
I'd like best a combination of 1 & 2, but I also see a 5th possibility
(see below). 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). I could also see a case made for a
"language-independent" node. 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. Many best practices issues
are language dependent, if not caused by syntactic or semantic issues
within the language. Language-independent issues should be emphasized
in secure programming courses, as covering these will likely have the
greatest ROI.
ii. It would reduce false positives, or make it easier to filter reports
based on the language used.
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. This
means that the CWE would be easier to use, more practical and relevant.
For example, there are other popular languages besides Python in which
== is the proper operator for string comparison.
It wouldn't bother me to find the same CWE node as a child of two
different problematic languages at the same time.
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. 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.
Cheers,
Pascal
« Return to Thread: Discussion point: CONSPEC - Context-specific Issues
| Free embeddable forum powered by Nabble | Forum Help |
