4 ms·

And everyone who depends on projects that pin their dependency versions gets to be victims of security exploits long after they are fixed. Dependency managemen

by btilly 7y ago

And everyone who depends on projects that pin their dependency versions gets to be victims of security exploits long after they are fixed. Dependency management is not as simple as you seem to think.

colinbartlett 7y ago
I’m working on a thing I’m calling DriftWatch that attempts to track, objectively, how far out of date you are on dependencies, which I call dependency drift. I’ve posted about it here before [1]. I’m using it in my consulting practice to show clients the importance of keeping up to date and it’s working well. I agree with the parent that it’s important to lock to avoid surprises (in Ruby, we commit the Gemfile.lock for this reason), but it’s equally as important to stay up to date. 1. https://nimbleindustries.io/2020/01/31/dependency-drift-a-metric-for-software-aging/ https://nimbleindustries.io/2020/01/31/dependency-drift-a-me...
- thawkins 7y ago
  There are commercial tools like blackduck, sonartype/nexus which are used to sczn dependancies of not1 just node code, and highlite ourof date packages, known vulnerabilities, and license problems.
montroser 7y ago
Well, I guess you can choose whichever poison you like. Pinning isn't meant to be a forever type of commitment. You're just saying, "all works as expected with this particular permutation of library code underneath." And the moment your dependencies release their hot-new you can retest and repin. Otherwise you're flying blind and this type of issue will arise without fail.
jessaustin 7y ago
The "magical security updates" theory has never worked. Breaking insufficiently-pinned dependencies are vastly more common than unnoticed fixes on patch releases. On balance, semver has been good for javascript, but to the extent it contributed to the popularization of this dumb theory it has been bad. Production apps (and by a transitive relation, one supposes, library modules) should be zealously pinned to the fewest possible dependencies, and those dependencies should be regularly monitored for updates. When those updates occur, tests can be run before updating the pins.
- stagas 7y ago
  Right, making significant changes to the entry points of a library should be marked as a breaking change and bump the major version.
- montroser 7y ago
  Yes -- pinning dependency versions does not have to be at odds with security. In fact, how secure is it, really, to keep dependencies unpinned and welcome literally /any/ random upstream code into your project, unchecked? This is yet more irresponsible than letting dependencies age. But even then, it's not as if you have to choose -- you can pin, then vet upstream updates when they come, and pin again.
Twirrim 7y ago
Tools like Safety can help in the python world, https://pypi.org/project/safety/ https://pypi.org/project/safety/, and cargo-audit https://github.com/rustsec/cargo-audit https://github.com/rustsec/cargo-audit in the rust world. Stick them in your build chain and get alerted to dependencies with known exploits, so you can revisit and bump your dependency versions, or decide that that project is not worth using if they can't be bothered to consider security to be as important a feature as it is.
bdcravens 7y ago
The unspoken assumption is that you don't just pin and move on with your life. You take as much ownership over your package.json as you do with your own code, and know that you must actively review and upgrade as necessary (as opposed to just running "npm install" and trusting in the wisdom of the cloud)
chrisan 7y ago
There are tools out there (like npm audit) that can alert you to known vulnerabilities.
bandrami 7y ago
And everyone who just upgrades whenever possible gets to be victims of security exploits too. Users of Debian Stable missed Heartbleed entirely. It simply never impacted them.
gberger 7y ago
What you do is you pin dependencies, then automate regular dependency upgrade PRs. If your test suite and your CI/CD pipeline is reliable, this should be an easy addition.
EdwardDiego 7y ago
We run Dependabot in our CI pipeline to flag security upgrades, and then action them. I'd much rather have that manual intervention than non-deterministic builds.

by btilly 7y ago

And everyone who depends on projects that pin their dependency versions gets to be victims of security exploits long after they are fixed. Dependency management is not as simple as you seem to think.

colinbartlett 7y ago

I’m working on a thing I’m calling DriftWatch that attempts to track, objectively, how far out of date you are on dependencies, which I call dependency drift. I’ve posted about it here before [1]. I’m using it in my consulting practice to show clients the importance of keeping up to date and it’s working well. I agree with the parent that it’s important to lock to avoid surprises (in Ruby, we commit the Gemfile.lock for this reason), but it’s equally as important to stay up to date. 1. https://nimbleindustries.io/2020/01/31/dependency-drift-a-metric-for-software-aging/ https://nimbleindustries.io/2020/01/31/dependency-drift-a-me...

thawkins 7y ago
There are commercial tools like blackduck, sonartype/nexus which are used to sczn dependancies of not1 just node code, and highlite ourof date packages, known vulnerabilities, and license problems.

montroser 7y ago

Well, I guess you can choose whichever poison you like. Pinning isn't meant to be a forever type of commitment. You're just saying, "all works as expected with this particular permutation of library code underneath." And the moment your dependencies release their hot-new you can retest and repin. Otherwise you're flying blind and this type of issue will arise without fail.

jessaustin 7y ago

The "magical security updates" theory has never worked. Breaking insufficiently-pinned dependencies are vastly more common than unnoticed fixes on patch releases. On balance, semver has been good for javascript, but to the extent it contributed to the popularization of this dumb theory it has been bad. Production apps (and by a transitive relation, one supposes, library modules) should be zealously pinned to the fewest possible dependencies, and those dependencies should be regularly monitored for updates. When those updates occur, tests can be run before updating the pins.

stagas 7y ago
Right, making significant changes to the entry points of a library should be marked as a breaking change and bump the major version.
montroser 7y ago
Yes -- pinning dependency versions does not have to be at odds with security. In fact, how secure is it, really, to keep dependencies unpinned and welcome literally /any/ random upstream code into your project, unchecked? This is yet more irresponsible than letting dependencies age. But even then, it's not as if you have to choose -- you can pin, then vet upstream updates when they come, and pin again.

Twirrim 7y ago

Tools like Safety can help in the python world, https://pypi.org/project/safety/ https://pypi.org/project/safety/, and cargo-audit https://github.com/rustsec/cargo-audit https://github.com/rustsec/cargo-audit in the rust world. Stick them in your build chain and get alerted to dependencies with known exploits, so you can revisit and bump your dependency versions, or decide that that project is not worth using if they can't be bothered to consider security to be as important a feature as it is.

bdcravens 7y ago

The unspoken assumption is that you don't just pin and move on with your life. You take as much ownership over your package.json as you do with your own code, and know that you must actively review and upgrade as necessary (as opposed to just running "npm install" and trusting in the wisdom of the cloud)

chrisan 7y ago

There are tools out there (like npm audit) that can alert you to known vulnerabilities.

bandrami 7y ago

And everyone who just upgrades whenever possible gets to be victims of security exploits too. Users of Debian Stable missed Heartbleed entirely. It simply never impacted them.

gberger 7y ago

What you do is you pin dependencies, then automate regular dependency upgrade PRs. If your test suite and your CI/CD pipeline is reliable, this should be an easy addition.

EdwardDiego 7y ago

We run Dependabot in our CI pipeline to flag security upgrades, and then action them. I'd much rather have that manual intervention than non-deterministic builds.