12 ms·

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my

by kelnos 1y ago

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embedded malware. One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago. As a maintainer, I could decide that a package that's been out in the wild for at least 6 weeks is less likely to have unnoticed malware in it than one that was released just yesterday. Obviously this is not a perfect fix, as there's no guarantee that the delay time I specify is enough for any particular package. And I'd want the tool to present me with options sometimes: e.g. if my current version of a dep has a vulnerability, and the fix for it came out a few days ago, I might choose to update to it (better eliminate the known vulnerability than refuse to update for fear of an unknown one) rather than wait until it's older than my threshold.

CraftThatBlock 1y ago
pnpm just added this: https://pnpm.io/blog/releases/10.16 https://pnpm.io/blog/releases/10.16
- jauntywundrkind 1y ago
  minimumReleaseAge is pretty good! Nice!! I do wish there were some lists of compromised versions, that package managers could disallow from.
- thepill 1y ago
  bun is also working on it: https://github.com/oven-sh/bun/issues/22679 https://github.com/oven-sh/bun/issues/22679
- philipwhiuk 1y ago
  Aren't they found quickly because people upgrade quickly?
- drdaeman 1y ago
  This sounds nice in theory, but does it really solve the issue? I think that if no one's installing that package then no one is noticing the malware and no one is reporting that package either. It merely slightly improves the chances that author would notice a version they didn't release, but this doesn't work if author is not particularly actively working the compromised project.
  - brw 1y ago
    These days compromised packages are often detected automatically by software that scans all packages uploaded to npm like https://socket.dev https://socket.dev or https://snyk.io https://snyk.io. So I imagine it's still useful to have those services scan these packages first, before they go out to the masses. Measures like this also aren't meant to be "final solutions" either, but stop-gaps. Slowing the spread can still be helpful when a large scale attack like this does occur. But I'm also not entirely sure how much that weighs against potentially slowing the discovery as well. Ultimately this is still a repository problem and not a package manager one. These are merely band-aids. The responsibility lies with npm (the repository) to implement proper solutions here. > The responsibility lies with
  - kelnos 1y ago
    No, it doesn't solve the issue, but it probably helps. And I agree that if everyone did this, it would slow down finding issues in new releases. Not really sure what to say to that... aside from the selfish idea that if I do it, but most other people don't, it won't affect me.
  - dec0dedab0de 1y ago
    a long enough delay would solve the issue for account takeovers, and bold attacks like this. It would not solve for a bad actor gaining trust over years, then contributing seemingly innocent code that contains an exploitable bug with enough plausible deniability to remain on the team after it is patched.
- brw 1y ago
  there's apparently an npm RFC from 2022 proposing a similar (but potentially slightly better?) solution https://github.com/npm/rfcs/issues/646 https://github.com/npm/rfcs/issues/646
- smrtinsert 1y ago
  this btw would also solve social media. if only accounts required a month waiting period before they could speak.
gameman144 1y ago
> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually pretty sensible.
- Ajedi32 1y ago
  If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.
  - curtisf 1y ago
    This is true to the extent that you actually _use_ all of the features of a dependency. You only need to rewrite what you use, which for many (probably most) libraries will be 1% or less of it
    - zahlman 1y ago
      Indeed. About 26% of the disk space for a freshly-installed copy of pip 25.2 for Python 3.13 comes from https://pypi.org/project/rich/ https://pypi.org/project/rich/ (and its otherwise-unneeded dependency https://pypi.org/project/Pygments/ https://pypi.org/project/Pygments/), "a Python library for rich text and beautiful formatting in the terminal", hardly any of the features of which are relevant to pip. This is in spite of an apparent manual tree-shaking effort (mostly on Pygments) — a separate installed copy of rich+Pygments is larger than pip. But even with that attempt, for example, there are hundreds of kilobytes taken up for a single giant mapping of "friendly" string names to literally thousands of emoji. Another 20% or more is https://pypi.org/project/requests/ https://pypi.org/project/requests/ and its dependencies — this is an extremely popular project despite that the standard library already provides the ability to make HTTPS connections (people just hate the API that much). One of requests' dependencies is certifi, which is basically just a .pem file in Python package form. The vendored requests has not seen any tree-shaking as far as I can tell. This sort of thing is a big part of why I'll be able to make PAPER much smaller.
eschneider 1y ago
If you pull something into your project, you're responsible for it working. Full stop. There are a lot of ways to manage/control dependencies. Pick something that works best for you, but be aware, due diligence, like maintenance is ultimately your responsibility.
- IshKebab 1y ago
  That's very naive. We can do better than this.
  - hermannj314 1y ago
    Almost all software has a no warranty clause. I am not a lawyer but in pretty plain English every piece of software I have ever used has said exactly that I can fuck off if I expect it to work or do anything. To clarify - I dont think it is naive to assume the software is as-is with all responsibilities on the user since that is exactly what lawyers have made all software companies say that for over 50 years.
    - gmueckl 1y ago
      Product liability is coming for software. Warranty disclaimers in licenses will be rendered ineffective by the end of 2026 at the latest.
      - tcoff91 1y ago
        Source? An open source library is not necessarily a ‘product’ at all.
        LtWorf 1y ago
        No source because it's not real. There's talk about final products and making the companies selling them responsible. But open source developers are not responsible.
      - respondo2134 1y ago
skybrian 1y ago
When using Go, you don't get updated indirect dependencies until you update a direct dependency. It seems like a good system, though it depends on your direct dependencies not updating too quickly.
- silverwind 1y ago
  The auto-updating behaviour dependencies because of the `^` version prefix is the root problem. It's best to never use `^` and always specify exact version, but many maintainers apparently can't be bothered with updating their dependencies themselves so it became the default.
