Perl and OWASP

Jacqui Caren-home jacqui.caren at
Sun Mar 28 19:34:58 BST 2010

James Laver wrote:
> What is actually required is to systematically audit each library for 
> potential pitfalls and see what the system as a larger entity 
> potentially opens up in them. And all that could take some time.

Code reviews are seriously hard work but well worth it.

We used to run code review sessions when I worked at Cray (a LONG time ago)
and it changed how we developed and tested code. I remember the IBM team
reviewing 100 lines of assember and find over 100 issues that needed resolution
- they were actually happy and bought us cakes :-)

The nice bit was it was seen as a way to improve things and for people
to learn from others. Other parts of the company liked the idea they
copied it and it started being used in both software and hardware reviews.

The side effect that programmers taught each other about pitfalls (and shortcuts)
was an unforseen advantage.

We were lucky in that we a team of some of the best professional testers
working with our dev team. They drove the code review and ensured it worked.

I no longer have the documentation but the rules were pretty simple.
small team - each member looks for specific issues. Constructive
cirticism. Limited code to review. Limited time and very very short
review meetings. No redesigns etc.

I just wish I had the free time to do this again.

More information about the mailing list