Trends in security code reviews?

I am looking for pointers to info about how many companies are doing
security code reviews (as a normal part of software development) now
compared to 2003 or 2002. I would expect that the number is increasing, but
would like some credible background info. Along those lines, can there be a
way to assess how many professionals are truly qualified to do security code
reviews?

Also, does anyone have pointers to info that shows losses incurred by
companies that don't do security code reviews compared to companies that do?

And yes, I'm looking for this info to help justify to management that
implementing a software security program will provide a positive ROSI
(Return on Security Investment).

Thanks for any information.

Bit Tamer, CISSP

 

I have been asked that also but, here is what I found. After doing some
research I was frustrated by:

First, to review code is almost impossible. Most companies will NOT release
their code. They might give you some teasers but not the full code base.
GNU/Linux/BSD is a good option which is what I have been pushing. A far as
qualified personnel I think that anyone with a CS degree and some
experience would be adequate.

As far as your second question "...losses by companies..." most companies
try to bury this information. From the CIO not wanting to look foolish
onward down...this information is most often covered up.

I have been in your boat though. I have tried giving information, why this
is the way to go. However, it is a difficult and uphill battle.

Let me know how you do and good luck,
Michael

 

:> And yes, I'm looking for this info to help justify to management that
:> implementing a software security program will provide a positive ROSI
:> (Return on Security Investment).

:First, to review code is almost impossible. Most companies will NOT release
:their code. They might give you some teasers but not the full code base.

Bit Tamer didn't ask for that. He is interested in his -own- company's
development practices, and would like to hear about what other companies
have done internally and how well it has turned out.

:A far as
:qualified personnel I think that anyone with a CS degree and some
:experience would be adequate.

Heavens, no!! You don't give security reviews to a plain CS degree with
a bit of experience! Such people do not have the experience to recognize
and weigh risks and development consequences.


The kinds of people you would give such work to would include:

- the professionally paranoid who have demonstrated ability to
lock down systems with acceptable time/money/human-cost tradeoffs

- code testers with a proven track record of finding and reporting
bugs in behaviours that others wouldn't even think of trying

- the person who regularily follows comp.risks (aka Risks Digest) -- and
contributes to it

- the software engineer -- in the sense of someone who cares about
the -process- of producing programs, not just about getting their
own code out

- the quiz who knows and cares about IEEE 754 and can spot bad
mathematics faster than it would take most people to notice
the blob of mustard in the middle of the page

- the hacker in the back room who might not be the fastest programmer
around, but who is the only one in the company who can be handed an
underdocumented disaster that has been a decade in the making and turn it
into clean maintainable code. This type is quite uncommon: the
typical CS grad wants to do *new* work, not debug old code. There are
not many who can read between the lines of oodles of bad code to figure
out what the code is -intended- to do; it's not really the same skill as
debugging, which involves taking an identified misbehaviour and tracking
down the cause.