10 ms·

Pnpm has a new setting to stave off supply chain attacks

238 points by ivanb 1y ago

postepowanieadm 1y ago
If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.
- anematode 1y ago
  A lot of people will still use npm, so they'll be the canaries in the coal mine :) More seriously, automated scanners seem to do a good job already of finding malicious packages. It's a wonder that npm themselves haven't already deployed an automated countermeasure.
  - vasachi 1y ago
    If only there was a high-ranking official at Microsoft, who could prioritize security[1]! /s [1] https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/ https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...
  - deleted 1y ago
    [deleted]
  - mcintyre1994 1y ago
    In the case of the chalk/debug etc hack, the first detection seemed to come from a CI build failure it caused: https://jdstaerk.substack.com/p/we-just-found-malicious-code-in-the https://jdstaerk.substack.com/p/we-just-found-malicious-code... > It started with a cryptic build failure in our CI/CD pipeline, which my colleague noticed > This seemingly minor error was the first sign of a sophisticated supply chain attack. We traced the failure to a small dependency, error-ex. Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3, which got published just a few minutes earlier.
    - DougBTX 1y ago
      > Our package-lock.json specified the stable version 1.3.2 or newer Is that possible? I thought the lock files restricted to a specific version with an integrity check hash. Is it possible that it would install a newer version which doesn't match the hash in the lock file? Do they just mean package.json here?
      - streptomycin 1y ago
        If they were for some reason doing `npm install` rather than `npm ci`, then `npm install` does update packages in the lock file. Personally I always found that confusing, and yarn/pnpm don't behave that way. I think most people do `npm ci` in CI, unless they are using CI to specifically test if `npm install` still works, which I guess maybe would be a good idea if you use npm since it doesn't like obeying the lock file.
        Rockslide 1y ago
        How does this get repeated over and over, when it's simply not true? At least not anymore. npm install will only update the lockfile if you make changes to your package.json. Otherwise, it will install the versions from the lockfile.
        cluckindan 1y ago
        Are you 100% on that?
        Rockslide 1y ago
        Yes. As someone who's using npm install daily, and given the update cadence of npm packages, I would end up with dirty lock files very frequently if the parent statement were true. It just doesn't happen.
        mirashii 1y ago
        > How does this get repeated over and over, when it's simply not true? Well, for one, the behavior is somewhat insane. `npm install` with no additional arguments does update the lockfile if your package.json and your lockfile are out of sync with one another for any reason, and so to get a guarantee that it doesn't change your lockfile, you must do additional configuration or guarantee by some external mechanism that you don't ever have an out of date package.json and lock. For this reason alone, the advice of "just don't use npm install, use npm ci instead" is still extremely valid, you'd really like this to fail fast if you get out of sync. `npm install additional-package` also updates your lock file. Other package managers distinguish these two operations, with the one to add a new dependency being called "add" instead of "install". The docs add to the confusion. https://docs.npmjs.com/cli/v11/commands/npm-install#save https://docs.npmjs.com/cli/v11/commands/npm-install#save suggests that writing to package-lock.json is the default and you need to change configuration to disable it. The notion that it won't change your lock file if you're already in sync between package.json and package-lock.json is not actually spelled out clearly anywhere on the page. > At least not anymore. You've partially answered your own question here.
  - kjok 1y ago
    > automated scanners seem to do a good job already of finding malicious packages. That's not true. This latest incident was detected by an individual researcher, just like many similar attacks in the past. Time and again, it's been people who flagged these issues, later reported to security startups, not automated tools. Don't fall for the PR spin. If automated scanning were truly effective, we'd see deployments across all major package registries. The reality is, these systems still miss what vigilant humans catch.
    - hobofan 1y ago
      > If automated scanning were truly effective, we'd see deployments across all major package registries. No we wouldn't. Most package registries are run by either bigcorps at a loss or by community maintainers (with bigcorps again sponsoring the infrastructure). And many of them barely go beyond the "CRUD" of package publishing due to lack of resources. The economic incentives of building up supply chain security tools into the package registries themselves are just not there.
      - kjok 1y ago
        You're right that registries are under-resourced. But, if automated malware scanning actually worked, we'd already see big tech partnering with package registries to run continuous, ecosystem-wide scanning and detection pipelines. However, that isn't happening. Instead, we see piecemeal efforts from Google with assurance artifacts (SLSA provenance, SBOMs, verifiable builds), Microsoft sponsoring OSS maintainers, Facebook donating to package registries. Google's initiatives stop short of claiming they can automatically detect malware. This distinction matters. Malware detection is, in the general case, an undecidable problem (think halting problem and Rice theorem). No amount of static or dynamic scanning can guarantee catching malicious logic in arbitrary code. At best, scanners detect known signatures, patterns, or anomalies. They can't prove absence of malicious behavior. So the reality is: if Google's assurance artifacts stop short of claiming automated malware detection is feasible, it's a stretch for anyone else to suggest registries could achieve it "if they just had more resources." The problem space itself is the blocker, not just lack of infra or resources.
- singulasar 1y ago
  Not really, app sec companies scan npm constantly for updated packages to check for malware. Many attacks get caught that way. e.g. the debug + chalk supply chain attack was caught like this: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
- blamestross 1y ago
  1) Checks and audits will still happen (if they are happening at all) 2) Real chances for owners to notice they have been compromised 3) Adopt early before that commons is fully tragedy-ed.
- acdha 1y ago
  Think about how the three major recent incidents were caught: not by individual users installing packages but by security companies running automated scans on new uploads flagging things for audits. This would work quite well in that model, and it’s cheap in many cases where there isn’t a burning need to install something which just came out.
  - kjok 1y ago
    I think there's some confusion here. No automated scan was able to catch the attack. It was an individual who notified these startups.
    - acdha 1y ago
      Quite possibly - there have been several incidents recently and a number of researchers working together so it’s not clear exactly who found something first and it’s definitely not as simple to fix as tossing a tool in place. The CEO of socket.dev described an automated pipeline flagging new uploads for analysts, for example, which is good but not instantaneous: https://news.ycombinator.com/item?id=45257681 https://news.ycombinator.com/item?id=45257681 The Aikido team also appear to be suggesting they investigated a suspicious flag (apologies if I’m misreading their post), which again needs time for analysts to work: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com... My thought was simply that these were caught relatively quickly by security researchers rather than by compromised users reporting breaches. If you didn’t install updates with a relatively short period of time after they were published, the subsequent response would keep you safe. Obviously that’s not perfect and a sophisticated, patient attack like liblzma suffered would likely still be possible but there really does seem to be a value to having something like Debian’s unstable/stable divide where researchers and thrill-seekers would get everything ASAP but most people would give it some time to be tested. What I’d really like to see is a community model for funding that and especially supporting independent researchers.
  - nikanj 1y ago
    Automated scans have detected 72251 out of the previous 3 supply-chain attacks
