Difference between revisions of "How to Write an Application Code Review Finding"

From OWASP
Jump to: navigation, search
 
Line 1: Line 1:
 +
'''How to write an application security finding'''
 +
 
> Personally, I find all of these lists (the SANS Top 20, the old Top   
 
> 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   
 
> 10, the old Guide, etc) very negative - which is the way they were   
Line 36: Line 38:
 
> I can make it even more positive.
 
> 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
 +
 +
==Categories==
 +
 +
[[Category:How To]]

Revision as of 11:54, 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. >


Contents

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

Categories