6 ms·

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-releas

• dirtbag__dad 6mo ago
  I guess this is the case for new installs, but for existing dependencies can’t you simply pin them to a patch release, and point at the sha?
• tadfisher 6mo ago
  Cooldowns are passing the buck. These are all caught with security scanning tools, and AI is probably going to be better at this than people going forward, so just turn on the cooldowns server-side. Package updates go into a "quarantine" queue until they are scanned. Only after scanning do they go live.
  • eranation 6mo ago
    I agree, even without project glasswing (that Microsoft is part of) even with cheaper models, and Microsoft's compute (Azure, OpenAI collaboration), it makes no sense that private companies needs to scan new package releases and find malware before npm does. I'm sure they have some reason for it (people rely on packages to be immediately available on npm, and the real use case of patching a zero day CVE quickly), but until this is fixed fundamentally, I'd say the default should be a cooldown (either serverside or not) and you'll need to opt in to get the current behavior. This might takes years of deprecation though, I'm sure it was turned on now, a lot of things would break. (e.g. every CVE public disclosure will also have to wait that additional cooldown... and if Anthropic are not lying, we are bound for a tsunami of patched CVEs soon...)
    • tadfisher 6mo ago
      There are so many ways to self-host package repos that "immediate availability" to the wider npm-using public is a non-issue. Exceptions to quarantine rules just invites attackers to mark malicious updates as security patches. If every kind of breakage, including security bugs, results in a 2-3 hour wait to ship the fix, maybe that would teach folks to be more careful with their release process. Public software releases really should not be a thing to automate away; there needs to be a human pushing the button, ideally attested with a hardware security key.
  • deleted 6mo ago
    [deleted]
  • woodruffw 6mo ago
    "Just" is doing a lot of work; most ecosystems are not set up or equipped to do this kind of server-side queuing in 2026. That's not to say that we shouldn't do this, but nobody has committed the value (in monetary and engineering terms) to realizing it. Perhaps someone should. By contrast, a client-side cooldown doesn't require very much ecosystem or index coordination.
    • tadfisher 6mo ago
• prdonahue 6mo ago
  > Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Most of these attacks don't make it into the upstream source, so solutions[1] that build from source get you ~98% of the way there. If you can't get a from-source build vs. pulling directly from the registries, can reduce risk somewhat with a cooldown period. For the long tail of stuff that makes it into GitHub, you need to do some combination of heuristics on the commits/maintainers and AI-driven analysis of the code change itself. Typically run that and then flag for human review. [1] Here's the only one I know that builds everything from source: https://www.chainguard.dev/libraries https://www.chainguard.dev/libraries (Disclaimer: I work there.)
  • eranation 6mo ago
    Build from source is a great idea, I assume you provide SLSA/sigstore like provenance as well?
    • arianvanp 6mo ago
      The chainguard folks built sigstore :)
      • eranation 6mo ago
        Yep yep, hence the ask, expected for containers, wondering if also for build from source.
  • schnatterer 6mo ago
    Can you give some examples for the claim that most of the attacks don't make it upstream? My gut tells me that, yes, mostly binaries have been compromised. But I am sure you have some real-world examples proving the point.
• fauigerzigerk 6mo ago
  I use a separate dev user account (on macOS) for package installations, VSCode extensions, coding agents and various other developer activities. I know it's far from watertight (and it's useless if you're working with bitwarden itself), but I hope it blocks the low hanging fruit sort of attacks.
  • bananadonkey 6mo ago
    Check your home folder permissions on macos, last time I checked mine were world readable (until I changed them). I was very surprised by it, and only noticed when adding an new user account for my wife.
    • fauigerzigerk 6mo ago
      I noticed that too (and changed it). The home folder appears to be world readable because otherwise sharing via the Public folder wouldn't work. The folders where the actual data lives are not world readable. I think this is a bad idea, because it means the permissions of any new folders have to be closely guarded, which is easy to forget.
