Rohit,
Excellent article! For the Top 25, we've had lots of people assume that
the entire list is about domain-specific issues, when it also covers
domain-agnostic issues as well. My first guess is that domain-specific
has a loose association with implementation, and domain-agnostic has a
loose association with design. Better modeling the differences between
domain-agnostic and domain-specific might also partially explain the
false-positive rates in automated code scanners [1] and why scanners seem
to be very limited for domain-specific issues without sufficient tuning.
There may be some subtleties with how to classify things like XSS, which
is arguably both domain-agnostic and domain-independent; a CMS admin often
has the privileges to insert script, thus no XSS (which requires a
domain-specific assessment). You might also have requirements that are
specific to a particular product; for example, path traversal might be
fine for an application if it's provided as a command-line argument for
startup, but not when reading a pathname from remote input. This suggests
an application-layer notion of "domain-specific".
We do not have this type of distinction for weaknesses in CWE, though it
may be useful for some consumers (SC-L readers can contact cwe@mitre if
you think this would be useful, and why).
- Steve
[1] See NIST's SATE project for why "false positive" and "true positive"
are not fine-grained enough for classifying the correctness/utility of
automated scanning findings.
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________
