I was thinking, Instead of the next frontier, how about another frontier? Many software vendors pretend that the entire world is either Java or .NET without acknowledging that all of the really good data in many enterprises is sitting on a big ugly mainframe running COBOL, IMS, PL/1, etc. It is assumed at this level that most folks in this space have zero knowledge of these platforms and hence the reason their tools don't support.
It is my current thought that us folks in enterprises could do several things. First, we have the environment that others may not have access to. Second, we have employees that can help write specifications for detecting some aspects (they are not secure coding oriented but do understand things like buffer overflows) in PL1, COBOL, Assembler, etc. If the later is of value, we would of course like to figure out how to make this happen with one effort where every vendor could potentially consume and not do it for a single vendor. ************************************************************************* 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. _______________________________________________
