3 ms·

I don't agree that nobody is adopting them. Can you please elaborate? - Most companies I know have a 24 hours (at least) cooldown via their Artifactory / Nexus

I don't agree that nobody is adopting them. Can you please elaborate? - Most companies I know have a 24 hours (at least) cooldown via their Artifactory / Nexus. They have ways to bypass it for urgent CVEs - pnpm just adopted 24 hours cooldown as default, based on community feedback.

doctorpangloss 4mo ago
what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly exploited - either by using known vulnerable software or from supply chain attacked software.
- eranation 4mo ago
  It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.
  - deleted 4mo ago
    [deleted]
- AshamedBadger56 4mo ago
  I believe the point is that if you delay patches until X days after release, usually someone will catch it and the maintainer or the package manager will pull the infected release. Thus, by you doing nothing and waiting X days, you protect yourself by never even getting the bad release. Then on the flip side, you just keep up with urgent security updates and push bad ones through faster after vetting them.
  - doctorpangloss 4mo ago
    [dead]
- rcxdude 4mo ago
  The kind of 'urgent CVE' situation they're describing generally involves you learning about it out-of-band and then rushing to deploy an update. If you learn about a supply chain attack, oops, you might already have been pwned in the meantime, depending on when your builds ran. If you learn about an important CVE, you're not going to count on what's deployed already being patched, you're going to at a minimum check if not force an update.
  - doctorpangloss 4mo ago
    You might have been "pwned" in the meantime waiting for 7 days! If I'm checking, I have to check everything no? That's just updating every dependency! Am I taking crazy pills? Obviously cooldowns don't work.
    - rcxdude 4mo ago
      If you install a package that has been part of a supply chain attack, you definitely have a problem. If you have a dependency with a vulnerability, you might have a problem, and any really bad one you are likely to find out about anyway. You can also subscribe to notifications for CVEs as well. Obviously, you would ideally be reviewing every update to every dependency manually, and reviewing them for security problems as well, but in the absence of the resources to do that, the risk balance for cooldowns makes a decent amount of sense (especially since the number of high-profile everyone-patch-now vulnerabilities in the npm ecosystem is now a fair bit smaller than the number of supply chain attacks).
    - dns_snek 4mo ago
      Do you update your dependencies and push to production every single day? Saturdays and sundays too? What are the chances that your code is using a vulnerable dependency AND doing so in an exploitable manner AND the vulnerability being serious enough to warrant immediate attention? The likelihood of that is extremely low unless you're high-profile enough to have a team dedicated to this. 99.9% of vulnerabilities in your dependencies aren't actually exploitable in your project. Most exploitable vulnerabilities probably aren't that serious. And even if it's serious, it's unlikely that you would be targeted immediately. On the other hand you have a constant stream of unreviewed dependency updates, each one having a small chance of containing malicious code. The most pragmatic approach, IMO, is to set up alerts for high severity CVEs, cooldown of at least 24h, and only execute code in per-project sandboxes (VMs or containers). 1 day is short enough that it would practically never be a problem, regardless of severity. It's historically been long enough to discover the vast majority of these supply chain attacks, and alerting for high severity CVEs is something you should be doing anyway if you're worried about security.

doctorpangloss 4mo ago

what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly exploited - either by using known vulnerable software or from supply chain attacked software.

eranation 4mo ago
It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.
- deleted 4mo ago
  [deleted]
AshamedBadger56 4mo ago
I believe the point is that if you delay patches until X days after release, usually someone will catch it and the maintainer or the package manager will pull the infected release. Thus, by you doing nothing and waiting X days, you protect yourself by never even getting the bad release. Then on the flip side, you just keep up with urgent security updates and push bad ones through faster after vetting them.
- doctorpangloss 4mo ago
  [dead]
rcxdude 4mo ago
The kind of 'urgent CVE' situation they're describing generally involves you learning about it out-of-band and then rushing to deploy an update. If you learn about a supply chain attack, oops, you might already have been pwned in the meantime, depending on when your builds ran. If you learn about an important CVE, you're not going to count on what's deployed already being patched, you're going to at a minimum check if not force an update.
- doctorpangloss 4mo ago
  You might have been "pwned" in the meantime waiting for 7 days! If I'm checking, I have to check everything no? That's just updating every dependency! Am I taking crazy pills? Obviously cooldowns don't work.
  - rcxdude 4mo ago
    If you install a package that has been part of a supply chain attack, you definitely have a problem. If you have a dependency with a vulnerability, you might have a problem, and any really bad one you are likely to find out about anyway. You can also subscribe to notifications for CVEs as well. Obviously, you would ideally be reviewing every update to every dependency manually, and reviewing them for security problems as well, but in the absence of the resources to do that, the risk balance for cooldowns makes a decent amount of sense (especially since the number of high-profile everyone-patch-now vulnerabilities in the npm ecosystem is now a fair bit smaller than the number of supply chain attacks).
  - dns_snek 4mo ago
    Do you update your dependencies and push to production every single day? Saturdays and sundays too? What are the chances that your code is using a vulnerable dependency AND doing so in an exploitable manner AND the vulnerability being serious enough to warrant immediate attention? The likelihood of that is extremely low unless you're high-profile enough to have a team dedicated to this. 99.9% of vulnerabilities in your dependencies aren't actually exploitable in your project. Most exploitable vulnerabilities probably aren't that serious. And even if it's serious, it's unlikely that you would be targeted immediately. On the other hand you have a constant stream of unreviewed dependency updates, each one having a small chance of containing malicious code. The most pragmatic approach, IMO, is to set up alerts for high severity CVEs, cooldown of at least 24h, and only execute code in per-project sandboxes (VMs or containers). 1 day is short enough that it would practically never be a problem, regardless of severity. It's historically been long enough to discover the vast majority of these supply chain attacks, and alerting for high severity CVEs is something you should be doing anyway if you're worried about security.