Melatonic 1y ago
Lot of software has update policies like this and then also people will run a separate test environment updating to latest
spion 1y ago
pnpm just added minimum age for dependencies https://pnpm.io/blog/releases/10.16#new-setting-for-delayed-dependency-updates https://pnpm.io/blog/releases/10.16#new-setting-for-delayed-...
- kelnos 1y ago
  Oh brilliant. I've been meaning to start migrating my use to pnpm; this is the push I needed.
- ojosilva 1y ago
  From your link: > In most cases, such attacks are discovered quickly and the malicious versions are removed from the registry within an hour. By delaying the infected package availability (by "aging" dependencies), we're only delaying the time, and reducing samples, until it's detected. Infections that lay dormant are even more dangerous than explosives ones. The only benefit would be if, during this freeze, repository maintainers were successfully pruning malware before it hits the fan, and the freeze would give scanners more time to finish their verification pipelines. That's not happening afaik, NPM is crazy fast going from `npm publish` to worldwide availability, scanning is insufficient by many standards.
  - jkrems 1y ago
    Afaict many of these recent supply chain attacks _have_ been detected by scanners. Which ones flew under the radar for an extended period of time? From what I can tell, even a few hours of delay for actually pulling dependencies post-publication to give security tools a chance to find it would have stopped all (?) recent attacks in their tracks.
- oefrha 1y ago
  Thank god, adopting this immediately. Next I’d like to see Go-style minimum version selection instead.
duped 1y ago
Personally, I go further than this and just never update dependencies unless the dependency has a bug that affects my usage of it. Vulnerabilities are included. It is insane to me how many developers update dependencies in a project regularly. You should almost never be updating dependencies, when you do it should be because it fixes a bug (including a security issue) that you have in your project, or a new feature that you need to use. The only time this philosophy has bitten me was in an older project where I had to convince a PM who built some node project on their machine that the vulnerability warnings were not actually issues that affected our project. Edit: because I don't want to reply to three things with the same comment - what are you using for dependencies where a) you require frequent updates and b) those updates are really hard? Like for example, I've avoided updating node dependencies that have "vulnerabilities" because I know the vuln doesn't affect me. Rarely do I need to update to support new features because the dependency I pick has the features I need when I choose to use it (and if it only supports partial usage, you write it yourself!). If I see that a dependency frequently has bugs or breakages across updates then I stop using it, or freeze my usage of it.
- erulabs 1y ago
  counterpoint, if the runtime itself (nodejs) has a critical issue, you haven't updated for years, you're on an end-of-life version, and you cannot upgrade because you have dependencies that do not support the new version of the runtime, you're in for a painful day. The argument for updating often is that when you -are- exposed to a vulnerability that you need a fix for, it's a much smaller project to revert or patch that single issue. Otherwise, I agree with the sentiment that too many people try to update the world too often. Keeping up with runtime updates as often as possible (node.js is more trusted than any given NPM module) and updating only when dependencies are no longer compatible is a better middle ground.
  - RussianCow 1y ago
    The same logic you used for runtimes also applies to libraries. Vulnerabilities are found in popular JS libraries all the time. The surface area is, of course, smaller than that of a runtime like Node.js, but there is still lots of potential for security issues with out-of-date libraries. There really is no good solution other than to reduce the surface area for vulnerabilities by reducing the total amount of code you depend on (including third-party code). In practice, this means using as few dependencies as possible. If you only use one or two functions from lodash or some other helper library, you're probably better off writing or pulling in those functions directly instead.
TZubiri 1y ago
Install less dependencies, code more.
- vvpan 1y ago
  Copy-paste more.
  - baobabKoodaa 1y ago
    I guess this is a joke, but imo it shouldn't be.
    - TZubiri 1y ago
      I'm all for disregarding DRY and copypasting code you wrote. But I think for untrusted third party code, it's much better to copy the code by hand, that way you are really forced to audit it. There really isn't much of an advantage to copying an install.sh script compared to just downloading a running the .sh, whereas writing the actual .sh commands on the command line (and following any other URLs before executing them) is golden.
    - vvpan 1y ago
      Not entirely a joke actually. For example, I have worked at a large corp where dependencies were high discouraged. For example lodash was not used in the codebase I was working on and if you really needed something from lodash you were encouraged to copy-paste the function. This won't work for large libraries of course but the copy-paste-first mentality is not a bad one.
  - 1oooqooq 1y ago
    wonder how long for llms to spew the malware in those packages along the code when you request the same functionality.
- kelnos 1y ago
  Sure, and I do that whenever I can. But I'm not going to write my own react, or even my own react-hook-form. I'm not going to rewrite stripe-js. Looking through my 16 direct dependencies -- that pull in a total of 653 packages, jesus christ -- there's only one of them that I'd consider writing myself (js-cookie) in order to reduce my dependency count. The rest would be a maintenance burden that I shouldn't have to take on.
Waterluvian 1y ago
I update my deps once a year or when I specifically need to. That helps a bit. Though it upsets the security theatre peeps at work who just blindly think dependabot issues means I need to change dependencies.
- LtWorf 1y ago
  I never understood the "let's always pin everything to the latest version and let's update the pinned versions every day"… what is even the point of this exercise? Might as well not pin at all.
