Fork your dependencies, trim them to only your use case, never update unless it breaks for your users. I’ve been vocal about this for 10+ years. I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored). If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies. If you dont see anything compelling, dont update! I remember at HashiCorp once in awhile an engineer would try to update a dep or replace a DIY lib with an external one and id always ask “show me the commit we need.” Dont update for the sake of it. Feeling pretty swell about this mentality with all the supply chain attacks happening.

May 20, 2026 · 6:48 PM UTC

289
773
8,952
1,254,226
Sort replies: Relevant Recent Liked
Replying to @mitchellh
I can only agree with your point of view on risk. But to be honest, my first reaction was that this was a very bad sign for the open source ecosystem. Open source projects need people to use them, discover and report compatibility issues or special cases.
2
20
17,550
Nah they don’t. Maintainers just want to do shit for fun. Almost nobody wants to be a supply chain. We just want to share our cool projects and provide it as is without warranty.
1
127
12,359
more replies
Replying to @mitchellh
I’m forking Windows and macOS keeping good stuff and removing all security risks 💪
2
6
3,901
Mitchell Hashimoto
@mitchellh
May 21
Replying to @jasonshah
That’s true for like… your OS or OpenSSL or something. But 99% of dependencies are something idiotic like a data structure or RGB color parser or something. Don’t update those if they work (esp if you’re already in a memory safe language)
8
4,417
Replying to @mitchellh
Main reason I love golang. It ships with pretty much everything out of the box.
6
3
303
46,922
The Go team that works on the stdlib has a pretty legendary quality/stability/security track record too.
2
8
699
39,911
Replying to @mitchellh
This is impossible and costs us more to update to major versions.
3
1
53
30,126
No, the security breaches cost more.
4
1
268
27,494
Replying to @mitchellh
Main caveat is if a critical vulnerability is discovered and the project is so many versions behind on that dependency that it need quite an uplift
1
47
16,819
No it doesn't, you fix the CVE out of band. Most times though, you're not affected because you're on a version so old or you're not even using that code path and you cut it out.
5
111
14,936
more replies
Replying to @mitchellh
what about when those older lib/package versions get compromised and you have to upgrade 7 major versions?
1
15
10,057
You never upgrade. You just patch in the functionality you need or treat it as a new dep and throw away the old (and re-review as necessary). Its just super rare to ever have to upgrade a dependency. Big dependency has fooled you into thinking you do.
3
1
85
9,062
Replying to @mitchellh
I agree in theory, but what about performance improvements or more importantly security patches that don’t necessarily get a CVE.
2
12
10,066
Measure your own code, if it isn't slow enough, who cares about performance (does it affect users? basically). I hear the security patch thing come up but its always hypothetical, I think on balance you expose yourself to more risk by updating than via latent exposure
1
52
9,247
Replying to @mitchellh
Doesn't work. We need a better strategy than forking.
Patrick Senti@productaizery
May 22
Replying to @ThePrimeagen
Been there done that. Not really sustainable unless you have a huge team just maintaining dependencies. I agree we need better ways to manage dependencies and the security of the supply chain, but forking is not it.
4
7
11,004
Worked well enough for me
3
18
5,318
more replies
Replying to @mitchellh
That’s great advice. You can maintain your forked dependencies all the time instead of delivering own stuff.

ALT Ok Nice Grafic GIF

1
2
1,062
In reality you never really need to touch them. Updates are a mind virus. Most functionality is "finished".
2
10
1,334
more replies
Replying to @mitchellh
What is your threshold for upgrading for a vulnerability?
1
3,269
Almost zero. Look at the upstream report, look at the code affected, see if you use it (9 out of 10 vulnerabilities become moot here). If you don't use it, make sure you just delete the code out of your fork. If you do use it, adapt their patch and verify. Nver update.
1
11
3,013
Replying to @mitchellh
What OS do you use? Is that a dependency for your app?
1
1,302
Mitchell Hashimoto
@mitchellh
May 21
Replying to @jasonshah
That’s true for like… your OS or OpenSSL or something. But 99% of dependencies are something idiotic like a data structure or RGB color parser or something. Don’t update those if they work (esp if you’re already in a memory safe language)
1
3
1,825
more replies
Load more