This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "How to Write an Application Code Review Finding"
| Line 63: | Line 63: | ||
[[Category:How To]] | [[Category:How To]] | ||
| + | [[Category:Penetration Testing]] | ||
| + | [[Category:Code Review]] | ||
Revision as of 16:58, 3 April 2006
How to write an application security finding
> Personally, I find all of these lists (the SANS Top 20, the old Top > 10, the old Guide, etc) very negative - which is the way they were > designed. Even the chapter headings in the new book from Howard and > LeBlanc are negative. > > A few years ago, that's how I thought, too. However, I've moved on. > Sure we need to tell people, don't do X when it is necessary, but I > think human nature works better when ideas are framed in a positive > way. Certainly with business types who don't (yet) understand risk > properly. Read this: > > http://www.asktog.com/columns/047HowToWriteAReport.html > > I write many reports which occasionally detail pretty bad news for > the recipients. Typically, they are not technical people (nor > necessarily should they be - well-written reports should be > understandable by lay people). Tog's essay was an eye opener for me > and I wish I'd read it sooner. With my more positive approach, I'm > getting greater traction and things are getting fixed. Before, they'd > often go "it's all too hard, we accept this risk, next!" > > I strongly believe we are here to enable secure business, not get in > the way. Too many security folks* forget that we exist to make sure > that ordinary folks don't lose money, don't see their details lost to > identity thieves, and don't lose privacy. "Thou Shalt Not ..." lists > don't really work in this "enable secure business" ideology. > > That's why the Guide has moved from negative titles to positive or > neutral titles. I've tried as hard as I can do phrase the issue in > terms of "This is the business reason why we check for this issue. > Check X. Do Y", rather than say "Faulty authorization. Don't do X. > It's bad. M'kay?". > > Only a few times I resorted to "don't do X" when it was truly > unavoidable and that's a few times too many. Hopefully, by Guide 2.1 > I can make it even more positive. >
Step 1: NAME
blah blah blah
Step 2: NAME
blah blah blah
Step 3: NAME
blah blah blah
Related How To Articles
blah blah blah
References
blah blah blah
