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".

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


Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.

Reply via email to