To be sure, "inherently secure code" is a misnomer. However, that being said, my original contention was that certain common vulnerabilities should be automatically managed these days rather than relying on explicit code to catch them. Should any sort of overflow really be allowed? I have to believe there are ways to safely trap those - perhaps they result in an abend, but at least not in a manner that achieves the goals of a compromise attempt. Similarly, it seems that there should be ways to force the deserialization and parsing of data that could be safer than allowing raw, unvalidated input to be acted upon.
I wonder, too, if part of the error in the curriculum thread is focusing too low-level - that is, instead of focusing just on coding skills, maybe there should also be a larger discussion of publishing frameworks, development environments, etc., that introduce a lot of these security capabilities as inherited properties/functions? Done properly, it would lead to inherently better properties. fwiw. -ben Peter G. Neumann wrote: > I don't much like INHERENTLY SECURE CODE. > Software components by themselves are not secure. > Security (and trustworthiness that encompasses security, reliability, > survivability, etc.) is an emergent property of the entire system > or enterprise. To say that a component is secure is rather fatuous. > > See my DARPA report on composable trustworthy architectures for > starters. > http://www.csl.sri.com/neumann/chats4.pdf or .html > > _______________________________________________ > 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. > _______________________________________________ > > -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] "We can't solve problems by using the same kind of thinking we used when we created them." Albert Einstein _______________________________________________ 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. _______________________________________________
