> --- the software should work and be secure (co-requirements).

And already we have trouble, because this immediately raises not only
the question "what does `work' mean?" but also "secure against what?".

And answering that correctly requires input from the customer.  Which
we (TINW) won't have until customers recognize a need for security and
get enough clue to know what they want to be secure against.

And we all know how likely customers are to have clue (of just about
any sort).

(Actually, there are markets where the customer usually is clued.
Oddly enough, they also tend to be markets wherein software isn't
security Swiss cheese. :-)

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               [EMAIL PROTECTED]
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
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