homebrewer 1y ago
Don't update your dependencies manually. Setup renovate to do it for you, with a delay of at least a couple of weeks, and enable vulnerability alerts so that it opens PRs for publicly known vulnerabilities without delay https://docs.renovatebot.com/configuration-options/#minimumreleaseage https://docs.renovatebot.com/configuration-options/#minimumr... https://docs.renovatebot.com/presets-default/#enablevulnerabilityalerts https://docs.renovatebot.com/presets-default/#enablevulnerab...
- collinmanderson 1y ago
  Why was this comment downvoted? Please explain why you disagree.
  - biggusdickus69 1y ago
    I didn’t downvote, but... Depending on a commercial service is out of the question for most open source projects.
    - isbvhodnvemrwvn 1y ago
      Renovate is not commercial, it's an own source dependabot, quite more copable at that.
      - wereHamster 1y ago
        AGPL is a no-go for many companies (even when it's just a tool that touches your code and not a dependency you link to).
        1oooqooq 1y ago
        good. that's the point. agpl is a no go for companies not intending to ever contribute anything back. good riddance.
johtso 1y ago
Maybe one approach would be to pin all dependencies, and not use any new version of a package until it reaches a certain age. That would hopefully be enough time for any issues to be discovered?
- rapfaria 1y ago
  People living on the latest packages with their dependabots never made any sense to me, ADR. They trusted their system too much
  - LtWorf 1y ago
    If you don't review the pinned versions, it makes no difference.
- pfych 1y ago
  Packages can still be updated, even if pinned. If a dependency of a dependency is not pinned - it can still be updated.
0xbadcafebee 1y ago
Stick to (pin) old stable versions, don't upgrade often. Pain in the butt to deal with eventual minimum-version-dependency limitations, but you don't get the brand new releases with bugs. Once a year, get all the newest versions and figure out all the weird backwards-incompatible bugs they've introduced. Do it over the holiday season when nobody's getting anything done anyway.
nostrademons 1y ago
npm shrinkwrap and then check in your node_modules folder. Don't have each developer (or worse, user) individually run npm install. It's common among grizzled software engineering veterans to say "Check in the source code to all of your dependencies, and treat it as if it were your own source code." When you do that, version upgrades are actual projects. There's a full audit trail of who did what. Every build is reproducible. You have full visibility into all code that goes into your binary, and you can run any security or code maintenance tools on all of it. You control when upgrades happen, so you don't have a critical dependency break your upcoming project.
collinmanderson 1y ago
> sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago. For Python's uv, you can do something like: > uv lock --exclude-newer $(date --iso -d "2 days ago")
- zygentoma 1y ago
  Awesome tip, thanks!
- parlortricks 1y ago
  oh that uv lock is neat, i am going to give that a go
deleted 1y ago
[deleted]
1over137 1y ago
>It's not feasible for me to audit every single one of my dependencies Perhaps I’m just ignorant of web development, but why not? We do so with our desktop software.
- galaxy_gas 1y ago
  Average .net core desktop complex app may have a dozen dependencies if it get to that point. Average npm todo list may have several thousand if not more
cmckn 1y ago
> instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago The problem with this approach is you need a certain number of guinea pigs on the bleeding edge or the outcome is the same (just delayed). There is no way for anyone involved to ensure that balance is maintained. Reducing your surface area is a much more effective strategy.
- biggusdickus69 1y ago
  Not necessarily, some supply chain compromises are detected within a day by the maintainers themselves, for example by their account being taken over. It would be good to mitigate those at least.
  - cmckn 1y ago
    In that specific scenario, sure; but I don't think that's a meaningful guardrail for a business.
hedora 1y ago
I recently started using npm for an application where there’s no decent alternative ecosystem. The signal desktop app is an electron app. Presumably it has the same problem. Does anyone know of any reasonable approaches to using npm securely? “Reduce your transitive dependencies” is not a reasonable suggestion. It’s similar to “rewrite all the Linux kernel modules you need from scratch” or “go write a web browser”.
- umpalumpaaa 1y ago
  Most big tech companies maintain their own NPM registry that only includes approved packages. If you need a new package available in that registry you have to request it. A security team will then review that package and its deps and add it to the list of approved packages… I would love to have something like that "in the open"…
  - skydhash 1y ago
    A debian version of NPM? I've seen a lot of hates on Reddit and other places about Debian because the team focuses on stability. When you look at the project, it's almost always based on Rust or Python.
- wolvesechoes 1y ago
  > “Reduce your transitive dependencies” is not a reasonable suggestion. It’s similar to “rewrite all the Linux kernel modules you need from scratch” or “go write a web browser”. Oh please, do not compare writing bunch of utilities for you "app" with writing a web browser.
benoau 1y ago
I like to pin specific versions in my package.json so dependencies don't change without manual steps, and use "npm ci" to install specifically the versions in package-lock.json. My CI runs "npm audit" which will raise the alarms if a vulnerability emerges in those packages. With everything essentially frozen there either is malware within it, or there is not going to be, and the age of the packages softly implies there is not.
abrookewood 1y ago
The article explicitly mentions a way to do this: Use NPM Package Cooldown Check The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks are detected within the first 24 hours of a malicious package release, and the projects that get compromised are often the ones that rushed to adopt the version immediately. By introducing a short waiting period before allowing new dependencies, teams can reduce their exposure to fresh attacks while still keeping their dependencies up to date.
- loginatnine 1y ago
  That's a feature of stepsecurity though, it's not built-in.
- autoexec 1y ago
  This is basically what I recommended people do with windows updates back when MS gave people a choice about when/if to install them, with shorter windows for critical updates and much longer ones for low priority updates or ones that only affected things they weren't using.
- DrewADesign 1y ago
  And hope there isn’t some recently patched zero-day RCE exploit at the same time.
- throwawayqqq11 1y ago
  This attack was only targeting user environments. Having secrets in a different security context, like root/secretsuser-owned secret files only accessible by the user for certain actions (the simplest way would be eg. sudoers file white listing a precise command like git push), which would prevent arbitrary reads of secrets. The other part of this attack, creating new github actions, is also a privilege, normal users dont need to exercise that often or unconstrained. There are certainly ways to prevent/restrict that too. All this "was a supply chain attack" fuzz here is IMO missing the forest for the trees. Changing the security context for these two actions is easier to implement than supply chain analysis and this basic approach is more reliable than trusting the community to find a backdoor before you apply the update. Its security 101. Sure, there are post-install scripts that can attack the system but that is a whole different game.
glennericksen 1y ago
You can switch to the mentioned "delayed" mode if you're using pnpm. A few days ago, pnpm 10.16 introduced a minimumReleaseAge setting that delays the installation of newly released dependencies by a configurable amount of time. https://pnpm.io/blog/releases/10.16 https://pnpm.io/blog/releases/10.16
pabs3 1y ago
This is where distributed code audits come in, you audit what you can, others audit what they can, and the overlaps of many audits gives you some level of confidence in the audited code. https://github.com/crev-dev/ https://github.com/crev-dev/
esafak 1y ago
> One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. You can do it: https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/ https://github.blog/changelog/2025-07-01-dependabot-supports... https://docs.renovatebot.com/configuration-options/#minimumreleaseage https://docs.renovatebot.com/configuration-options/#minimumr... https://www.stepsecurity.io/blog/introducing-the-npm-package-cooldown-check https://www.stepsecurity.io/blog/introducing-the-npm-package...
travisgriggs 1y ago
Use less dependencies :) And larger dependencies that can be trusted in larger blocks. I'll bet half of a given projects dependencies are there to "gain experience with" or be able to name drop that you've used them. Less is More. We used to believe that. And then W3C happened.
franky47 1y ago
> One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. You can do this with npm (since version 6.9.0). To only get registry deps that are over a week old: $ npm install --before="$(date -v -7d)" Source: Darcy Clarke - https://bsky.app/profile/darcyclarke.me/post/3lyxir2yu6k2s https://bsky.app/profile/darcyclarke.me/post/3lyxir2yu6k2s
catlifeonmars 1y ago
I think it definitely couldn’t hurt. You’re right it doesn’t eliminate the threat of supply chain attacks, but it would certainly reduce them and wouldn’t require much effort to implement (either manually or via script). You’re basically giving maintainers and researchers time to identify new malware and patch or unrelease them before you’re exposed. Just make sure you still take security patches.
PeterStuer 1y ago
Not you. But one would expect major cybersecurity vendors such as Crowdstrike to screen their dependencies, yet they are all over the affected list.
- rpodraza 1y ago
  It looks like they actually got infected as well. So it's not only that, their security practices seem crap
