process a change is made, the more costly the change will be and the more likely that it will have unintended consequences. Therefore, even though an after-the-fact security review is an extremely valuable assessment tool, it does not work as a primary mechanism to achieve application security.
In general, better training and management of developers is extremely valuable. However, this approach does not address the full need. In practice, deployed environments always contain applications that were built under varying development procedures by varying teams at various times. Therefore, better training for the current in-house team does not provide the breadth and consistency of coverage required.
Similarly, capabilities such as encryption libraries and connections to authentication authorities, that are built in to a single development environment or runtime application server are insufficient to meet an organization's full security needs. While those capabilities would then be available to developers writing new code for a given application server or development environment, they do not address legacy or packaged applications that do not use those tools.
Furthermore, simply providing an underlying mechanism isn't enough. It was still being left to the developer to write code that provided the logic that determined for a given combination of operations, service requests, and message content which specific security mechanism should be used.
For example, it's useful to have libraries built in to an application server for producing XML encryption and SSL encryption. However, that is only half the battle. You still need logic that determines whether or not encryption should be used, and, if so, what type of encryption, which key should be used, where to access that key, and so on.
[an error occurred while processing this directive]
