7/14/2026 at 10:36:38 PM
If everyone starts applying cooldowns, won't it postpone the problem? So now there is a considerable amount of users who are affected and someone from the affected group discovers the infection and reports it.But if everyone will be delaying updates, won't be there less chances to catch it in time? I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require.
by zihotki
7/14/2026 at 10:50:03 PM
>If everyone starts applying cooldowns, won't it postpone the problem?There are still research firms who are actively and aggressively scanning new packages once they are pushed. For example socket.dev pulls new packages across ecosystems and performs automated analysis and runs it in a sandbox. We don't have to have them go boom in someone's production repos to find out there is a problem.
by stusmall
7/15/2026 at 12:42:08 AM
And if every malware developer worth their salt now introduces code to "wait out" that period of time, we're back to square one.This assumes that they employ clandestine enough techniques that you have to actually install, wait and observe the behavior for longer than the cooldown period in order to detect this, because the code is "obfuscated" enough to evade static analysis of the code. It's anti-virus / anti-anti-virus 101 all over so to speak.
The good thing I suppose is that it raises the bar. Your regular "virus generator" script kid (sorry: supply chain attack generator script kid) can no longer pull this off.
by tharkun__
7/15/2026 at 12:53:35 AM
Most automated analysis isn't dependent on just behavior, but rather suspicious things in the code itself. You have a popular open source package with files that exist on pypi but not github then that's a big flag, or if a similar package suddenly has some base64encoded garbage that runs through an obfuscated exec call. In other words the simple fact that the project has obfuscated code is enough to flag for further attention.That said if the only issue is time, researchers will just run their automated analysis through machines with dates in the future alongside their normal tests.
by tedivm
7/15/2026 at 8:38:54 AM
A package I maintain once ended up in exactly this state because of a sync script.by kunxue
7/15/2026 at 1:10:50 AM
Cat and mouse like the sibling says ;) Like if you start changing system time, I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this. Of course I'll run the code that does this through "my obfuscator".The thing with cat and mouse based on time is that this now became a default. I rather liked my odds when malware authors assumed that the defaults were that dependabot updates right away. If the general consensus online seems to be 7 days, then I'll set my dependabot to wait 10 days, so on average I'll catch even things people report over a weekend. Now that the default is a longer time period, I have to change my time period to be even longer, which actually increases my risk in another way: I'll stay vulnerable to _actual_ vulnerabilities vs. supply chain attacks for longer.
by tharkun__
7/15/2026 at 8:14:04 AM
A cat and mouse game at least raises the bar for the exploit. The status quo requires no attempt at obfuscation at all. It also makes it harder for such an exploit to turn into a worm, since developers have time to notice their credentials have been stolen and pull any malicious packages pushed using them. (and such worms hitting popular packages have so far been how most people have been exposed to this risk).by rcxdude
7/15/2026 at 8:09:30 AM
> I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this.This makes no sense, the system clock would be set before the suspect package is even pulled down. There isn't a "jump" just a reboot and system start at a "totally real" point in time.
And the premise is that this package can evade detection of its suspect code by using an ever-increasing amount of odd code? Yeah, that's a hard strategy.
by SideburnsOfDoom
7/15/2026 at 4:22:31 AM
ok, but your package still contains obfuscated code that we can readby mplewis
7/15/2026 at 12:49:37 AM
Fundamentally, this is a cat-and-mouse game. But I suspect that "time bomb" techniques aren't economically viable for attackers, at least not with current patterns: current attackers demonstrate "smash and grab" tendencies because they know their access is limited anyways. Attempting to wait out a cooldown exposes them to additional detection risk.Of course, maybe the attacker profile changes over time. But that's the nature of the game.
by woodruffw
7/15/2026 at 5:49:40 AM
You can simulate accelerated time in the sandbox used to evaluate the runtime behavior of the package being analyzed.by tcoff91
7/15/2026 at 4:40:49 AM
This would increase the malware surface area and make it much easier for automated security scanners to detect. So win-win for everyone.by mgrandl
7/15/2026 at 8:07:52 AM
> And if every malware developer worth their salt now introduces code to "wait out" that period of time, we're back to square one.Of course this is an arms race, but the time setting inside the sandbox doesn't need to be the same as outside.
by SideburnsOfDoom
7/15/2026 at 6:06:31 AM
If it is about a few highly specialized firms finding the vulns we should let them do it before publication and we do not need cooldowns.If it is not about that and we still subscribe to Linus's law then cooldowns will just postpone the problem.
by weinzierl
7/15/2026 at 6:13:46 AM
Publishing publicly then applying cooldowns in projects is much easier tgan establishing a new standard for pre-release security testing versions that works across ecosystems and gains zooling support.by StrauXX
7/15/2026 at 6:29:52 AM
Exactly this. The firms can follow the standard practices of the industry without needing to injection further process into the projects.by yuppiepuppie
7/15/2026 at 7:08:20 AM
Releasing secure software is the right thing to do. We only release insecure software because we need the eyeballs to make it secure.If we believe the point made above that the many eyeballs are not that important then releasing before we have done everything to make the software as secure as possible is irresponsible.
by weinzierl
7/15/2026 at 7:20:34 AM
"We only release insecure software because we need the eyeballs to make it secure." No one is doing this on purpose, they believe the software to be secure when they release it... You shouldn't gate the release of a package until every single offsec research shop in the world has had a chance to look at itby palky
7/15/2026 at 8:18:27 AM
The cooldowns effectively make the initial push into the package repository into a pre-publishing step. It's pretty much isomorphic with what you're suggesting.by rcxdude
7/15/2026 at 12:07:46 AM
Also as an upstream, if your "coworker" releases a strange package without discussing the changes with the broader maintenance group, you might notice after 3-48 hours, but probably not within the hour unless you happened to be online.by NewJazz
7/14/2026 at 11:01:07 PM
> But if everyone will be delaying updates, won't be there less chances to catch it in time?No: the security assumption behind cooldowns rests on security scanning parties, not on innocent users being victimized. Three days is a short cooldown, but it should be a good enough lead for scanning parties.
> I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require.
It’s not that much data, particularly for parties that are directly financially incentivized to be the first to report malware.
by woodruffw
7/15/2026 at 1:48:11 AM
Do you have an example of those things you're alleging?All package malware related news I see are related to users being affected by it (then security firms do their analysis whatever) ...
by moralestapia
7/15/2026 at 7:41:50 AM
If you google “supply chain security company” you will find various companies of various reputations vying for attention in this space.by woodruffw
7/15/2026 at 11:21:35 AM
Didn't find any. Found a lot scammers, though.Just post one link of a "supply chain" problem that was prevented by any of these companies before it went into the wild and affected users.
Simple.
by moralestapia
7/15/2026 at 11:35:12 AM
I generally try not to name the companies directly, because I don’t want to give them free advertising. But you can look up e.g. the recent Shai Hulud campaign.> Just post one link of a "supply chain" problem that was prevented by any of these companies before it went into the wild and affected users.
This is not the claim being made, since cooldowns are not widely adopted at the moment.
by woodruffw
7/15/2026 at 12:03:48 PM
I see. So, it has never happened before.by moralestapia
7/15/2026 at 12:42:48 PM
Well, yeah. There’s no package police that’ll stop you from installing malware. The argument has never revolved around that; the argument is solely that cooldowns are effective if you use them, and timely detection by third parties is strong evidence of that.by woodruffw
7/15/2026 at 12:57:34 PM
>and timely detection by third parties is strong evidence of thatDo you have an example of those things you're alleging?
by moralestapia
7/15/2026 at 3:47:04 PM
I gave Shai Hulud as an example above. If you want precise timeline examples that demonstrate the efficacy of cooldowns, here’s some examples I collected last year[1].(See the “Window of opportunity” column in the table.)
[1]: https://blog.yossarian.net/2025/11/21/We-should-all-be-using...
by woodruffw
7/15/2026 at 2:15:09 AM
Analysis and detection are not the same.by klausa
7/14/2026 at 10:46:07 PM
Only a few of the recent supply chain attacks were discovered by users noticing weird behavior.The majority were noticed by maintainers or third party groups noticing things like releases not tied to a source tag, many rapid releases, etc.
Cooldowns won’t stop everything, but it makes a malicious release significantly more likely to be noticed
by MeetingsBrowser
7/15/2026 at 1:09:20 AM
When you're running from a bear on a hiking trip you just have to be faster than your friend. So just set your cooldown slightly longer than everyone else's cooldowns. The cooldown will give security researchers some time to scan the packages so it's still good.by brikym
7/15/2026 at 6:40:59 AM
If you currently use a 7 day cooldown on a 0 day default. You can just use a 10 day cooldown on a 3 day default. But don't tell anyone...by kleyd
7/14/2026 at 10:39:12 PM
The goal is to give time for automated scanners ran by cybersecurity companies to flag malware before it gets installed on real users.by roblabla
7/15/2026 at 2:02:26 AM
I agree, it’s just the wrong approach. As a user, there’s no way to know if a package has been audited during the cooldown by some generous cybersecurity firm before you pull it in, it’s just wishful thinking. Minimizing your dependencies is a more effective strategy against supply chain attacks.by cmckn
7/15/2026 at 8:24:16 AM
The way to guarantee that is to pay one of those cybersecurity firms, that's basically their business.And the most effective strategy is to audit and review your dependencies and any updates to them. That probably constrains how many you can have, but just minimizing them is reducing the size of the target, not protecting it per se.
by rcxdude
7/15/2026 at 4:06:46 AM
Hence by writing your own code with its own set of vulns to be detected.by pixl97
7/15/2026 at 12:23:12 PM
Unless you are a big enough target, there is still potential value to this. Is your business worth enough for someone to spend a lot of money hunting bespoke vulnerabilities? If not, your main risk is being swept in a vulnerability affecting a common dependency, and eliminating the common dependencies removes that risk.by swiftcoder
7/15/2026 at 5:27:38 AM
Well, there’s always woodworking.by appplication
7/14/2026 at 11:12:56 PM
Most of the malicious ones just curl something in a postinstall script, scanners already catch that. The sneaky ones don't look malicious until they run, and three days may not help.by tabwidth
7/14/2026 at 11:25:34 PM
There are plenty of ways to notice a malicious release without observing it running.Build provenance, maintainer alerts on new releases, tying releases to specific git tags, etc all help.
by MeetingsBrowser
7/14/2026 at 11:22:21 PM
Every single one now will be more sneaky, and we’ll be operating on a 3-day cooldown for no reason.by drdexebtjl
7/15/2026 at 4:11:16 AM
How exactly does that work?I don't think that HNers understand the recent supply chain attacks very well at all. I also don't think they realize the tests the SCA/package providers do to all the major packages.
Almost all these attacks try to reach out to external sites to steal your data. That is exceptionally hard to hide in any meaningful way.
by pixl97
7/15/2026 at 4:15:25 AM
def steal_your_data():
if datetime.now() < three_days_after_attack:
return
reach_out_to_external_sites()by drdexebtjl
7/15/2026 at 4:23:39 AM
OK, so it looks like you've still added suspicious code to your package.by mplewis
7/15/2026 at 4:47:08 AM
You can make it much less suspicious. In particular, if you can compromise the package publishing process, and not just pushes to main, you can add your malicious code to binary artifacts, not to the source code.by drdexebtjl
7/15/2026 at 2:44:35 PM
That’s a bold claim to make about HNers. Au contraire, security companies have absolutely missed supply chain attacks.Example:
https://snyk.io/blog/node-gyp-supply-chain-compromise-self-p...
Before that we had event-stream, then we had XZ compromise.
It’s not exceptionally hard to delay reaching out to external sites until after a cooldown period.
by yearolinuxdsktp
7/14/2026 at 11:33:39 PM
You really think it has zero benefit whatsoever? Nothing malicious will be caught?by brookst
7/15/2026 at 3:33:46 AM
Pretty much. These tools are effective now only because the malware doesn’t have to avoid being detected at all to be successful.by drdexebtjl
7/14/2026 at 10:51:31 PM
Easy, then you just delay your project’s dependency updates just a little more than everyone elseby ronbenton
7/15/2026 at 6:54:44 AM
The cooldowns should probably be randomised.by eru
7/14/2026 at 10:38:17 PM
I think the idea is that it gives a bit of time for the companies which run automated scans of new versions to run through and detect any issues with new versions before users install them en-mass.by oakesm9
7/15/2026 at 12:17:51 AM
There was a story about two men and a tigerThe men see the tiger, one scrambles to run and the other starts putting on their shoes
"Why are you putting on shoes? You'll never outrun the tiger"
"I don't need to, I just need to outrun you"
by TZubiri