5 ms·

Needlessly upgrading all of your packages leaves you open to supply chain attacks. If one of those NPM packages got quietly compromised (and my lockfile likely

Needlessly upgrading all of your packages leaves you open to supply chain attacks. If one of those NPM packages got quietly compromised (and my lockfile likely has 4-to-5 digits worth of dependencies in it), you invested time in making what amounts to an unneeded change to expose yourself.

duped 5y ago
The only real defense to supply chain attacks are audits and self hosted dependencies/packages.
- roblabla 5y ago
  > self hosted dependencies/packages. Why? If your lockfile specifies and enforces the hash of the package, you don't need to self-host it - the lockfile will take care of detecting supply chain compromises that swaps a package with another. 100% agree on audits being necessary.
  - delusional 5y ago
    You're still downloading random stuff from the internet. A vulnerability in your package manager could let an attacker bypass the hash check, or they could discover a hash collision. If you really want to be sure, having the exact bits on a system you control seems like the right move.
  - charcircuit 5y ago
    Self hosting protects against attacks against the availability of your supply chain.
raffraffraff 5y ago
Ok, so let's say it's day one: how do you choose all of your initial pinned versions? How do you know they're safe? What if you luck-out in the supply chain attack lottery and pin malware?
- 88913527 5y ago
  Older packages are more likely to be vetted as non-problematic than newer packages. As time goes own, the vulnerabilities are disclosed. If you're upgrading to a package that's 1 day old, the community hasn't had the time to go through that process and disseminate the vulnerability. Your point is valid, but I think it's an increased risk since time is against you when you accept fresher, newer, unproven versions of your dependencies.
  - delusional 5y ago
    I think you're right that cutting edge carries the risk of introducing new vulnerabilities that haven't been observed yet. And the closer you are to release, the less time the security community has had to look into it. Conversely, there's also a factor that says that after some time, the security community will stop looking at a specific version. Even if that version still has vulnerabilities. Those two factors lead me to believe there's some sort of sweet spot. You probably don't want the cutting edge newest version, but you still want a version new enough that it's in widespread use.
cogman10 5y ago
Any bit of software can have a very nasty vulnerability (looking at you, log4j). Leaving your software pinned to old versions exposes you to existing undiscovered CVEs. This is a pick your poison circumstance.
- PeterisP 5y ago
  In general, for undiscovered CVEs new versions will be as exposed as old versions - if the bug was not discovered, it was not fixed as well; and if the latest version fixes an exploitable security flaw then there generally will be a CVE issued along with that release. Using the same log4j as an example, all the (many!) projects which were still using the old 1.x log4j branch were not exposed, but those who were using the latest released version were exposed to the undiscovered CVE at the moment it was released. IMHO a reasonable compromise is to watch for discovered CVEs and update your dependencies when appropriate, but keep them pinned if no known CVEs apply.

duped 5y ago

The only real defense to supply chain attacks are audits and self hosted dependencies/packages.

roblabla 5y ago
> self hosted dependencies/packages. Why? If your lockfile specifies and enforces the hash of the package, you don't need to self-host it - the lockfile will take care of detecting supply chain compromises that swaps a package with another. 100% agree on audits being necessary.
- delusional 5y ago
  You're still downloading random stuff from the internet. A vulnerability in your package manager could let an attacker bypass the hash check, or they could discover a hash collision. If you really want to be sure, having the exact bits on a system you control seems like the right move.
- charcircuit 5y ago
  Self hosting protects against attacks against the availability of your supply chain.

raffraffraff 5y ago

Ok, so let's say it's day one: how do you choose all of your initial pinned versions? How do you know they're safe? What if you luck-out in the supply chain attack lottery and pin malware?

88913527 5y ago
Older packages are more likely to be vetted as non-problematic than newer packages. As time goes own, the vulnerabilities are disclosed. If you're upgrading to a package that's 1 day old, the community hasn't had the time to go through that process and disseminate the vulnerability. Your point is valid, but I think it's an increased risk since time is against you when you accept fresher, newer, unproven versions of your dependencies.
- delusional 5y ago
  I think you're right that cutting edge carries the risk of introducing new vulnerabilities that haven't been observed yet. And the closer you are to release, the less time the security community has had to look into it. Conversely, there's also a factor that says that after some time, the security community will stop looking at a specific version. Even if that version still has vulnerabilities. Those two factors lead me to believe there's some sort of sweet spot. You probably don't want the cutting edge newest version, but you still want a version new enough that it's in widespread use.

cogman10 5y ago

Any bit of software can have a very nasty vulnerability (looking at you, log4j). Leaving your software pinned to old versions exposes you to existing undiscovered CVEs. This is a pick your poison circumstance.

PeterisP 5y ago
In general, for undiscovered CVEs new versions will be as exposed as old versions - if the bug was not discovered, it was not fixed as well; and if the latest version fixes an exploitable security flaw then there generally will be a CVE issued along with that release. Using the same log4j as an example, all the (many!) projects which were still using the old 1.x log4j branch were not exposed, but those who were using the latest released version were exposed to the undiscovered CVE at the moment it was released. IMHO a reasonable compromise is to watch for discovered CVEs and update your dependencies when appropriate, but keep them pinned if no known CVEs apply.