Time to dismount the hamster security wheel of pain
Quit patching, build a library
Enterprises are spending a huge amount of effort scanning for vulnerabilities that they already know are in their applications. Here's a little secret: there's no point in scanning if you haven't at least tried to put in a basic set of defenses. You already know you're vulnerable.
So what kinds of defenses does the average web application need? Here's a good way to figure it out. Take a look at the common application security vulnerabilities and then list the security controls that developers need to prevent those holes.
You'll end up with a list that includes authentication, session management, access control, input validation, canonicalization, output encoding, parameterized interfaces, encryption, hashing, random numbers, logging and error handling.
It's not reasonable to expect developers to build a secure application without a decent set of security controls for them to use. So how can you make them available? Here's what you could and what you probably should do.
Build your own security controls in each application
This is a bad idea. Writing security controls is both time consuming and extremely prone to mistakes. MITRE's CWE project lists more than 600 different types of security mistakes you can make, and most of them are not at all obvious. Most people recognize developers should not build their own encryption mechanisms; the same argument applies to all the security controls.
Use security libraries directly
Another bad idea. There are plenty of libraries and frameworks out there that provide various security functions - Log4j, Java Cryptographic Extension (JCE), Java Authentication and Authorization Service (JAAS), Spring Security, and dozens more. Some of them are even pretty good at what they do. But there are several reasons why enterprise developers should not use them directly.
Most importantly, these libraries are too powerful. Most developers need just a very limited set of security functions and don't require a complex interface. Further, many of these libraries contain security holes themselves - such as encoding libraries that don't canonicalize or authentication libraries that don't use strong cryptographic functions. Many security controls use features from other controls, and using security libraries that aren't integrated is a problem waiting to happen.
Establish an organization-wide standard security API
Now you're talking. Organizations that have institutionalized a standard application security control tend to have less vulnerabilities. And organizations that have standardized on a cryptographic library, and especially the ones that have wrapped that library in a standard encryption component, have significantly less problems in building and securing applications.