[Owasp-topten] A9 is weird (yes, that's a technical term)

Neil Smithline neil.smithline at owasp.org
Sun Feb 17 00:33:23 UTC 2013


On my first read through the T10 I didn't think twice about A9. But on
subsequent readings I find that it feels more and more like a fish out of
water.

I believe that all of the 2007, 2010, and 2013, minus 2013 A9, risks
involve some aspect of coding or configuration changes. The fix for each
risk involves changing code or configuration files. But the 2013 A9 is
different.

The strategy for avoiding 2013 A9 is a process change; not an authoring
one. A9 is immune to discovery by a manual or automated code review (a big
deal IMO). The ASVS (https://www.owasp.org/index.php/ASVS) is wholly
irrelevant to A9.

A9 is not targeted at developers, QA, code reviewers, or development app
sec auditors. The real work of A9 begins after delivery and is managed by
customer support. R&D has to worry about 9 of the T10 with support worrying
about the 10th? Who's going to tell them to worry about it? Support, at
least the non-coding portions of support, aren't typically the people who
read the T10.

I'm left questioning whether A9 belongs on this list. If it does, should
unpatched OSs also be on the list? If not, why?

I recall the discussion regarding the removal of buffer overflow from the
2007 T10. My recollection is that it was removed because it was deemed a
generic coding error and not web specific. IMO, 2013 A9 falls in the same
category and doesn't belong in the T10.

Well that's my 2 cents; more like 2 bucks I guess,

Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20130216/af49cc0e/attachment.html>


More information about the Owasp-topten mailing list