@mitchellh Well, these days you can setup an agent to monitor upstream to pull in minor/patch updates or backport security fixes which lowers the time cost for maintenance ig. Though I'm still unsure if the security outcomes are better with this approach than upgrading.
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.
@mitchellh Seems like a lot of overhead instead of upgrading with the added downside that existing tooling may not accurately alert you about future cve patches.
And trimming is only helping reduce supply chain risk but if a vulnerable code path is unreachable trimming doesn't help?
@mitchellh What does it look like in practice?
So you fork, trim them down only to the functions you need.
How do you make sure it's maintained? What if there are bug fixes in later versions you can't simply cherry-pick?
@thedawgyg Thanks for responding. I totally agree with the learning by doing approach, that's what I prefer as well. But sometimes it gets difficult to figure out where to start with so much info everywhere? Do you face that? How do you overcome that?