I work for a company that provides compliance services to banks, we take our security responsibilities very seriously.
The risk associated with introducing a new dependency to the codebase has now exceeded the risk associated with implementing something ourselves in most cases (the exceptions being the obvious ones: crypto, auth, server frameworks, etc.).
> We like to optimize for actually keeping our customer’s data safe, rather than covering our butts :)
If you have the budget to back that up I'm jealous. Otherwise, pride cometh before a fall. I'm curious how you conducted that risk analysis. Just because a common COTS library has more documented vulnerabilities doesn't inherently mean your hand-rolled option has less, and the difference would naturally vary from library to library.
That’s the whole point. Pre-AI, it was usually the right move to rely on dependencies to accomplish many things. But even though these dependencies are non-critical, a supply chain attack on them will own you just as hard as a vulnerability in your web framework. Now, you can use AI to eliminate that risk.
Most of these huge AI discoveries of vulnerabilities have not been through probing an unknown server with a custom stack. They've been through probing a known/discoverable tech stack that is open source. Security through obscurity is never good, but if anything, the next couple years on known tech stacks is going to be worse.
> Being able to blame a supplier/library is almost always preferable to assuming the liability yourself
This only works if it's Log4j, or PHP, or some big vulnerability that hits mainstream news. Clients do not care if the tiny library only you picked had a vulnerability in it, and they shouldn't either.
Also, you clearly don't work with products that have any sort of serious corporate liability. Being able to blame a supplier/library is almost always preferable to assuming the liability yourself