- kibwen 1y ago
  Also, if everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to broadly disseminate the fix for a compromise in the wild. The knife cuts both ways.
- kaelwd 1y ago
  The chalk+debug+error-ex maintainer probably would have noticed a few hours later when they got home and saw a bunch of "Successfully published" emails from npm that they didn't trigger.
- djdjsjejb 1y ago
  thats what npm is for, so they install it first. cannon fodders.
omnicognate 1y ago
Should have included the units in the name or required a choice of unit to be selected as part of the value. Sorry, just a bugbear of mine.
- zokier 1y ago
  Or just use ISO8601 standard notation (e.g. "P1D" for one day)
  - 1oooqooq 1y ago
    or PT1400M or P0.5DT700M? oh, you can use commas too. and if you're still not thinking this is fun, here's a quote from Wikipedia "But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to Daylight saving time." just add a unit to your period parameters. sigh.
    - brewmarche 1y ago
      Maybe surprising for days (could also happen with minutes because of leap seconds technically :-) but for months and years this is more apparent due to month ends and leap years.
  - johanyc 1y ago
    TIL ISO8601 also standardizes duration
- fzeindl 1y ago
  ISO8601 durations should be used, like PT3M.
  - aa-jv 1y ago
    Should be easy, just add the ISO8601-duration package to your project .. /s
  - mort96 1y ago
    Oh wow, never looked at ISO8601 durations before and I had no idea they were this ugly. Please, no, don't make me deal with ISO8601. I'd rather write a number of seconds or a format like 'X weeks' or 'Y hours Z minutes'x ISO8601 looks exclusively like a data interchange format
OskarS 1y ago
I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking, so security isn’t as critical for us, stability is much more important). Does the JS ecosystem really move so fast that you can’t wait a month or two before updating your packages?
- codemonkey-zeta 1y ago
  I think the surface area for bugs in a C++ dependency is way bigger than a JS one. Pulling in a new node module is not going to segfault my app, for example.
- progx 1y ago
  Yes, but this is not only JS dependent, in PHP (composer) is the same. Normally old major or minor packages don't get an update, only the latest. E.g. 4.1.47 (no update), 4.2.1 (yes got update). So if the problem is in 4.1 you must "upgrade" to 4.2. With "perfect" semver, this shouldn't be a problem, cause 4.2 only add new features... but... back to reality, the world is not perfect.