rkagerer 1y ago
> sort of a "delayed" mode That's the secret lots of enterprises have relied on for ages. Don't be bleeding edge, let the rest of the world gineau pig the updates and listen for them to sound the alarm if something's wrong. Obviously you do still need to pay attention to the occasional, major, hot security issues and deal with them in a swift fashion. Another good practice is to control when your updates occur - time them when it's ok to break things and your team has the bandwidth to fix things. This is why I laughed hard when Microsoft moved to aggressively push Windows updates and the inevitable borking it did to people's computers at the worst possible times ("What's that you said? You've got a multi-million dollar deliverable pitch tomorrow and your computer won't start due to a broken graphics driver update?). At least now there's a "delay" option similar to what you described, but it still riles me that update descriptions are opaque (so you can't selectively manage risk) and you don't really have the degree of control you ought to.
robertlagrant 1y ago
> As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embedded malware. I think Github's Dependabot can help you here. You can also host your own little instance of DependencyTrack and keep up to date with vulnerabilities.
heavyset_go 1y ago
If your employer paid your dependencies' verified authors to provide them licensed and signed software, you wouldn't have to rely on a free third party intermediary with a history of distributing massive amounts of malware for your security.
wvh 1y ago
As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines of code. There are no real solutions to the problem, except for reducing exposure somewhat by limiting yourself to a mostly frozen subset of packages that are hopefully vetted more stringently by more people.
- mgaunard 1y ago
  I've always been very careful about dependencies, and freezing them to versions that are known to work well. I was shocked when I found out that at some of the most profitable shops, most of their code is just a bunch of different third-party libraries badly cobbled together, with only a superficial understanding of how those libraries work.
- p0w3n3d 1y ago
  > You are an obstruction for making profit. This explains a lot. Really, this is the great reason of why the society is collapsing as we speak. "There should be no DRM in phones" - "You Are An Obstruction To Making Profit". "People should own their devices, we must not disallow custom software on it" - "YAAOTMP" "sir, the application will weigh 2G and do almost nothing yet, should we minify it or use different framework?" - "YAAOTMP". "Madame, this product will cost too much and require unnecessary payments" - "YAAOTMP" Etc. etc. Like in this "Silicon Valley" comedy series. But for real, and affecting us greatly.
  - ivan_gammel 1y ago
    Death comes to corp CEO, he screams YAAOTMP, death leaves shocked. Startup CEO watches the scene. His jedi sword turns from blue to red.
- jen729w 1y ago
  At my previous enterprise we had a saying: Security: we put the ‘no’ in ‘innovation’.
Hilift 1y ago
> I'm not really sure what to do You need an EDR and code repo scanner. Exploring this as a technical problem of the infrastructure will accomplish. The people that create these systems are long gone and had/have huge gaps in their capabilities to stop creating these problems.
1oooqooq 1y ago
would you pay a subscription for a vetted repo?
_el1s7 1y ago
Rather than the user doing that "delay" installation, it would be a good idea if the package repository (i.e. NPM) actually enforced something like that. For example, whenever a new version of a package is released, it's published to the repository but not allowed to be installed for at least 48 hours, and this gives time to any third-party observers to detect a malware early.
Aldipower 1y ago
You can use Sonatype or Artifactory as an self-hosted provider for your NPM packages that keep their own NPM repository. This way you can delay and control updates. It is common enterprise practice.

