Why stop there? Why don’t we build our own OS before starting a project? Better yet, let's design and manufacture our own CPUs, because, well, "the cost of rolling our own has gotten so low". I’m not sure what to say; sometimes I think I live in a completely different dimension from some HN commenters.
It’s about the relative chance that someone’s CI infrastructure somewhere in the dependency change gets pwned in a way that allows malware to get into our dev environments or production servers. If we roll our own library for some functionality we need, that risk is 0. My point is the cost of doing so is much lower than it used to be, both in terms of implementation time and maintenance effort.
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
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.
I 100% disagree with this. Supply chain attacks are already at an all-time high due to agentic hacking assistance, and that trend shows no sign of slowing. Every dependency you add is another potential attack vector, and just checking the dependency’s code doesn’t solve the issue - your dependencies also have dependencies!
The cost of rolling your own has gotten so low that it’s almost always a better security tradeoff to reimplement the thing yourself. Is that a good thing? I’m not sure.