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