by kelnos 1y ago

CraftThatBlock 1y ago

pnpm just added this: https://pnpm.io/blog/releases/10.16 https://pnpm.io/blog/releases/10.16

jauntywundrkind 1y ago
minimumReleaseAge is pretty good! Nice!! I do wish there were some lists of compromised versions, that package managers could disallow from.
thepill 1y ago
bun is also working on it: https://github.com/oven-sh/bun/issues/22679 https://github.com/oven-sh/bun/issues/22679
philipwhiuk 1y ago
Aren't they found quickly because people upgrade quickly?
drdaeman 1y ago
This sounds nice in theory, but does it really solve the issue? I think that if no one's installing that package then no one is noticing the malware and no one is reporting that package either. It merely slightly improves the chances that author would notice a version they didn't release, but this doesn't work if author is not particularly actively working the compromised project.
- brw 1y ago
  These days compromised packages are often detected automatically by software that scans all packages uploaded to npm like https://socket.dev https://socket.dev or https://snyk.io https://snyk.io. So I imagine it's still useful to have those services scan these packages first, before they go out to the masses. Measures like this also aren't meant to be "final solutions" either, but stop-gaps. Slowing the spread can still be helpful when a large scale attack like this does occur. But I'm also not entirely sure how much that weighs against potentially slowing the discovery as well. Ultimately this is still a repository problem and not a package manager one. These are merely band-aids. The responsibility lies with npm (the repository) to implement proper solutions here. > The responsibility lies with
- kelnos 1y ago
  No, it doesn't solve the issue, but it probably helps. And I agree that if everyone did this, it would slow down finding issues in new releases. Not really sure what to say to that... aside from the selfish idea that if I do it, but most other people don't, it won't affect me.
- dec0dedab0de 1y ago
  a long enough delay would solve the issue for account takeovers, and bold attacks like this. It would not solve for a bad actor gaining trust over years, then contributing seemingly innocent code that contains an exploitable bug with enough plausible deniability to remain on the team after it is patched.
brw 1y ago
there's apparently an npm RFC from 2022 proposing a similar (but potentially slightly better?) solution https://github.com/npm/rfcs/issues/646 https://github.com/npm/rfcs/issues/646
smrtinsert 1y ago
this btw would also solve social media. if only accounts required a month waiting period before they could speak.

gameman144 1y ago

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually pretty sensible.

Ajedi32 1y ago
If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.
- curtisf 1y ago
  This is true to the extent that you actually _use_ all of the features of a dependency. You only need to rewrite what you use, which for many (probably most) libraries will be 1% or less of it
  - zahlman 1y ago
    Indeed. About 26% of the disk space for a freshly-installed copy of pip 25.2 for Python 3.13 comes from https://pypi.org/project/rich/ https://pypi.org/project/rich/ (and its otherwise-unneeded dependency https://pypi.org/project/Pygments/ https://pypi.org/project/Pygments/), "a Python library for rich text and beautiful formatting in the terminal", hardly any of the features of which are relevant to pip. This is in spite of an apparent manual tree-shaking effort (mostly on Pygments) — a separate installed copy of rich+Pygments is larger than pip. But even with that attempt, for example, there are hundreds of kilobytes taken up for a single giant mapping of "friendly" string names to literally thousands of emoji. Another 20% or more is https://pypi.org/project/requests/ https://pypi.org/project/requests/ and its dependencies — this is an extremely popular project despite that the standard library already provides the ability to make HTTPS connections (people just hate the API that much). One of requests' dependencies is certifi, which is basically just a .pem file in Python package form. The vendored requests has not seen any tree-shaking as far as I can tell. This sort of thing is a big part of why I'll be able to make PAPER much smaller.

eschneider 1y ago

If you pull something into your project, you're responsible for it working. Full stop. There are a lot of ways to manage/control dependencies. Pick something that works best for you, but be aware, due diligence, like maintenance is ultimately your responsibility.

IshKebab 1y ago
That's very naive. We can do better than this.
- hermannj314 1y ago
  Almost all software has a no warranty clause. I am not a lawyer but in pretty plain English every piece of software I have ever used has said exactly that I can fuck off if I expect it to work or do anything. To clarify - I dont think it is naive to assume the software is as-is with all responsibilities on the user since that is exactly what lawyers have made all software companies say that for over 50 years.
  - gmueckl 1y ago
    Product liability is coming for software. Warranty disclaimers in licenses will be rendered ineffective by the end of 2026 at the latest.
    - tcoff91 1y ago
      Source? An open source library is not necessarily a ‘product’ at all.
      - LtWorf 1y ago
        No source because it's not real. There's talk about final products and making the companies selling them responsible. But open source developers are not responsible.
    - respondo2134 1y ago

skybrian 1y ago

When using Go, you don't get updated indirect dependencies until you update a direct dependency. It seems like a good system, though it depends on your direct dependencies not updating too quickly.

silverwind 1y ago
The auto-updating behaviour dependencies because of the `^` version prefix is the root problem. It's best to never use `^` and always specify exact version, but many maintainers apparently can't be bothered with updating their dependencies themselves so it became the default.

Melatonic 1y ago

Lot of software has update policies like this and then also people will run a separate test environment updating to latest

spion 1y ago

