Software security - sad state

Events over the last year have pushed me to investigate software security much closer.

The summary of my thoughts are (somewhat just common sense):

• Developer statements regarding secure coding practices only have real weight if the developers have substantial security training.
• Security is a joke if not part of the initial design.
• Statements from application designers regarding security only have weight if the designer has some security training.
• Systems are at the mercy of their libraries and frameworks.  
• If you use Struts, I think you should be very concerned.
• Libraries and frameworks should be refreshed (or at least reviewed) regularly. 
• It is a bad idea to use extra functionality in libraries "just because you can" versus a realistic need.  I would recommend throw-away prototypes of tools as learning tools instead of high profile production applications.
• Put lots of time into understanding default configurations and any functionality which allows you to disable unneeded functionality. 
• Layers of security are needed.
• Too many people underestimate security needs and don't worry about it unless you end up in the news.  Not being in the news implies that they are doing something right from their perspective - hard to change that. 
• Security is not implement and forget functionality.
• Software companies want to sell you "just one more" layer of security.  Shaped like a silver bullet in worst case.  Other times it indicates it is green product - i.e. much recycled content.
• Security regression tests would be useful.
• Automated security tests, in general, would be a benefit.  Problem is time and resources though. 

I have a few other thoughts I am mulling over;

• The root of many issues is the generalist nature of systems and a hierarchical nature of dependencies. Example:
• Programming frameworks support much more functionality than will be used in individual applications.  Some of that functionality has security implications - such as the ability to launch a new OS process.
• Regarding the previous item, the framework leverages generic functionality in the language runtime to launch a process.
• The  programming language runtime uses OS level support to launch processes.  
• The OS support for launching processes is normally provided in the form of a shared library which provides generic services.
• The shared library services are available to all applications with access to the library.

Restricting access to functionality, such as launching processes, is possible via things such as SELinux but:

1. The complexity is pretty high which also leads to potential errors
2. Harder to provide justification to management for the required time with the ever increasing pace of software development.  
3. This particular solution affects entire servers and most likely many servers.

Other possibilities exist to restrict functionality at the language runtime level (i.e. Java process).  An example of this is implementing a Java Security Manager & appropriate policy.

1. This implies that a large number of activities need to be white listed.  That just isn't reasonable or feasible in some cases due to the amount of code involved and the resources available to maintain the policy.
2. Any change in the environment (i.e. lib or framework version) effectively requires a total security review to prevent inclusion of unused white list entries.

So white listing is difficult because:

1. It is an all or nothing process (i.e. affects an entire server or entire application).  
2. Much of the work is related to 3rd party software (libs and frameworks) for which you would need to figure out the needs from scratch.  

Alternatively, if you are working from a blacklist only standpoint:

1. You may miss items and have unexpected security holes.
2. There are few methods available for blacklisting probably because of issues related to item 1.

If Java flags existed which disabled functionality (process launching), it could be considered a form of blacklisting (functionality).  At the moment, I don't believe any flags like this exist. 

*****
Work in progress.. Rewording some sections needed to clarify the intended thought.  Overall, there has got to be a better way to deal with security (especially in substantially resource constrained shops).