3 ms·
I also strongly disagree with his take on dependency pinning: > Solutions to this problem are running SCA combined with automatic updates at every build and ho
by richbell 4y ago
I also strongly disagree with his take on dependency pinning:
> Solutions to this problem are running SCA combined with automatic updates at every build and hot patching in production. What is not a solution to this is dependency pinning, a technique getting widespread adoption but very dangerous for security in the real world
Not pinning versions is a small benefit — automatically downloading the latest compatible version of a dependency — at the risk of enabling a whole new layer of supply chain attacks. I don't want npm to automatically download a dependency that was published 3 minutes ago and hasn't been vetted or tested by anyone.
- markcurphey 4y agoPoint taken and there are two trains of thought. The way I think about it is that it's a double edged sword. If you have already trusted a dependancy then trusting an update is a risk but less than the risk of having known vulnerable versions. I rarely see developers actually looking at the code of new versions when upgrading. My take on all this is a pessimistic one based on what I have seen and not on best practices. If teams I saw reviewed the updates I would fall on the pinned side of the sword.
- robertlagrant 4y agoYou might trust a dependency from a security perspective, but they might still have accidentally introduced a breaking change into a non-major version bump. It seems like a recipe for disaster to deploy other versions of dependencies (which might pull in further different versions of transitive dependencies) and assume it'll all work.