Actually CJC, it's often even worse than that.  In many cases, the customer or 
consumer has an implicit requirement for security that remains unstated.  Only 
when the system fails and is successfully attacked does that requirement shift 
from implicit to explicit.  "You mean it wasn't secure??  You've got to be 

In some sense that's what happened to Microsoft way back in the virus-bag days. 
 History shows that it is best to anticipate implicit requirements and address 
them as possible.



On 8/21/09 8:40 AM, "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).


Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Reply via email to