There are several perspectives missing from the dialog: - Before we even talk about secure coding, we need a course on secure thinking. Most folks are indoctrinated into thinking positive which blinds them from seeing vulnerabilities right in front of them. A prereq on being antisocial might be a good start
- For those who work in large enterprises, the positive thinking is even further reinforced where even functional delivery takes a back seat to perception management. In order for secure coding to mature, folks need the ability for someone to not get offended so easily. A good first step may be figuring out a way to tell someone that their code sucks without ending up in HR (observed but not personal) - Taking this one step further, how can we convince professors who don't teach secure coding to not accept insecure code from their students. Professors seed the students thinking by accepting anything that barely works at the last minute. Universities need to be consistent amongst their own teaching/thinking. ************************************************************ This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************ _______________________________________________ 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. _______________________________________________
