Re:The Lisp curse, now coming to your ecosystem
by scottLobster on Thursday November 05, 2026 @11:07PM
(#50388055)
Well if you have the time and money to do a full security audit of these new libraries you're rolling, more power to you. And you excluded a lot of stuff I was thinking of, so that changes the argument. If these are non-critical dependencies then sure, do whatever you like.
> 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.
Re:The Lisp curse, now coming to your ecosystem
by jdormit on Saturday November 07, 2026 @07:05PM
(#50409261)
> If these are non-critical dependencies then sure, do whatever you like.
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.
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.).