pnpm just added minimum age for dependencies https://pnpm.io/blog/releases/10.16#new-setting-for-delayed-dependency-updates https://pnpm.io/blog/releases/10.16#new-setting-for-delayed-...

kelnos 1y ago
Oh brilliant. I've been meaning to start migrating my use to pnpm; this is the push I needed.
ojosilva 1y ago
From your link: > In most cases, such attacks are discovered quickly and the malicious versions are removed from the registry within an hour. By delaying the infected package availability (by "aging" dependencies), we're only delaying the time, and reducing samples, until it's detected. Infections that lay dormant are even more dangerous than explosives ones. The only benefit would be if, during this freeze, repository maintainers were successfully pruning malware before it hits the fan, and the freeze would give scanners more time to finish their verification pipelines. That's not happening afaik, NPM is crazy fast going from `npm publish` to worldwide availability, scanning is insufficient by many standards.
- jkrems 1y ago
  Afaict many of these recent supply chain attacks _have_ been detected by scanners. Which ones flew under the radar for an extended period of time? From what I can tell, even a few hours of delay for actually pulling dependencies post-publication to give security tools a chance to find it would have stopped all (?) recent attacks in their tracks.
oefrha 1y ago
Thank god, adopting this immediately. Next I’d like to see Go-style minimum version selection instead.

duped 1y ago

Personally, I go further than this and just never update dependencies unless the dependency has a bug that affects my usage of it. Vulnerabilities are included. It is insane to me how many developers update dependencies in a project regularly. You should almost never be updating dependencies, when you do it should be because it fixes a bug (including a security issue) that you have in your project, or a new feature that you need to use. The only time this philosophy has bitten me was in an older project where I had to convince a PM who built some node project on their machine that the vulnerability warnings were not actually issues that affected our project. Edit: because I don't want to reply to three things with the same comment - what are you using for dependencies where a) you require frequent updates and b) those updates are really hard? Like for example, I've avoided updating node dependencies that have "vulnerabilities" because I know the vuln doesn't affect me. Rarely do I need to update to support new features because the dependency I pick has the features I need when I choose to use it (and if it only supports partial usage, you write it yourself!). If I see that a dependency frequently has bugs or breakages across updates then I stop using it, or freeze my usage of it.

erulabs 1y ago
counterpoint, if the runtime itself (nodejs) has a critical issue, you haven't updated for years, you're on an end-of-life version, and you cannot upgrade because you have dependencies that do not support the new version of the runtime, you're in for a painful day. The argument for updating often is that when you -are- exposed to a vulnerability that you need a fix for, it's a much smaller project to revert or patch that single issue. Otherwise, I agree with the sentiment that too many people try to update the world too often. Keeping up with runtime updates as often as possible (node.js is more trusted than any given NPM module) and updating only when dependencies are no longer compatible is a better middle ground.
- RussianCow 1y ago
  The same logic you used for runtimes also applies to libraries. Vulnerabilities are found in popular JS libraries all the time. The surface area is, of course, smaller than that of a runtime like Node.js, but there is still lots of potential for security issues with out-of-date libraries. There really is no good solution other than to reduce the surface area for vulnerabilities by reducing the total amount of code you depend on (including third-party code). In practice, this means using as few dependencies as possible. If you only use one or two functions from lodash or some other helper library, you're probably better off writing or pulling in those functions directly instead.

TZubiri 1y ago

Install less dependencies, code more.

vvpan 1y ago
Copy-paste more.
- baobabKoodaa 1y ago
  I guess this is a joke, but imo it shouldn't be.
  - TZubiri 1y ago
    I'm all for disregarding DRY and copypasting code you wrote. But I think for untrusted third party code, it's much better to copy the code by hand, that way you are really forced to audit it. There really isn't much of an advantage to copying an install.sh script compared to just downloading a running the .sh, whereas writing the actual .sh commands on the command line (and following any other URLs before executing them) is golden.
  - vvpan 1y ago
    Not entirely a joke actually. For example, I have worked at a large corp where dependencies were high discouraged. For example lodash was not used in the codebase I was working on and if you really needed something from lodash you were encouraged to copy-paste the function. This won't work for large libraries of course but the copy-paste-first mentality is not a bad one.
- 1oooqooq 1y ago
  wonder how long for llms to spew the malware in those packages along the code when you request the same functionality.
kelnos 1y ago
Sure, and I do that whenever I can. But I'm not going to write my own react, or even my own react-hook-form. I'm not going to rewrite stripe-js. Looking through my 16 direct dependencies -- that pull in a total of 653 packages, jesus christ -- there's only one of them that I'd consider writing myself (js-cookie) in order to reduce my dependency count. The rest would be a maintenance burden that I shouldn't have to take on.

Waterluvian 1y ago

I update my deps once a year or when I specifically need to. That helps a bit. Though it upsets the security theatre peeps at work who just blindly think dependabot issues means I need to change dependencies.

LtWorf 1y ago
I never understood the "let's always pin everything to the latest version and let's update the pinned versions every day"… what is even the point of this exercise? Might as well not pin at all.

homebrewer 1y ago

Don't update your dependencies manually. Setup renovate to do it for you, with a delay of at least a couple of weeks, and enable vulnerability alerts so that it opens PRs for publicly known vulnerabilities without delay https://docs.renovatebot.com/configuration-options/#minimumreleaseage https://docs.renovatebot.com/configuration-options/#minimumr... https://docs.renovatebot.com/presets-default/#enablevulnerabilityalerts https://docs.renovatebot.com/presets-default/#enablevulnerab...

