4 ms·

Aren't we back to the drawing board once everyone uses this?

ihumanable 5mo ago
Yea, all the new advice around using dependency cooldowns only works if _someone_ is installing these things before you and finding the vulnerabilities. It seems like the advice right now is to become a freerider while there are still people installing closer to release that will do free work for you finding out there's something nasty in the release. Once everyone is waiting 2 weeks to install an update, then the value of everyone waiting goes down dramatically.
- kbenson 5mo ago
  This is how a chunk of people function anyway. There are plenty of people that choose to not install "point zero" release for software of a certain importance, assuming with any major changes there are often bugs that come along with it. In this case, since the number of cool down days is configurable, even if everyone was using it we would still likely see a somewhat smooth curve for adoption, since not everyone will choose the same delay and the delay time will likely map closely to how people want to habdke risk. It's all a trade off, just like it's always been. This just makes it simpler to act on what you want your risk/comfort level to be.
- postalcoder 5mo ago
  Using dependency cooldowns is not a free-rider problem. There's a real tradeoff here – ppl are trading their time preference for security. Just as users are incentivized to avoid malware, researchers and attackers are equally motivated to be the first to discover it. The concern trolling around widespread dependency cooldowns doesn't make sense. Most people shouldn't be eager to download a release that hasn't made its way through at least some scans.
password4321 5mo ago
The point is to allow the automated scanners a chance to run. Every security company and their cousin wants to be the one to find the next big dependency malware.
- x0x0 5mo ago
  The idea that a package can be updated and with a deploy at the right time could be live on your servers in prod 10 minutes later has always been crazy, and the last years have just reinforced that. People are encouraged by package managers to treat any bit of code someone tosses onto a package manager as equivalent in reliability to the core language and sdk.
grncdr 5mo ago
I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.
- woodruffw 5mo ago
  Yep, this is the thesis behind them. I wish people engaged more fully with this argument: it’s possible to believe that security vendors won’t do a good job of upholding their side of the bargain, but I’ve yet to see anybody argue that rather than making a faulty universalization argument against cooldowns.
  - mike_hock 4mo ago
    Anything that isn't blatantly obvious zero effort malware is gonna wait for the cooldown to expire and then gradually introduce backdoors or vulnerabilities in subsequent versions once the project has gained trust.
    - woodruffw 4mo ago
      I think you’re talking about something different than the median case here: the kinds of malware that cooldowns are effective against are attacking already trusted projects, e.g. via repository compromise. I think it remains to be seen whether the economics of this kind of “supply chain” compromise support a stealthier actor profile: the whole reason to compromise an OSS project rather than exploit a single victim’s browser or phone is to smash-and-grab en masse. That’s a fundamentally noisy and delay-sensitive attacker profile.
  - rendaw 4mo ago
    How many people are paying security firms to test these things during the cooldown period? Which security firms are testing which packages?
    - woodruffw 4mo ago
      > How many people are paying security firms to test these things during the cooldown period? More than I think should be, frankly. More than enough for a sustainable industry. As for “which firms”: if you Google any of the recent dependency compromises, you’ll see their names. My rough guess is that there are somewhere between 12 and 20 active players in the “supply chain security” space, and they generally compete for mindshare with blogspam. That’s not to say their scanning results aren’t good, though.
teeray 5mo ago
It basically devolves into a Volunteer’s Dilemma. There’s no incentive here to be the guinea pig, so nobody will want to be.
- embedding-shape 5mo ago
  > It basically devolves into a Volunteer’s Dilemma. There’s no incentive here to be the guinea pig, so nobody will want to be. Except there is lots to gain from being the first to write about the new malware on some registry, so companies are actively downloading and inspecting literally every package. Back in the day (maybe 6-7 years ago?) you could detect this by uploading a new npm package that hit back some endpoint in your control, and it was almost guaranteed that this endpoint got a request within a minute of publishing a new package or update to existing one with users. Nowadays I think none of the scanners actually run the code, mostly static-analysis, and I dunno how often the npm download counter updates per day, probably harder to see in real-time.
  - teeray 5mo ago
    > Except there is lots to gain from being the first to write about the new malware on some registry Show me the company writing to their customers “we intentionally decided to ship code with potentially novel vulnerabilities. One of those vulnerabilities caused disclosure of your data, but cheer up! We have this cool security blog post about it now.” Meanwhile their competitors freeride and their customers’ data is safe.
    - weaksauce 5mo ago
      security researchers not the ones shipping the faulty code.
      - teeray 5mo ago
        We’re not talking about security researchers here: > there is lots to gain from being the first to write about the new malware on some registry, so *companies* are actively downloading and inspecting literally every package. (Emphasis mine)
raesene9 5mo ago
not really, there are a number of security companies doing analysis of any new packages looking for supply chain attacks, so if you wait a couple of days, till their analysis is complete, you're reducing the risk of hitting a compromised package.
nicoburns 4mo ago
Yep! We ultimately need better tooling for crowd-sourced manual auditing, not just a delay.

