[SC-L] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)

[Cassidy, Colin (GE Infra, Energy)]

Martin Gilje Jaatun wrote:
 
> Karen, Matt & all,
> 
> Goertzel, Karen [USA] wrote:
> > I'm more devious. I think what needs to happen is that we 
> need to redefine what we mean by "functionally correct" or 
> "quality" code. If determination of functional correctness 
> were extended from "must operate as specified under expected 
> conditions" to "must operate as specified under all 
> conditions", functional correctness would necessarily require 
> security, safety, fault tolerance, and all those other good 
> things that make software dependable instead of just correct.
> >   
> I couldn't agree more!
> 
> However, I have had several discussions with a colleague who is fairly
> well known in the"Software Process Improvement Mafia" on the topic of
> how to ensure that security requirements are considered for 
> _all_ kinds
> of code, not just "security software". Particularily in the context of
> agile development techniques, security keeps getting the short end of
> the stick, losing every time to "working features". His stance on this
> is that "if security were important to the customer, the 
> customer would
> provide and prioritize security requirements". To me, this is 
> a bit like
> saying "If the customer doesn't explicitly state that the software
> should be Y2k-proof, he/she is not really bothered about it".

The problem (certainly as I see it) is that the customer is likely to say
"Make it secure" without really understanding what that means.  Secure
against what exactly?

Or you'll get a list of security features that the customer wants, but as we
all know security features != secure product.

Instead we've taken a combined approach of including customer requirements
and adding specific requirements of our own focusing a good Secure
development practices.

> If we can "brainwash" the coming generations of programmers into
> accepting Karen's definition of "quality code", we might finally be
> getting somewhere.

And that's the trick we've been attempting here.  Secure software is nothing
more than really good quality code.  We already use coding guidelines and
have a strong(ish) process of code reviews.  So we have augmented our coding
and review guidelines to include secure coding aspect such as input/output
validation, good memory management etc. 

That said there is still a lot of scope for improvement in the rest of the
software development process (testing and design in particular).

CJC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4427 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20090821/7180bd1c/attachment-0001.bin