• 4ndrewl 6mo ago
  The problem with cooldowns is that the more people use them, the less effective they become.
  • bdangubic 6mo ago
    care to elaborate?
    • tomesco 6mo ago
      https://news.ycombinator.com/item?id=47773812 https://news.ycombinator.com/item?id=47773812
      • ievans 6mo ago
        Top comment has a great explicit refutation: > This plan works by letting software supply chain companies find security issues in new releases. Many security companies have automated scanners for popular and less popular libraries, with manual triggers for those libraries which are not in the top N.
    • deleted 6mo ago
      [deleted]
  • eranation 6mo ago
    Well, luckily, those who find the malicious activity are usually companies who do this proactively (for the good of the community, and understandably also for marketing). There are several who seem to be trying to be the first to announce, and usually succeed. IMHO it should be Microsoft (as owners of GitHub, owners of npm) who should take the helm and spend the tokens to scan each new package for malicious code. It gets easier and easier to detect as models improve (also gets easier and easier to create, and try to avoid detection on the other hand)
  • somehnguy 6mo ago
    That was my first instinct as well but I'm not sure how true it really is. Many companies exist now whose main product is supply chain vetting and scanning (this article is from one such company). They are usually the ones writing up and sharing articles like this - so the community would more than likely hear about it even if nobody was actually using the package yet.
• n_e 6mo ago
  > Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? With pnpm, you can also use trustPolicy: no-downgrade, which prevents installing packages whose trust level has decreased since older releases (e.g. if a release was published with the npm cli after a previous release was published with the github OIDC flow). Another one is to not run post-install scripts (which is the default with pnpm and configurable with npm). These would catch most of the compromised packages, as most of them are published outside of the normal release workflow with stolen credentials, and are run from post-install scripts
  • eranation 6mo ago
    Yep! depsguard sets trustPolicy: "no-downgrade" where applicable.
• doctorpangloss 6mo ago
  Haha what if there's an urgent security fix in an updated package?
  • edf13 6mo ago
    Manually review the package and override the setting
    • doctorpangloss 6mo ago
      The flaw of the cooldown solution speaks for itself.
      • bonzini 6mo ago
        Still it's something like a second factor (or even, literally, overriding might require 2FA).
        • deleted 6mo ago
          [deleted]
  • eranation 6mo ago
    Yep, that's the main argument against cooldowns, but there are ways to override them. I'll update the docs soon.
• hombre_fatal 6mo ago
  Maybe using a slower, stable package manager that still gets security/bug fixes, like nix.
• pxc 6mo ago
  Install tools using a package manager that performs builds as an unprivileged user account other than your own, sandboxes builds in a way that restricts network and filesystem access, and doesn't run let packages run arbitrary pre/post-install hooks by default. Avoid software that tries to manage its own native (external, outside the language ecosystem) dependencies or otherwise needs pre/post-install hooks to build. If you do packaging work, try to build packages from source code fetched directly from source control rather than relying on release tarballs or other published release artifacts. These attacks are often more effective at hiding in release tarballs, NPM releases, Docker images, etc., than they are at hiding in Git history. Learn how your tools actually build. Build your own containers. Learn how your tools actually run. Write your own CI templates. My team at work doesn't have super extreme or perfect security practices, but we try to be reasonably responsible. Just doing the things I outlined above has spared me from multiple supply chain attacks against tools that I use in the past few weeks. Platform, DevEx, and AppSec teams are all positioned well to help with stuff like this so that it doesn't all fall on individual developers. They can: - write and distribute CI templates - run caches, proxies, and artifact repositories which might create room to - pull through packages on a delay - run automated scans on updates and flag packages for risks? - maybe block other package sources to help prevent devs from shooting themselves in the foot with misconfiguration - set up shared infrastructure for CI runners that - use such caches/repos/proxies by default - sandbox the network for build$ - help replace or containerize or sandbox builds that currently only run on bare metal on some aging Jenkins box on bare metal - provide docs - on build sandboxing tools/standards/guidelines - on build guidelines surrounding build tools and their behaviours (e.g., npm ci vs npm install, package version locking and pinning standards) - promote packaging tools for development environments and artifact builds, e.g., - promote deterministic tools like Nix - run build servers that push to internal artifact caches to address trust assumptions in community software distributions - figure out when/whether/how to delegate to vendors who do these things I think there's a lot of things to do here. The hardest parts are probably organizational and social; coordination is hard and network effects are strong. But I also think that there are some basics that help a lot. And developers who serve other developers, whether they are formally security professionals or not, are generally well-positioned to make it easier to do the right thing than the sloppy thing over time.