- ozim 1y ago
  NPM packages follow semantic versioning so minor versions should be fine to auto update. (there is still an issue what for package maintainer might be minor not being minor for you - but let's stick to ideal world for that) I don't think people are having major versions updated every month, it is more really like 6 months or once a year. I guess the problem might be people think auto updating minor versions in CI/CD pipeline will keep them more secure as bug fixes should be in minor versions but in reality we see it is not the case and attackers use it to spread malware.
  - otterley 1y ago
    > so minor versions should be fine to auto update The problem is that "should" assumes that point releases never introduce regressions (whether they be security, performance, or correctness). Unfortunately, history has shown that regressions can and do happen. The best practice for release engineering (CI/CD, if you will) is to assume the worst, test thoroughly, and release incrementally (include bake time). Delaying updates isn't just a backstop against security vulnerabilities; it's useful for letting the dust settle after an update of any kind that can adversely impact the application. The theory is that someone will find it before you, report it, and that a fix will be issued.
progx 1y ago
That solve not really the problem. A better (not perfect) solution: Every package should by AI analysed on an update before it is public available, to detect dangerous code and set a rating. In package.json should be a rating defined, when remote package is below that value it could be updated, if it is higher a warning should appear. But this will cost, but i hope, that companies like github, etc. will allow package-Repositories to use their services for free. Or we should find a way, to distribute this services to us (the users and devs) like a BOINC-Client.
- jonkoops 1y ago
  Ah, yes! The universal and uncheatable LLM! Surely nothing can go wrong.
  - progx 1y ago
    As i wrote "not perfect". But better than anything else or nothing.
    - robertlagrant 1y ago
      The Politician's Syllogism[0] is instructive. [0] https://en.wikipedia.org/wiki/Politician's_syllogism https://en.wikipedia.org/wiki/Politician's_syllogism
      - progx 1y ago
        OK, we are here now on reddit or facebook? I thought we discuss here problems and possible solutions. My fault.
        deleted 1y ago
        [deleted]
        robertlagrant 1y ago
        I don't think "we should use AI to solve this" is a solution proposal.
gausswho 1y ago
'Delayed dependency updates' is a response to supply-side attacks in the JavaScript world, but it aptly describes how I have come to approach technology broadly. Large tech companies, as with most industry, have realized most people will pay with their privacy and data long before they'll pay with money. We live in a time of the Attention Currency, after all. But you don't need to be a canary to live a technology-enabled life. Much software that you pay with your privacy and data has free or cheap open-source alternatives that approach the same or higher quality. When you orient your way of consuming to 'eh, I can wait till the version that respects me is built', life becomes more enjoyable in myriad ways. I don't take this to absolute levels. I pay for fancy pants LLM's, currently. But I look forward to the day not too far away where I can get today's quality for libre in my homelab.
wallrat 1y ago
There are a few commercial products that allow you to do this also for other ecosystems (e.g. maven, nuget, pypi etc), including ours https://docs.bytesafe.dev/policies/delay-upstream/ https://docs.bytesafe.dev/policies/delay-upstream/ Good to see some OSS alternatives showing up!
_betty_ 1y ago
how about requiring some kind of interaction if they want to run an install script?
- jsheard 1y ago
  Pnpm already did that: https://github.com/pnpm/pnpm/releases/tag/v10.0.0 https://github.com/pnpm/pnpm/releases/tag/v10.0.0
the_mitsuhiko 1y ago
I think uv should get some credit for being an early supporter of this. They originally added it as a hidden way to create stable fixtures for their own tests, but it has become a pretty popular flag to use. This for instance will only install packages that are older than 14 days: uv sync --exclude-newer $(date -u -v-14d '+%Y-%m-%dT%H:%M:%SZ') It's great to see this kind of stuff being adopted in more places.
- mcintyre1994 1y ago
  Nice, but I think the config file is a much better implementation for protecting against supply chain attacks, particularly those targeting developers rather than runtime. You don’t want to rely on every developer passing a flag every time they install. This does suffer from the risk of using `npm install` instead of `pnpm install` though. It would also be nice to have this as a flag so you can use it on projects that haven't configured it though, I wonder if that could be added too.
  - cap11235 1y ago
    You can put the uv setting in pyproject.toml or uv.toml.
    - mcintyre1994 1y ago
      Nice, supporting both definitely seems ideal.
    - fainpul 1y ago
      But then you have to hardcode a timestamp, since this is not gonna work in uv.toml: exclude-newer = $(date -uv -14d '+%Y-%m-%dT%H:%M:%SZ')
  - ramses0 1y ago
    Just Minimum Version Selection in conjunction with "Minimum non-Vulnerable Version" (and this "--minAge") would do a lot, and effectively suss out a lot of poorly/casually maintained packages (eg: "finished" ones). https://research.swtch.com/vgo-mvs#upgrade_timing https://research.swtch.com/vgo-mvs#upgrade_timing MVS makes tons of sense that you shouldn't randomly uptake "new" packages that haven't been "certified" by package maintainers in their own dependencies. In the case of a vulnerable sub-dependency, you're effectively having to "do the work" to certify that PackageX is compatible with PackageY, and "--minAge" gives industry (and maintainers) time to scan before insta-pwning anyone who is unlucky that day.
keraf 1y ago
I might be naive but why isn't any package manager (npm, pnpm, bun, yarn, ...) pushing for a permission system, where packages have to define in the package.json what permission they would like to access? À la Deno but scoped to dependencies or like mobile apps do with their manifest. I know it would take time for packages to adopt this but it could be implemented as parameters when installing a new dependency, like `npm i ping --allow-net`. I wouldn't give a library like chalk access to I/O, processes or network.
- IanCal 1y ago
  I feel like that would require work from the language side, or at least runtimes. Is there a way of stopping code in one package from, say, hitting the network? You might be able to do this around install scripts, though disk writing is likely needed for all (but perhaps locations could be controlled).
  - Filligree 1y ago
    We've seen a lot of stunningly incompetent attacks that nevertheless get to a lot of people. Yeah, it needs work from the language runtime, but I think even a hacky, leaky 'security' abstraction would be helpful, because the majority of malware developers probably aren't able to break out of a language-level sandbox, even if the language still allows you to do unsafe array access. Then we can iterate.
  - ____tom____ 1y ago
    Java had support for something very like this, but no one used it, and they recently removed it. https://openjdk.org/jeps/486 https://openjdk.org/jeps/486 It's too bad, it would be useful in this situation
h4ch1 1y ago
https://github.com/oven-sh/bun/issues/22679 https://github.com/oven-sh/bun/issues/22679 There's an open discussion about adding something similar to bun as well^ minimumReleaseAge doesn't seem to be a bulletproof solution so there's still some research/testing to be done in this area
__MatrixMan__ 1y ago
Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to create juicy attack surface around the resolution of that name to some bits.
- mirekrusin 1y ago
  name + version are immutable, you can't republish packages in npm under existing version. you can only unpublish. content hash integrity is verified in lockfiles. the problem is with dependencies using semver ranges, especially wide ones like "debug": "*" initiatives like provenance statements [0] / code signing are also good complement to delayed dependency updates. also not running as default / whitelisting postinstall scripts is good default in pnpm. modifying (especially adding) keys in npmjs.org should be behind dedicated 2fa (as well as changing 2fa) [0] https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements
  - __MatrixMan__ 1y ago
    Those are promises that npm intends to keep, but whether they do or not isn't something that you as a package user can verify. Plus there's also the possibility that the server you got those bits from was merely masquerading as npm. The only immutability that counts is immutability that you can verify, which brings us back to cryptographic hashes.
    - mirekrusin 1y ago
      ...which are already present in lockfiles, available in registry ie. https://registry.npmjs.org/debug https://registry.npmjs.org/debug etc. - it's not a problem.
- frankdejonge 1y ago
bamboozled 1y ago
Can anyone tell me if yarn just as vulnerable as NPM? Isn't it the packages that are vulnerable and not the package manger software itself?
- cluckindan 1y ago
  No, the ”vulnerability” here is npm unilaterally allowing postinstall scripts, which are then used as an entry point for malware. Of course, the malware could just embed itself as an IIFE and get launched when the package is loaded, so disallowing postinstall is not really a security solution.
  - bamboozled 1y ago
    Interesting, thanks, it contradicts what was said on another similar post.
  - paulhodge 1y ago
    Pnpm 10.x also has a feature to disallow post-install scripts by default. When using Pnpm you have to specifically enable a dependency to let it run its post-install scripts. It's a great feature that should be the standard. Yes if someone compromises a package then they can also inject malicious code that will trigger at runtime. But the thing about the recent NPM supply chain attack - it happened really quickly. There was a chain reaction of packages that got compromised which lead to more authors getting compromised. And I think a big reason why it moved so quickly was because of post-install scripts. If the attack happened more slowly, then the community would have more time to react and block the compromised packages. So just slowing down an attack is valuable on its own.
chr15m 1y ago
The correct value for this setting is infinity seconds. Upgrades should be considered and deliberate, not automatic.
- kibwen 1y ago
  The downside of this approach is that this is how you create an ecosystem where legitimate security fixes never end up getting applied. There's no free lunch, you need to decide whether you're more concerned about vulnerabilities intentional backdoors (and thus never update anything automatically) or vulnerabilities from ordinary unintentional bugs (and thus have a mechanism for getting security updates automatically).
  - chr15m 1y ago
    Yep. I'm calling it. The churn is more dangerous and fragile than the rot. Two alternatives: - The occasional alert from `npm audit` that you have to carefully, deliberately, and thoughtfully upgrade your way out of. - The shifting sands of 100s or 1000s of towering deps that change literally every time you `pnmp install`. The second one is the current situation and it is madness. There should be no package lock because package.json should be the package lock.
- esafak 1y ago
  No, it isn't. Upgrades should be routine, like exercising. With your approach it becomes increasingly difficult and eventually impossible to upgrade anything since it requires moving a mountain. An update a ̶d̶a̶y̶ week makes the tech debt go away.
  - chr15m 1y ago
    The reason upgrades have become routine is because modern software is slop. We should strive for software to do one thing well (or at least be made up of modular parts that do one thing well) and prize backwards compatability, so that it does not require constant churn. The sane middle ground between "constant upgrades" and "never upgrade" is to upgrade when there is an actual vulnerability found in a dependency. Instead of churn for no reason, you update only with a good reason.
Ozzie_osman 1y ago
Does anyone understand why npm isn't adding these sorts of features?
- deleted 1y ago
  [deleted]
- JoshuaEN 1y ago
  There was an NPM RFC for this feature (though not as focused on supply chain attacks) in 2022, but the main response mirrored some of the other comments in here. "waiting a length of time doesn’t increase security, and if such a practice became common then it would just delay discovery of vulnerabilities until after that time anyways" https://github.com/npm/rfcs/issues/646#issuecomment-1282497113 https://github.com/npm/rfcs/issues/646#issuecomment-12824971...
tuananh 1y ago
in corp settings, you usually have a proxy registry. you can setup firewall there for this kind of things to filter out based on license, cve, release date, etc...
user1999919 1y ago
but what will we ever do without our: "developers are lazy, developers are dumb, left-pad degeneracy!"
NamlchakKhandro 1y ago
npm is now the tutorial filter. If I see someone using npm as a cli tool unironically...
tripplyons 1y ago
If I run: pnpm config set -g minimumReleaseAge 1440 Does that work as well? I can't tell if the global settings are the same as workspace settings, and it lets me set nonsense keys this way, so I'm not sure if there is a global equivalent.
lloydatkinson 1y ago
Why must this be in a workspace file which you may not even have if you aren't in a monorepo, why not in package.json? Anyway, it's progress.
calyhre 1y ago
Yarn just landed a similar feature too https://github.com/yarnpkg/berry/pull/6901 https://github.com/yarnpkg/berry/pull/6901
- cluckindan 1y ago
  And it supports excluding single versions! Looks like yarn is back on the menu.
deleted 1y ago
[deleted]
nicoburns 1y ago
I feel like the correct solution to these problems (across NPM and all similar package managers) is a web-of-trust audit system based on: - Reviewing the source code in the actual published package - Tooling that enable one to easily see a trusted diff between a package version and the previous version of that package - Built-in support in the package manager CLIs to only install packages that have a sufficient number of manual reviews from trusted sources (+ no / not too many negative reviews). With manual review required to bypass these checks. There are enough users of each package that such a system should not be too onerous on users once the infrastructure was in place.
mceachen 1y ago
npm-check-updates has a PR for --cooldown as well: https://github.com/raineorshine/npm-check-updates/pull/1547 https://github.com/raineorshine/npm-check-updates/pull/1547
kardianos 1y ago
It seems like the core problem is (1) NPM node_modules is so large usually, no one actually audit them and (2) the NPM churn is so great, no one audits them and (3) the design of NPM appears to think that automatically updating point or minor versions is actually good and desirable. Go is one of the few packing systems that got these right.
Flimm 1y ago
How is the age of a package calculated? If the publishing date of a package is obtained from the package's metadata defined by the package author, (just like Git commit dates are defined by the Git committer), then that would defeat the purpose of this new feature. The whole purpose of this feature is to protect from malicious or compromised package authors. Instead, it is necessary to query the package registry, trusting the package registry for the age of the package, rather than the package author. I presume this is how it works.
- mnahkies 1y ago
  Eh we got confused implementing this today. Basically we severed connection to the public npm registry completely earlier in the week whilst this worm plays out. Unfortunately there wasn't a way to do this without taking our cached "good" public packages down as well, so we later replicated the good cached packages into a new standalone private registry to be the new upstream. The bit that was not obvious in the moment but self evident once we realised is that the registry we're using took the copy time as the publish time, and therefore our new 2 week delay is rejecting the copied packages... So sample size of one, but the registry we're using is definitely using upload time not any metadata in the packages themselves. Good to know the filtering is working.
  - Flimm 1y ago
    Thank you for the explanation. And thank you for your important work making the ecosystem more secure, for the benefit of 5.5 billion Internet users.
sim7c00 1y ago
just dont use latest... old oackages can be malicious, benign ones tho... they get malicious generally on 'latest'. not on old versions. maybe its better to disallow latest than use age as a metric.
dwoldrich 1y ago
I am an npm user. My reaction to these software supply chain attacks is to stop taking updates unless absolutely necessary for vulnerability mitigation or to selectively take performance or feature upgrades on a package-by-package basis. Obviously, that approach still opens me up to attacks based on when I choose to take updates that coincides with a malicious package release, but I feel like an extreme reluctance to upgrade will mostly keep me safe. To achieve my goal, would this approach work: - Pin all of my package.json versions (no prefacing versions with ~ or ^) - Routine installation of packages both on my local and on CI servers will be done using `npm ci` - `npm install <package_name> --save-exact/--save-dev` would be used only at the time of adding a package to package.json, followed by an `npm ci` - Rely on tooling like GitHub Dependabot and CodeQL to inform the team when a dependency should be updated for security reasons and then manually update only the dependency with the desired version using `npm install lodash@4.17.21 --save-exact`, for example EDIT: Thinking about this more, we would have to forbid deleting the package-lock.json and regenerating it with `npm install` and forbid the use of `npm update` so that package-lock.json would stay stable.
- sedatk 1y ago
  It's all good until the day comes that one dependency breaks compatibility and drops support for the version you have, and now you have days of dependency resolution work ahead of you because you've never bothered for years. Usually, incremental and timely upgrades reduce that kind of friction.
  - dwoldrich 1y ago
    Could that just be the cost of doing business though? I think of it like when a version of Node goes out of support and you have to upgrade a bunch of stuff and fix build scripts. It's always ends up being days of work upgrading dependencies and re-testing everything.
  - null_deref 1y ago
    In a case of a package breaking compatibility (^) won’t help as well.
  - 1y ago

238 points by ivanb 1y ago

If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.

anematode 1y ago
A lot of people will still use npm, so they'll be the canaries in the coal mine :) More seriously, automated scanners seem to do a good job already of finding malicious packages. It's a wonder that npm themselves haven't already deployed an automated countermeasure.
- vasachi 1y ago
  If only there was a high-ranking official at Microsoft, who could prioritize security[1]! /s [1] https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/ https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...
- deleted 1y ago
  [deleted]
- mcintyre1994 1y ago
  In the case of the chalk/debug etc hack, the first detection seemed to come from a CI build failure it caused: https://jdstaerk.substack.com/p/we-just-found-malicious-code-in-the https://jdstaerk.substack.com/p/we-just-found-malicious-code... > It started with a cryptic build failure in our CI/CD pipeline, which my colleague noticed > This seemingly minor error was the first sign of a sophisticated supply chain attack. We traced the failure to a small dependency, error-ex. Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3, which got published just a few minutes earlier.
  - DougBTX 1y ago
    > Our package-lock.json specified the stable version 1.3.2 or newer Is that possible? I thought the lock files restricted to a specific version with an integrity check hash. Is it possible that it would install a newer version which doesn't match the hash in the lock file? Do they just mean package.json here?
    - streptomycin 1y ago
      If they were for some reason doing `npm install` rather than `npm ci`, then `npm install` does update packages in the lock file. Personally I always found that confusing, and yarn/pnpm don't behave that way. I think most people do `npm ci` in CI, unless they are using CI to specifically test if `npm install` still works, which I guess maybe would be a good idea if you use npm since it doesn't like obeying the lock file.
      - Rockslide 1y ago
        How does this get repeated over and over, when it's simply not true? At least not anymore. npm install will only update the lockfile if you make changes to your package.json. Otherwise, it will install the versions from the lockfile.
        cluckindan 1y ago
        Are you 100% on that?
        Rockslide 1y ago
        Yes. As someone who's using npm install daily, and given the update cadence of npm packages, I would end up with dirty lock files very frequently if the parent statement were true. It just doesn't happen.
        mirashii 1y ago
        > How does this get repeated over and over, when it's simply not true? Well, for one, the behavior is somewhat insane. `npm install` with no additional arguments does update the lockfile if your package.json and your lockfile are out of sync with one another for any reason, and so to get a guarantee that it doesn't change your lockfile, you must do additional configuration or guarantee by some external mechanism that you don't ever have an out of date package.json and lock. For this reason alone, the advice of "just don't use npm install, use npm ci instead" is still extremely valid, you'd really like this to fail fast if you get out of sync. `npm install additional-package` also updates your lock file. Other package managers distinguish these two operations, with the one to add a new dependency being called "add" instead of "install". The docs add to the confusion. https://docs.npmjs.com/cli/v11/commands/npm-install#save https://docs.npmjs.com/cli/v11/commands/npm-install#save suggests that writing to package-lock.json is the default and you need to change configuration to disable it. The notion that it won't change your lock file if you're already in sync between package.json and package-lock.json is not actually spelled out clearly anywhere on the page. > At least not anymore. You've partially answered your own question here.
- kjok 1y ago
  > automated scanners seem to do a good job already of finding malicious packages. That's not true. This latest incident was detected by an individual researcher, just like many similar attacks in the past. Time and again, it's been people who flagged these issues, later reported to security startups, not automated tools. Don't fall for the PR spin. If automated scanning were truly effective, we'd see deployments across all major package registries. The reality is, these systems still miss what vigilant humans catch.
  - hobofan 1y ago
    > If automated scanning were truly effective, we'd see deployments across all major package registries. No we wouldn't. Most package registries are run by either bigcorps at a loss or by community maintainers (with bigcorps again sponsoring the infrastructure). And many of them barely go beyond the "CRUD" of package publishing due to lack of resources. The economic incentives of building up supply chain security tools into the package registries themselves are just not there.
    - kjok 1y ago
      You're right that registries are under-resourced. But, if automated malware scanning actually worked, we'd already see big tech partnering with package registries to run continuous, ecosystem-wide scanning and detection pipelines. However, that isn't happening. Instead, we see piecemeal efforts from Google with assurance artifacts (SLSA provenance, SBOMs, verifiable builds), Microsoft sponsoring OSS maintainers, Facebook donating to package registries. Google's initiatives stop short of claiming they can automatically detect malware. This distinction matters. Malware detection is, in the general case, an undecidable problem (think halting problem and Rice theorem). No amount of static or dynamic scanning can guarantee catching malicious logic in arbitrary code. At best, scanners detect known signatures, patterns, or anomalies. They can't prove absence of malicious behavior. So the reality is: if Google's assurance artifacts stop short of claiming automated malware detection is feasible, it's a stretch for anyone else to suggest registries could achieve it "if they just had more resources." The problem space itself is the blocker, not just lack of infra or resources.
singulasar 1y ago
Not really, app sec companies scan npm constantly for updated packages to check for malware. Many attacks get caught that way. e.g. the debug + chalk supply chain attack was caught like this: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
blamestross 1y ago
1) Checks and audits will still happen (if they are happening at all) 2) Real chances for owners to notice they have been compromised 3) Adopt early before that commons is fully tragedy-ed.
acdha 1y ago
Think about how the three major recent incidents were caught: not by individual users installing packages but by security companies running automated scans on new uploads flagging things for audits. This would work quite well in that model, and it’s cheap in many cases where there isn’t a burning need to install something which just came out.
- kjok 1y ago
  I think there's some confusion here. No automated scan was able to catch the attack. It was an individual who notified these startups.
  - acdha 1y ago
    Quite possibly - there have been several incidents recently and a number of researchers working together so it’s not clear exactly who found something first and it’s definitely not as simple to fix as tossing a tool in place. The CEO of socket.dev described an automated pipeline flagging new uploads for analysts, for example, which is good but not instantaneous: https://news.ycombinator.com/item?id=45257681 https://news.ycombinator.com/item?id=45257681 The Aikido team also appear to be suggesting they investigated a suspicious flag (apologies if I’m misreading their post), which again needs time for analysts to work: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com... My thought was simply that these were caught relatively quickly by security researchers rather than by compromised users reporting breaches. If you didn’t install updates with a relatively short period of time after they were published, the subsequent response would keep you safe. Obviously that’s not perfect and a sophisticated, patient attack like liblzma suffered would likely still be possible but there really does seem to be a value to having something like Debian’s unstable/stable divide where researchers and thrill-seekers would get everything ASAP but most people would give it some time to be tested. What I’d really like to see is a community model for funding that and especially supporting independent researchers.
