Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection]

[Jeremiah Grossman <jeremiah () whitehatsec com>]

comments inline:

On Wednesday, February 23, 2005, at 08:18  PM, David wrote:

> 2 cents on code reviews:
>
> I find that there is a place(s) for code review in the release cycle 
> itself. A 3rd party reviewer is not going to be as familiar with 
> software as an inhouse developer and will be far more expensive.

Between a third-party reviewer and an in-house staffer, there are going 
to be some give and takes when it comes to code audits. Just like every 
solution out there, ROI analysis for your particular organization is 
essential. We know no one particular process is always going to be the 
right way.

The part you mentioned I that find interesting is, "familiarity with 
the code", which I have question about. Is this a good thing when it 
comes to auditing code? Are code audits more effective with a fresh set 
of eyes or someone already familiar with the software? It seems to me 
that both have benefits, though I'm not certain on what they might be. 
From this perspective It doesn't matter if the person is in-house or 
out-house.

> Why not have inhouse developers check each other's code as part of the 
> release cycle?

Several open source initiatives use a similar model.

The answer I've heard most often in organizations is that you want 
"developers" writing code, not auditing code, because you lose they're 
productivity. Auditing code should be done by someone else (Who really 
doesn't exist in most cases). Not that I agree with the premise, but 
this is what I hear. :)


> Before anything gets released another developer should look over the 
> originator's code. This could also be done by the developer manager as 
> well. This is sort of like having the fox gaurd the henhouse I admit 
> but just as security should be multi-layered so should commitment to 
> quality if you expect to have it. Then, semi-anually, take time to go 
> back over the code and have bug-hunt month or week or whatever. This 
> (bug hunt week/month every so oftern) is what we did at my old dev 
> shop and it mostly worked as a compromise between slamming out 
> software as fast as humanly possible and having software that works. 
> Damn those project managers and their rigid schedules!


You found a balanced process that works for your organizations needs 
and keeps everyone happy. Did your developers go over they're own code, 
or everyone else's code? What were the results like?


> This may be unrealistic for most companies as the business side 
> typically demands on schedule releases without bugs in the first place 
> and doesn't see as high a value in 'skipping' releases to look for 
> bugs that 'shouldn't be there in the first place'.
>
> Quality, price, speed. Which 2 do you want? Sales, marketing, and the 
> board seem to take price and speed every time. Developers will take 
> quality and speed every time but then they don't control the 
> checkbook... IT on the other hand will take quality and quality. 
> "Screw speed and price! We want security and flawlessness!"


I like this. This is a great way to characterize the commonly found 
motives within the business.


Regards,

Jeremiah-