• madduci 6mo ago
  Renovate can do it as well
  • eranation 6mo ago
    Yep, depsguard has support for renovate and dependabot cooldown settings too.
• PunchyHamster 6mo ago
  Don't write anything backend or cli tool in NPM would be good start
  • MetaWhirledPeas 6mo ago
    Other package managers are magically immune?
    • c2h5oh 6mo ago
      They are not, but npm is uniquely bad in that regard. Refusal to implement security features that would have made attacks like this harder really doesn't help https://github.com/node-forward/discussions/issues/29 https://github.com/node-forward/discussions/issues/29
      • nirvdrum 6mo ago
        The lack of a comprehensive standard library for JavaScript also results in projects pulling many more third party dependencies than you would with most other modern environments. It’s just a bigger attack surface. And if you can compromise a module used for basic functionality that you’d get out of the box elsewhere, the blast radius will be enormous.
        • pico303 6mo ago
          Not to mention a culture of basically one-line packages ad infinitum. I downloaded a JS tool the other day to generate test reports and it had around 300 dependencies. Needless to say I’m running all my JS tools in a Docker container these days.
        • wombatpm 6mo ago
          So why hasn’t someone created a batteries include JS library? I don’t program in JS on the backend so I don’t know how feasible something like that is.
          • 6mo ago
• fragmede 6mo ago
  But how do you know which one is good? If foo package sends out an announcement that v1.4.3 was hacked, upgrade now to v1.4.4 and you're on v1.4.3, waiting a week seems like a bad idea. But if the hackers are the one sending the announcement, then you'd really want to wait the week!
  • dwattttt 6mo ago
    An announcement isn't a quiet action. One would hope that the real maintainers would notice & take action.
  • throw1230 6mo ago
    malicious versions are recalled and removed when caught - so you don't need to update to the next version
• abustamam 6mo ago
  I like the idea of a cool down. But my next question is would this have been caught if no one updated? I know in practice not everyone would be on a cool down. But presumably this comprise was only found out because a lot of people did update.
  • slekker 6mo ago
    It's a trade off for sure, maybe if companies could have "honeypot" environments where they update everything and deploy their code, and try to monitor for sneaky things.
    • teiferer 6mo ago
      It's easy for malicious code to detect sandboxing. Also, check out the VW Diesel scandal.
  • pmichaud 6mo ago
    If I were in charge of a package manager I would be seriously looking into automated and semi automated exploit detection so that people didn't have to yolo new packages to find out if they are bad. The checking would itself become an attack vector, but you could mitigate that too. I'm just saying _something_ is possible.
  • kjok 6mo ago
    Cooldown sounds like a good idea ONLY IF these so called security companies can catch these malicious dependencies during the cooldown period. Are they doing this bit or individual researchers find a malware and these companies make headlines?
    • subarctic 6mo ago
      Does it matter? The individual researchers could look at brand-new published packages just the same
      • hunter2_ 6mo ago
• fdsajfkldsfklds 6mo ago
  Never, ever type "npm -i". This advice has served me well for many years.
• personalcompute 6mo ago
  Regarding doing more than just a minimum release age: The tool I personally use is Aikido "safe-chain". It sets minimum release age, but also provides a wrapper for npm/uv/etc where upon trying to install anything it first checks each dependency for known or suspected vulnerabilities against an online commercial vulnerability database.