- nikanj 1y ago
  Automated scans have detected 72251 out of the previous 3 supply-chain attacks
kibwen 1y ago
Also, if everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to broadly disseminate the fix for a compromise in the wild. The knife cuts both ways.
kaelwd 1y ago
The chalk+debug+error-ex maintainer probably would have noticed a few hours later when they got home and saw a bunch of "Successfully published" emails from npm that they didn't trigger.
djdjsjejb 1y ago
thats what npm is for, so they install it first. cannon fodders.

omnicognate 1y ago

Should have included the units in the name or required a choice of unit to be selected as part of the value. Sorry, just a bugbear of mine.

zokier 1y ago
Or just use ISO8601 standard notation (e.g. "P1D" for one day)
- 1oooqooq 1y ago
  or PT1400M or P0.5DT700M? oh, you can use commas too. and if you're still not thinking this is fun, here's a quote from Wikipedia "But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to Daylight saving time." just add a unit to your period parameters. sigh.
  - brewmarche 1y ago
    Maybe surprising for days (could also happen with minutes because of leap seconds technically :-) but for months and years this is more apparent due to month ends and leap years.
- johanyc 1y ago
  TIL ISO8601 also standardizes duration
fzeindl 1y ago
ISO8601 durations should be used, like PT3M.
- aa-jv 1y ago
  Should be easy, just add the ISO8601-duration package to your project .. /s