collinmanderson 1y ago
Why was this comment downvoted? Please explain why you disagree.
- biggusdickus69 1y ago
  I didn’t downvote, but... Depending on a commercial service is out of the question for most open source projects.
  - isbvhodnvemrwvn 1y ago
    Renovate is not commercial, it's an own source dependabot, quite more copable at that.
    - wereHamster 1y ago
      AGPL is a no-go for many companies (even when it's just a tool that touches your code and not a dependency you link to).
      - 1oooqooq 1y ago
        good. that's the point. agpl is a no go for companies not intending to ever contribute anything back. good riddance.

johtso 1y ago

Maybe one approach would be to pin all dependencies, and not use any new version of a package until it reaches a certain age. That would hopefully be enough time for any issues to be discovered?

rapfaria 1y ago
People living on the latest packages with their dependabots never made any sense to me, ADR. They trusted their system too much
- LtWorf 1y ago
  If you don't review the pinned versions, it makes no difference.
pfych 1y ago
Packages can still be updated, even if pinned. If a dependency of a dependency is not pinned - it can still be updated.

0xbadcafebee 1y ago

Stick to (pin) old stable versions, don't upgrade often. Pain in the butt to deal with eventual minimum-version-dependency limitations, but you don't get the brand new releases with bugs. Once a year, get all the newest versions and figure out all the weird backwards-incompatible bugs they've introduced. Do it over the holiday season when nobody's getting anything done anyway.

nostrademons 1y ago

npm shrinkwrap and then check in your node_modules folder. Don't have each developer (or worse, user) individually run npm install. It's common among grizzled software engineering veterans to say "Check in the source code to all of your dependencies, and treat it as if it were your own source code." When you do that, version upgrades are actual projects. There's a full audit trail of who did what. Every build is reproducible. You have full visibility into all code that goes into your binary, and you can run any security or code maintenance tools on all of it. You control when upgrades happen, so you don't have a critical dependency break your upcoming project.

collinmanderson 1y ago

> sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago. For Python's uv, you can do something like: > uv lock --exclude-newer $(date --iso -d "2 days ago")

zygentoma 1y ago
Awesome tip, thanks!
parlortricks 1y ago
oh that uv lock is neat, i am going to give that a go

deleted 1y ago

[deleted]

1over137 1y ago

>It's not feasible for me to audit every single one of my dependencies Perhaps I’m just ignorant of web development, but why not? We do so with our desktop software.

galaxy_gas 1y ago
Average .net core desktop complex app may have a dozen dependencies if it get to that point. Average npm todo list may have several thousand if not more

cmckn 1y ago

> instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago The problem with this approach is you need a certain number of guinea pigs on the bleeding edge or the outcome is the same (just delayed). There is no way for anyone involved to ensure that balance is maintained. Reducing your surface area is a much more effective strategy.

biggusdickus69 1y ago
Not necessarily, some supply chain compromises are detected within a day by the maintainers themselves, for example by their account being taken over. It would be good to mitigate those at least.
- cmckn 1y ago
  In that specific scenario, sure; but I don't think that's a meaningful guardrail for a business.

hedora 1y ago

I recently started using npm for an application where there’s no decent alternative ecosystem. The signal desktop app is an electron app. Presumably it has the same problem. Does anyone know of any reasonable approaches to using npm securely? “Reduce your transitive dependencies” is not a reasonable suggestion. It’s similar to “rewrite all the Linux kernel modules you need from scratch” or “go write a web browser”.

umpalumpaaa 1y ago
Most big tech companies maintain their own NPM registry that only includes approved packages. If you need a new package available in that registry you have to request it. A security team will then review that package and its deps and add it to the list of approved packages… I would love to have something like that "in the open"…
- skydhash 1y ago
  A debian version of NPM? I've seen a lot of hates on Reddit and other places about Debian because the team focuses on stability. When you look at the project, it's almost always based on Rust or Python.
wolvesechoes 1y ago
> “Reduce your transitive dependencies” is not a reasonable suggestion. It’s similar to “rewrite all the Linux kernel modules you need from scratch” or “go write a web browser”. Oh please, do not compare writing bunch of utilities for you "app" with writing a web browser.

benoau 1y ago

I like to pin specific versions in my package.json so dependencies don't change without manual steps, and use "npm ci" to install specifically the versions in package-lock.json. My CI runs "npm audit" which will raise the alarms if a vulnerability emerges in those packages. With everything essentially frozen there either is malware within it, or there is not going to be, and the age of the packages softly implies there is not.

abrookewood 1y ago

The article explicitly mentions a way to do this: Use NPM Package Cooldown Check The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks are detected within the first 24 hours of a malicious package release, and the projects that get compromised are often the ones that rushed to adopt the version immediately. By introducing a short waiting period before allowing new dependencies, teams can reduce their exposure to fresh attacks while still keeping their dependencies up to date.

loginatnine 1y ago
That's a feature of stepsecurity though, it's not built-in.
autoexec 1y ago
This is basically what I recommended people do with windows updates back when MS gave people a choice about when/if to install them, with shorter windows for critical updates and much longer ones for low priority updates or ones that only affected things they weren't using.
DrewADesign 1y ago
And hope there isn’t some recently patched zero-day RCE exploit at the same time.
throwawayqqq11 1y ago
This attack was only targeting user environments. Having secrets in a different security context, like root/secretsuser-owned secret files only accessible by the user for certain actions (the simplest way would be eg. sudoers file white listing a precise command like git push), which would prevent arbitrary reads of secrets. The other part of this attack, creating new github actions, is also a privilege, normal users dont need to exercise that often or unconstrained. There are certainly ways to prevent/restrict that too. All this "was a supply chain attack" fuzz here is IMO missing the forest for the trees. Changing the security context for these two actions is easier to implement than supply chain analysis and this basic approach is more reliable than trusting the community to find a backdoor before you apply the update. Its security 101. Sure, there are post-install scripts that can attack the system but that is a whole different game.

glennericksen 1y ago

You can switch to the mentioned "delayed" mode if you're using pnpm. A few days ago, pnpm 10.16 introduced a minimumReleaseAge setting that delays the installation of newly released dependencies by a configurable amount of time. https://pnpm.io/blog/releases/10.16 https://pnpm.io/blog/releases/10.16

pabs3 1y ago

This is where distributed code audits come in, you audit what you can, others audit what they can, and the overlaps of many audits gives you some level of confidence in the audited code. https://github.com/crev-dev/ https://github.com/crev-dev/

esafak 1y ago

> One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. You can do it: https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/ https://github.blog/changelog/2025-07-01-dependabot-supports... https://docs.renovatebot.com/configuration-options/#minimumreleaseage https://docs.renovatebot.com/configuration-options/#minimumr... https://www.stepsecurity.io/blog/introducing-the-npm-package-cooldown-check https://www.stepsecurity.io/blog/introducing-the-npm-package...

travisgriggs 1y ago

Use less dependencies :) And larger dependencies that can be trusted in larger blocks. I'll bet half of a given projects dependencies are there to "gain experience with" or be able to name drop that you've used them. Less is More. We used to believe that. And then W3C happened.