• neya 6mo ago
  Stop using Javascript. Or Typescript or whatever excuses they have for the fundamentally flawed language that should have been retired eons ago instead of trying to get it fixed. Javascript, its ecosystem has always been a pack of cards. Time and again it has been proven again. I think this is like the 3rd big attack in the last 30 days alone.
  • bdangubic 6mo ago
    it is being attacked precisely because it is ubiquitous. no one is going to attack haskell, erlang or whatever no one uses.
  • d0liver 6mo ago
    This isn't a JS specific issue.
  • eranation 6mo ago
    Yes but it has nothing to do with the language, and everything to do with the ecosystem (npm tried to make thing such as mandatory MFA etc, npmjs is so big maintainers pushed back) TypeScript on its own is a great language, with a very interesting type system. Most other type systems can’t run doom. https://simonwillison.net/2025/Feb/27/typescript-types-can-run-doom/ https://simonwillison.net/2025/Feb/27/typescript-types-can-r...
    • Ferret7446 6mo ago
      > Most other type systems can’t run doom. That doesn't sound like a compliment.
• nl 6mo ago
  > ~/.config/uv/uv.toml > exclude-newer = "7 days" Note the if you get failed to parse year in date "7 days": failed to parse "7 da" as year (a four digit integer): invalid digit, expected 0-9 but got then comment out the exclude and run uv self update
• nikcub 6mo ago
  compartmentalize. I do development and anything finance / crypto related / sensitive on separate machines. If you're brave you can run whonix. The issue is developers who have publish access to popular packages - they really should be publishing and signing on a separate machine / environment. Same with not doing any personal work on corporate machines (and having strict corp policy - vercel were weak here).
• NetMageSCW 6mo ago
  Isn’t the problem with a minimum age release that the opposite would also occur - a high priority fix of zero day under exploit wouldn’t be fixed and you could be compromised in the window?
  • eranation 6mo ago
    It is! It’s a tough problem to balance. The good news is that you can always override for specific cases. Linking to my other reply here: https://news.ycombinator.com/item?id=47880149 https://news.ycombinator.com/item?id=47880149
• duskdozer 6mo ago
  Update dependencies when you need something in them, not just because there's a new version available.
  • nedt 6mo ago
    But then at the same time you should always update because it might fix a security vulnerability. Otherwise you end up running nodejs 10 because you don't need the new stuff.
    • duskdozer 6mo ago
      Or it might introduce one. But sure, a security fix for a known vulnerability could count as something you need in a new version. Ideally they would be backported and separated from feature updates. The constant dependency churn and single-channel update stream is kind of why a lot of vulnerabilities become problems in the first place.
• kippinsula 6mo ago
  we've been running Renovate with `minimumReleaseAge: '7 days'` across all our repos for a while now, which does basically the same thing across npm, PyPI, and Cargo in one config. the tradeoff is you're always 7 days behind on patches, but for anything touching CI or secrets tooling that feels like a fair deal. the nasty part of this class of attack is the timing window is usually sub-24h before it's pulled, so even 3 days would have caught this one.
• pdntspa 6mo ago
  This seems pretty sensible. Do we really need updates the day they drop?
• johntash 6mo ago
  > https://depsguard.com https://depsguard.com if anyone is interested. I really appreciate that you didn't include a "curl | bash" command to paste for installing, but at the same time it's what I was expecting when I clicked. I'm pretty sure I saw a comment on HN where the user wrapped all of their npm/pip/etc commands with bubblewrap. I've been thinking of doing something similar and basically just seeing how many of my daily commands I can sandbox. My hunch is that _most_ of them don't need to operate outside the current directory and don't need internet access.
  • eranation 6mo ago
    Yeah, I really wanted to avoid anything "| bash"... appreciate you noticed! (although downloading any binary is also risky, I think just making this a standalone python script would be a better idea for the next version)
• r-bedekar 6mo ago
  [dead]
• hawk_aa 6mo ago
  [dead]