- mort96 1y ago
  Oh wow, never looked at ISO8601 durations before and I had no idea they were this ugly. Please, no, don't make me deal with ISO8601. I'd rather write a number of seconds or a format like 'X weeks' or 'Y hours Z minutes'x ISO8601 looks exclusively like a data interchange format

OskarS 1y ago

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking, so security isn’t as critical for us, stability is much more important). Does the JS ecosystem really move so fast that you can’t wait a month or two before updating your packages?

codemonkey-zeta 1y ago
I think the surface area for bugs in a C++ dependency is way bigger than a JS one. Pulling in a new node module is not going to segfault my app, for example.
progx 1y ago
Yes, but this is not only JS dependent, in PHP (composer) is the same. Normally old major or minor packages don't get an update, only the latest. E.g. 4.1.47 (no update), 4.2.1 (yes got update). So if the problem is in 4.1 you must "upgrade" to 4.2. With "perfect" semver, this shouldn't be a problem, cause 4.2 only add new features... but... back to reality, the world is not perfect.
ozim 1y ago
NPM packages follow semantic versioning so minor versions should be fine to auto update. (there is still an issue what for package maintainer might be minor not being minor for you - but let's stick to ideal world for that) I don't think people are having major versions updated every month, it is more really like 6 months or once a year. I guess the problem might be people think auto updating minor versions in CI/CD pipeline will keep them more secure as bug fixes should be in minor versions but in reality we see it is not the case and attackers use it to spread malware.
- otterley 1y ago
  > so minor versions should be fine to auto update The problem is that "should" assumes that point releases never introduce regressions (whether they be security, performance, or correctness). Unfortunately, history has shown that regressions can and do happen. The best practice for release engineering (CI/CD, if you will) is to assume the worst, test thoroughly, and release incrementally (include bake time). Delaying updates isn't just a backstop against security vulnerabilities; it's useful for letting the dust settle after an update of any kind that can adversely impact the application. The theory is that someone will find it before you, report it, and that a fix will be issued.

progx 1y ago

That solve not really the problem. A better (not perfect) solution: Every package should by AI analysed on an update before it is public available, to detect dangerous code and set a rating. In package.json should be a rating defined, when remote package is below that value it could be updated, if it is higher a warning should appear. But this will cost, but i hope, that companies like github, etc. will allow package-Repositories to use their services for free. Or we should find a way, to distribute this services to us (the users and devs) like a BOINC-Client.

jonkoops 1y ago
Ah, yes! The universal and uncheatable LLM! Surely nothing can go wrong.
- progx 1y ago
  As i wrote "not perfect". But better than anything else or nothing.
  - robertlagrant 1y ago
    The Politician's Syllogism[0] is instructive. [0] https://en.wikipedia.org/wiki/Politician's_syllogism https://en.wikipedia.org/wiki/Politician's_syllogism
    - progx 1y ago
      OK, we are here now on reddit or facebook? I thought we discuss here problems and possible solutions. My fault.
      - deleted 1y ago
        [deleted]
      - robertlagrant 1y ago
        I don't think "we should use AI to solve this" is a solution proposal.

gausswho 1y ago

'Delayed dependency updates' is a response to supply-side attacks in the JavaScript world, but it aptly describes how I have come to approach technology broadly. Large tech companies, as with most industry, have realized most people will pay with their privacy and data long before they'll pay with money. We live in a time of the Attention Currency, after all. But you don't need to be a canary to live a technology-enabled life. Much software that you pay with your privacy and data has free or cheap open-source alternatives that approach the same or higher quality. When you orient your way of consuming to 'eh, I can wait till the version that respects me is built', life becomes more enjoyable in myriad ways. I don't take this to absolute levels. I pay for fancy pants LLM's, currently. But I look forward to the day not too far away where I can get today's quality for libre in my homelab.

wallrat 1y ago

There are a few commercial products that allow you to do this also for other ecosystems (e.g. maven, nuget, pypi etc), including ours https://docs.bytesafe.dev/policies/delay-upstream/ https://docs.bytesafe.dev/policies/delay-upstream/ Good to see some OSS alternatives showing up!

_betty_ 1y ago

how about requiring some kind of interaction if they want to run an install script?

jsheard 1y ago
Pnpm already did that: https://github.com/pnpm/pnpm/releases/tag/v10.0.0 https://github.com/pnpm/pnpm/releases/tag/v10.0.0

the_mitsuhiko 1y ago

I think uv should get some credit for being an early supporter of this. They originally added it as a hidden way to create stable fixtures for their own tests, but it has become a pretty popular flag to use. This for instance will only install packages that are older than 14 days: uv sync --exclude-newer $(date -u -v-14d '+%Y-%m-%dT%H:%M:%SZ') It's great to see this kind of stuff being adopted in more places.

mcintyre1994 1y ago
Nice, but I think the config file is a much better implementation for protecting against supply chain attacks, particularly those targeting developers rather than runtime. You don’t want to rely on every developer passing a flag every time they install. This does suffer from the risk of using `npm install` instead of `pnpm install` though. It would also be nice to have this as a flag so you can use it on projects that haven't configured it though, I wonder if that could be added too.
- cap11235 1y ago
  You can put the uv setting in pyproject.toml or uv.toml.
  - mcintyre1994 1y ago
    Nice, supporting both definitely seems ideal.
  - fainpul 1y ago
    But then you have to hardcode a timestamp, since this is not gonna work in uv.toml: exclude-newer = $(date -uv -14d '+%Y-%m-%dT%H:%M:%SZ')
- ramses0 1y ago
  Just Minimum Version Selection in conjunction with "Minimum non-Vulnerable Version" (and this "--minAge") would do a lot, and effectively suss out a lot of poorly/casually maintained packages (eg: "finished" ones). https://research.swtch.com/vgo-mvs#upgrade_timing https://research.swtch.com/vgo-mvs#upgrade_timing MVS makes tons of sense that you shouldn't randomly uptake "new" packages that haven't been "certified" by package maintainers in their own dependencies. In the case of a vulnerable sub-dependency, you're effectively having to "do the work" to certify that PackageX is compatible with PackageY, and "--minAge" gives industry (and maintainers) time to scan before insta-pwning anyone who is unlucky that day.

keraf 1y ago

I might be naive but why isn't any package manager (npm, pnpm, bun, yarn, ...) pushing for a permission system, where packages have to define in the package.json what permission they would like to access? À la Deno but scoped to dependencies or like mobile apps do with their manifest. I know it would take time for packages to adopt this but it could be implemented as parameters when installing a new dependency, like `npm i ping --allow-net`. I wouldn't give a library like chalk access to I/O, processes or network.

IanCal 1y ago
I feel like that would require work from the language side, or at least runtimes. Is there a way of stopping code in one package from, say, hitting the network? You might be able to do this around install scripts, though disk writing is likely needed for all (but perhaps locations could be controlled).
- Filligree 1y ago
  We've seen a lot of stunningly incompetent attacks that nevertheless get to a lot of people. Yeah, it needs work from the language runtime, but I think even a hacky, leaky 'security' abstraction would be helpful, because the majority of malware developers probably aren't able to break out of a language-level sandbox, even if the language still allows you to do unsafe array access. Then we can iterate.
- ____tom____ 1y ago
  Java had support for something very like this, but no one used it, and they recently removed it. https://openjdk.org/jeps/486 https://openjdk.org/jeps/486 It's too bad, it would be useful in this situation

h4ch1 1y ago

https://github.com/oven-sh/bun/issues/22679 https://github.com/oven-sh/bun/issues/22679 There's an open discussion about adding something similar to bun as well^ minimumReleaseAge doesn't seem to be a bulletproof solution so there's still some research/testing to be done in this area

__MatrixMan__ 1y ago

Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to create juicy attack surface around the resolution of that name to some bits.

mirekrusin 1y ago
name + version are immutable, you can't republish packages in npm under existing version. you can only unpublish. content hash integrity is verified in lockfiles. the problem is with dependencies using semver ranges, especially wide ones like "debug": "*" initiatives like provenance statements [0] / code signing are also good complement to delayed dependency updates. also not running as default / whitelisting postinstall scripts is good default in pnpm. modifying (especially adding) keys in npmjs.org should be behind dedicated 2fa (as well as changing 2fa) [0] https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements
- __MatrixMan__ 1y ago
  Those are promises that npm intends to keep, but whether they do or not isn't something that you as a package user can verify. Plus there's also the possibility that the server you got those bits from was merely masquerading as npm. The only immutability that counts is immutability that you can verify, which brings us back to cryptographic hashes.
  - mirekrusin 1y ago
    ...which are already present in lockfiles, available in registry ie. https://registry.npmjs.org/debug https://registry.npmjs.org/debug etc. - it's not a problem.
frankdejonge 1y ago

bamboozled 1y ago

Can anyone tell me if yarn just as vulnerable as NPM? Isn't it the packages that are vulnerable and not the package manger software itself?

cluckindan 1y ago
No, the ”vulnerability” here is npm unilaterally allowing postinstall scripts, which are then used as an entry point for malware. Of course, the malware could just embed itself as an IIFE and get launched when the package is loaded, so disallowing postinstall is not really a security solution.
- bamboozled 1y ago
  Interesting, thanks, it contradicts what was said on another similar post.
- paulhodge 1y ago
  Pnpm 10.x also has a feature to disallow post-install scripts by default. When using Pnpm you have to specifically enable a dependency to let it run its post-install scripts. It's a great feature that should be the standard. Yes if someone compromises a package then they can also inject malicious code that will trigger at runtime. But the thing about the recent NPM supply chain attack - it happened really quickly. There was a chain reaction of packages that got compromised which lead to more authors getting compromised. And I think a big reason why it moved so quickly was because of post-install scripts. If the attack happened more slowly, then the community would have more time to react and block the compromised packages. So just slowing down an attack is valuable on its own.

chr15m 1y ago

The correct value for this setting is infinity seconds. Upgrades should be considered and deliberate, not automatic.

kibwen 1y ago
The downside of this approach is that this is how you create an ecosystem where legitimate security fixes never end up getting applied. There's no free lunch, you need to decide whether you're more concerned about vulnerabilities intentional backdoors (and thus never update anything automatically) or vulnerabilities from ordinary unintentional bugs (and thus have a mechanism for getting security updates automatically).
- chr15m 1y ago
  Yep. I'm calling it. The churn is more dangerous and fragile than the rot. Two alternatives: - The occasional alert from `npm audit` that you have to carefully, deliberately, and thoughtfully upgrade your way out of. - The shifting sands of 100s or 1000s of towering deps that change literally every time you `pnmp install`. The second one is the current situation and it is madness. There should be no package lock because package.json should be the package lock.
esafak 1y ago
No, it isn't. Upgrades should be routine, like exercising. With your approach it becomes increasingly difficult and eventually impossible to upgrade anything since it requires moving a mountain. An update a ̶d̶a̶y̶ week makes the tech debt go away.
- chr15m 1y ago
  The reason upgrades have become routine is because modern software is slop. We should strive for software to do one thing well (or at least be made up of modular parts that do one thing well) and prize backwards compatability, so that it does not require constant churn. The sane middle ground between "constant upgrades" and "never upgrade" is to upgrade when there is an actual vulnerability found in a dependency. Instead of churn for no reason, you update only with a good reason.

Ozzie_osman 1y ago

Does anyone understand why npm isn't adding these sorts of features?

deleted 1y ago
[deleted]
JoshuaEN 1y ago
There was an NPM RFC for this feature (though not as focused on supply chain attacks) in 2022, but the main response mirrored some of the other comments in here. "waiting a length of time doesn’t increase security, and if such a practice became common then it would just delay discovery of vulnerabilities until after that time anyways" https://github.com/npm/rfcs/issues/646#issuecomment-1282497113 https://github.com/npm/rfcs/issues/646#issuecomment-12824971...

tuananh 1y ago

in corp settings, you usually have a proxy registry. you can setup firewall there for this kind of things to filter out based on license, cve, release date, etc...

user1999919 1y ago

but what will we ever do without our: "developers are lazy, developers are dumb, left-pad degeneracy!"

NamlchakKhandro 1y ago

npm is now the tutorial filter. If I see someone using npm as a cli tool unironically...

tripplyons 1y ago

If I run: pnpm config set -g minimumReleaseAge 1440 Does that work as well? I can't tell if the global settings are the same as workspace settings, and it lets me set nonsense keys this way, so I'm not sure if there is a global equivalent.

lloydatkinson 1y ago

Why must this be in a workspace file which you may not even have if you aren't in a monorepo, why not in package.json? Anyway, it's progress.

calyhre 1y ago

Yarn just landed a similar feature too https://github.com/yarnpkg/berry/pull/6901 https://github.com/yarnpkg/berry/pull/6901

cluckindan 1y ago
And it supports excluding single versions! Looks like yarn is back on the menu.

deleted 1y ago

[deleted]

nicoburns 1y ago

I feel like the correct solution to these problems (across NPM and all similar package managers) is a web-of-trust audit system based on: - Reviewing the source code in the actual published package - Tooling that enable one to easily see a trusted diff between a package version and the previous version of that package - Built-in support in the package manager CLIs to only install packages that have a sufficient number of manual reviews from trusted sources (+ no / not too many negative reviews). With manual review required to bypass these checks. There are enough users of each package that such a system should not be too onerous on users once the infrastructure was in place.

mceachen 1y ago

npm-check-updates has a PR for --cooldown as well: https://github.com/raineorshine/npm-check-updates/pull/1547 https://github.com/raineorshine/npm-check-updates/pull/1547

kardianos 1y ago

It seems like the core problem is (1) NPM node_modules is so large usually, no one actually audit them and (2) the NPM churn is so great, no one audits them and (3) the design of NPM appears to think that automatically updating point or minor versions is actually good and desirable. Go is one of the few packing systems that got these right.

Flimm 1y ago

How is the age of a package calculated? If the publishing date of a package is obtained from the package's metadata defined by the package author, (just like Git commit dates are defined by the Git committer), then that would defeat the purpose of this new feature. The whole purpose of this feature is to protect from malicious or compromised package authors. Instead, it is necessary to query the package registry, trusting the package registry for the age of the package, rather than the package author. I presume this is how it works.

mnahkies 1y ago
Eh we got confused implementing this today. Basically we severed connection to the public npm registry completely earlier in the week whilst this worm plays out. Unfortunately there wasn't a way to do this without taking our cached "good" public packages down as well, so we later replicated the good cached packages into a new standalone private registry to be the new upstream. The bit that was not obvious in the moment but self evident once we realised is that the registry we're using took the copy time as the publish time, and therefore our new 2 week delay is rejecting the copied packages... So sample size of one, but the registry we're using is definitely using upload time not any metadata in the packages themselves. Good to know the filtering is working.
- Flimm 1y ago
  Thank you for the explanation. And thank you for your important work making the ecosystem more secure, for the benefit of 5.5 billion Internet users.

sim7c00 1y ago

just dont use latest... old oackages can be malicious, benign ones tho... they get malicious generally on 'latest'. not on old versions. maybe its better to disallow latest than use age as a metric.

dwoldrich 1y ago

I am an npm user. My reaction to these software supply chain attacks is to stop taking updates unless absolutely necessary for vulnerability mitigation or to selectively take performance or feature upgrades on a package-by-package basis. Obviously, that approach still opens me up to attacks based on when I choose to take updates that coincides with a malicious package release, but I feel like an extreme reluctance to upgrade will mostly keep me safe. To achieve my goal, would this approach work: - Pin all of my package.json versions (no prefacing versions with ~ or ^) - Routine installation of packages both on my local and on CI servers will be done using `npm ci` - `npm install <package_name> --save-exact/--save-dev` would be used only at the time of adding a package to package.json, followed by an `npm ci` - Rely on tooling like GitHub Dependabot and CodeQL to inform the team when a dependency should be updated for security reasons and then manually update only the dependency with the desired version using `npm install lodash@4.17.21 --save-exact`, for example EDIT: Thinking about this more, we would have to forbid deleting the package-lock.json and regenerating it with `npm install` and forbid the use of `npm update` so that package-lock.json would stay stable.

sedatk 1y ago
It's all good until the day comes that one dependency breaks compatibility and drops support for the version you have, and now you have days of dependency resolution work ahead of you because you've never bothered for years. Usually, incremental and timely upgrades reduce that kind of friction.
- dwoldrich 1y ago
  Could that just be the cost of doing business though? I think of it like when a version of Node goes out of support and you have to upgrade a bunch of stuff and fix build scripts. It's always ends up being days of work upgrading dependencies and re-testing everything.
- null_deref 1y ago
  In a case of a package breaking compatibility (^) won’t help as well.
- 1y ago