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
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
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.
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.).
> Being able to blame a supplier/library is almost always preferable to assuming the liability yourself
We like to optimize for actually keeping our customer’s data safe, rather than covering our butts :)
> 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.
For my part I work in defense, and our customers prefer to hear that we're using industry standard libraries and have tons of questions if we're rolling our own stuff (first of which is "why are you wasting our time and money reinventing the wheel?"). It reduces liability for them as well, they can tell their higher-ups that they approved proven, industry-standard solutions as much as possible and they're only paying us for our unique expertise.
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.