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'''
+
'''How to write an application security finding''' - by {Andrew was this you? (dinis)}
  
> 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  designed. Even the chapter headings in the new book from Howard and LeBlanc are negative.
> 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.
+
>
+
  
 +
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:
  
==Step 1: NAME==
+
http://www.asktog.com/columns/047HowToWriteAReport.html
  
blah blah blah
+
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!"
  
==Step 2: NAME==
+
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.
  
blah blah blah
+
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. 
  
==Step 3: NAME==
+
Check X. Do Y", rather than say "Faulty authorization. Don't do X. It's bad. M'kay?".
 
+
blah blah blah
+
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.
 
+
==Related How To Articles==
+
 
+
blah blah blah
+
 
+
==References==
+
 
+
blah blah blah
+
 
+
==Categories==
+
  
 
[[Category:How To]]
 
[[Category:How To]]
 
[[Category:Penetration Testing]]
 
[[Category:Penetration Testing]]
 
[[Category:Code Review]]
 
[[Category:Code Review]]

Revision as of 22:40, 24 May 2006

How to write an application security finding - by {Andrew was this you? (dinis)}

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.