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