franky47 1y ago

> One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. You can do this with npm (since version 6.9.0). To only get registry deps that are over a week old: $ npm install --before="$(date -v -7d)" Source: Darcy Clarke - https://bsky.app/profile/darcyclarke.me/post/3lyxir2yu6k2s https://bsky.app/profile/darcyclarke.me/post/3lyxir2yu6k2s

catlifeonmars 1y ago

I think it definitely couldn’t hurt. You’re right it doesn’t eliminate the threat of supply chain attacks, but it would certainly reduce them and wouldn’t require much effort to implement (either manually or via script). You’re basically giving maintainers and researchers time to identify new malware and patch or unrelease them before you’re exposed. Just make sure you still take security patches.

PeterStuer 1y ago

Not you. But one would expect major cybersecurity vendors such as Crowdstrike to screen their dependencies, yet they are all over the affected list.

rpodraza 1y ago
It looks like they actually got infected as well. So it's not only that, their security practices seem crap

rkagerer 1y ago

> sort of a "delayed" mode That's the secret lots of enterprises have relied on for ages. Don't be bleeding edge, let the rest of the world gineau pig the updates and listen for them to sound the alarm if something's wrong. Obviously you do still need to pay attention to the occasional, major, hot security issues and deal with them in a swift fashion. Another good practice is to control when your updates occur - time them when it's ok to break things and your team has the bandwidth to fix things. This is why I laughed hard when Microsoft moved to aggressively push Windows updates and the inevitable borking it did to people's computers at the worst possible times ("What's that you said? You've got a multi-million dollar deliverable pitch tomorrow and your computer won't start due to a broken graphics driver update?). At least now there's a "delay" option similar to what you described, but it still riles me that update descriptions are opaque (so you can't selectively manage risk) and you don't really have the degree of control you ought to.

robertlagrant 1y ago

> As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embedded malware. I think Github's Dependabot can help you here. You can also host your own little instance of DependencyTrack and keep up to date with vulnerabilities.

heavyset_go 1y ago

If your employer paid your dependencies' verified authors to provide them licensed and signed software, you wouldn't have to rely on a free third party intermediary with a history of distributing massive amounts of malware for your security.

wvh 1y ago

As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines of code. There are no real solutions to the problem, except for reducing exposure somewhat by limiting yourself to a mostly frozen subset of packages that are hopefully vetted more stringently by more people.

mgaunard 1y ago
I've always been very careful about dependencies, and freezing them to versions that are known to work well. I was shocked when I found out that at some of the most profitable shops, most of their code is just a bunch of different third-party libraries badly cobbled together, with only a superficial understanding of how those libraries work.
p0w3n3d 1y ago
> You are an obstruction for making profit. This explains a lot. Really, this is the great reason of why the society is collapsing as we speak. "There should be no DRM in phones" - "You Are An Obstruction To Making Profit". "People should own their devices, we must not disallow custom software on it" - "YAAOTMP" "sir, the application will weigh 2G and do almost nothing yet, should we minify it or use different framework?" - "YAAOTMP". "Madame, this product will cost too much and require unnecessary payments" - "YAAOTMP" Etc. etc. Like in this "Silicon Valley" comedy series. But for real, and affecting us greatly.
- ivan_gammel 1y ago
  Death comes to corp CEO, he screams YAAOTMP, death leaves shocked. Startup CEO watches the scene. His jedi sword turns from blue to red.
jen729w 1y ago
At my previous enterprise we had a saying: Security: we put the ‘no’ in ‘innovation’.

Hilift 1y ago

> I'm not really sure what to do You need an EDR and code repo scanner. Exploring this as a technical problem of the infrastructure will accomplish. The people that create these systems are long gone and had/have huge gaps in their capabilities to stop creating these problems.

1oooqooq 1y ago

would you pay a subscription for a vetted repo?

_el1s7 1y ago

Rather than the user doing that "delay" installation, it would be a good idea if the package repository (i.e. NPM) actually enforced something like that. For example, whenever a new version of a package is released, it's published to the repository but not allowed to be installed for at least 48 hours, and this gives time to any third-party observers to detect a malware early.

Aldipower 1y ago

You can use Sonatype or Artifactory as an self-hosted provider for your NPM packages that keep their own NPM repository. This way you can delay and control updates. It is common enterprise practice.