Yea, all the new advice around using dependency cooldowns only works if _someone_ is installing these things before you and finding the vulnerabilities. It seems like the advice right now is to become a freerider while there are still people installing closer to release that will do free work for you finding out there's something nasty in the release. Once everyone is waiting 2 weeks to install an update, then the value of everyone waiting goes down dramatically.

kbenson 5mo ago
This is how a chunk of people function anyway. There are plenty of people that choose to not install "point zero" release for software of a certain importance, assuming with any major changes there are often bugs that come along with it. In this case, since the number of cool down days is configurable, even if everyone was using it we would still likely see a somewhat smooth curve for adoption, since not everyone will choose the same delay and the delay time will likely map closely to how people want to habdke risk. It's all a trade off, just like it's always been. This just makes it simpler to act on what you want your risk/comfort level to be.
postalcoder 5mo ago
Using dependency cooldowns is not a free-rider problem. There's a real tradeoff here – ppl are trading their time preference for security. Just as users are incentivized to avoid malware, researchers and attackers are equally motivated to be the first to discover it. The concern trolling around widespread dependency cooldowns doesn't make sense. Most people shouldn't be eager to download a release that hasn't made its way through at least some scans.

password4321 5mo ago

The point is to allow the automated scanners a chance to run. Every security company and their cousin wants to be the one to find the next big dependency malware.

x0x0 5mo ago
The idea that a package can be updated and with a deploy at the right time could be live on your servers in prod 10 minutes later has always been crazy, and the last years have just reinforced that. People are encouraged by package managers to treat any bit of code someone tosses onto a package manager as equivalent in reliability to the core language and sdk.

grncdr 5mo ago

I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.

woodruffw 5mo ago
Yep, this is the thesis behind them. I wish people engaged more fully with this argument: it’s possible to believe that security vendors won’t do a good job of upholding their side of the bargain, but I’ve yet to see anybody argue that rather than making a faulty universalization argument against cooldowns.
- mike_hock 4mo ago
  Anything that isn't blatantly obvious zero effort malware is gonna wait for the cooldown to expire and then gradually introduce backdoors or vulnerabilities in subsequent versions once the project has gained trust.
  - woodruffw 4mo ago
    I think you’re talking about something different than the median case here: the kinds of malware that cooldowns are effective against are attacking already trusted projects, e.g. via repository compromise. I think it remains to be seen whether the economics of this kind of “supply chain” compromise support a stealthier actor profile: the whole reason to compromise an OSS project rather than exploit a single victim’s browser or phone is to smash-and-grab en masse. That’s a fundamentally noisy and delay-sensitive attacker profile.
- rendaw 4mo ago
  How many people are paying security firms to test these things during the cooldown period? Which security firms are testing which packages?
  - woodruffw 4mo ago
    > How many people are paying security firms to test these things during the cooldown period? More than I think should be, frankly. More than enough for a sustainable industry. As for “which firms”: if you Google any of the recent dependency compromises, you’ll see their names. My rough guess is that there are somewhere between 12 and 20 active players in the “supply chain security” space, and they generally compete for mindshare with blogspam. That’s not to say their scanning results aren’t good, though.

teeray 5mo ago

It basically devolves into a Volunteer’s Dilemma. There’s no incentive here to be the guinea pig, so nobody will want to be.

embedding-shape 5mo ago
> It basically devolves into a Volunteer’s Dilemma. There’s no incentive here to be the guinea pig, so nobody will want to be. Except there is lots to gain from being the first to write about the new malware on some registry, so companies are actively downloading and inspecting literally every package. Back in the day (maybe 6-7 years ago?) you could detect this by uploading a new npm package that hit back some endpoint in your control, and it was almost guaranteed that this endpoint got a request within a minute of publishing a new package or update to existing one with users. Nowadays I think none of the scanners actually run the code, mostly static-analysis, and I dunno how often the npm download counter updates per day, probably harder to see in real-time.
- teeray 5mo ago
  > Except there is lots to gain from being the first to write about the new malware on some registry Show me the company writing to their customers “we intentionally decided to ship code with potentially novel vulnerabilities. One of those vulnerabilities caused disclosure of your data, but cheer up! We have this cool security blog post about it now.” Meanwhile their competitors freeride and their customers’ data is safe.
  - weaksauce 5mo ago
    security researchers not the ones shipping the faulty code.
    - teeray 5mo ago
      We’re not talking about security researchers here: > there is lots to gain from being the first to write about the new malware on some registry, so *companies* are actively downloading and inspecting literally every package. (Emphasis mine)

raesene9 5mo ago

not really, there are a number of security companies doing analysis of any new packages looking for supply chain attacks, so if you wait a couple of days, till their analysis is complete, you're reducing the risk of hitting a compromised package.

nicoburns 4mo ago

Yep! We ultimately need better tooling for crowd-sourced manual auditing, not just a delay.