Correct, for CI&#x2F;CD systems that want to push releases.

Apparently it&#x27;s possible to create access tokens that bypass 2FA. Might&#x27;ve been this.<a href="https:&#x2F;&#x2F;docs.npmjs.com&#x2F;creating-and-viewing-access-tokens" rel="nofollow">https:&#x2F;&#x2F;docs.npmjs.com&#x2F;creating-and-viewing-access-tokens</a>

&gt; Both versions were published using the compromised npm credentials of a lead axios maintainer, bypassing the project&#x27;s normal GitHub Actions CI&#x2F;CD pipeline.Doesn’t npm mandate 2FA as of some time last year? How was that bypassed?

Incident tracking:<a href="https:&#x2F;&#x2F;github.com&#x2F;axios&#x2F;axios&#x2F;issues&#x2F;10604" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;axios&#x2F;axios&#x2F;issues&#x2F;10604</a>

Other languages have package managers (perl) and there are package managers in existence that are not so vulnerable to this issue. IMO, it stems from one place: Transitive dependencies and general opaqueness of the issue.In package managers like pacman, apt, apk,... it&#x27;s easier to catch such issue. They do have postinstall scripts, but it&#x27;s part of the submission to the repo, not part of the project. Whatever comes from the project is hashed, and that hash is also visible as part of the submission. That makes it a bit difficult to sneak something. You don&#x27;t push a change, they pull yours.

Log4Shell was hardly a supply-chain attack - just a latent bug in a widely-used library. That can happen anywhere.Maven to this day represents my ideal of package distribution. Immutable versions save so much trouble and I really don&#x27;t understand why, in the age of left-pad, other people looked at that and said, &quot;nah, I&#x27;m good with this.&quot;

Come on dude. The issue is the frequency and magnitude of these attacks. Log4Shell was also not a supply chain attack.I looked at the Rust one for example, which is literally just a malicious crate someone uploaded with a similar name as a popular one:&gt; The crate had less than 500 downloads since its first release on 2022-03-25, and no crates on the crates.io registry depended on it.Compared to Axios, which gets 83 million downloads and was directly compromised.What an extremely disingenuous argument lol

Because no other language has ever had supply chain attacks ever, in history. Nope.<a href="https:&#x2F;&#x2F;blog.rust-lang.org&#x2F;2022&#x2F;05&#x2F;10&#x2F;malicious-crate-rustdecimal&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.rust-lang.org&#x2F;2022&#x2F;05&#x2F;10&#x2F;malicious-crate-rustde...</a><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Log4Shell" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Log4Shell</a><a href="https:&#x2F;&#x2F;blog.pypi.org&#x2F;posts&#x2F;2024-12-11-ultralytics-attack-analysis&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.pypi.org&#x2F;posts&#x2F;2024-12-11-ultralytics-attack-an...</a><a href="https:&#x2F;&#x2F;about.gitlab.com&#x2F;blog&#x2F;gitlab-catches-mongodb-go-module-supply-chain-attack&#x2F;" rel="nofollow">https:&#x2F;&#x2F;about.gitlab.com&#x2F;blog&#x2F;gitlab-catches-mongodb-go-modu...</a><a href="https:&#x2F;&#x2F;www.reversinglabs.com&#x2F;blog&#x2F;packagist-php-repo-supply-chain-threat-what-you-need-to-know" rel="nofollow">https:&#x2F;&#x2F;www.reversinglabs.com&#x2F;blog&#x2F;packagist-php-repo-supply...</a>

It&#x27;s reasons like this why I refuse to download Node or use anything NPM. Thankfully other languages are better anyways.

It’s only a losing strategy if you assume everyone universally adopts the slow strategy, and no research teams spot it in the interim. For things with large splash radius, that’s unrealistic, so defenders have an information advantage.Makes actual security patches tougher to roll out though - you need to be vigilant to bypass the slowdown when you’re actually fixing a critical flaw. But nobody said this would be easy!

but wouldn&#x27;t it work in this case? sure if a package was compromised for months&#x2F;years it wouldn&#x27;t save youbut tell dependabot to delay a week, you&#x27;d sleep easy from this nonesense

Slow Russian roulette is still a losing strategy

Should increase the delay to dependency updates.

NPM only gained minimum package age in February of this year, and still doesn&#x27;t support package exclusions for internal packages.<a href="https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;cli&#x2F;pull&#x2F;8965" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;cli&#x2F;pull&#x2F;8965</a><a href="https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;cli&#x2F;issues&#x2F;8994" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;cli&#x2F;issues&#x2F;8994</a>Its good that that they finally got there but....I would be avoiding npm itself on principle in the JS ecosystem. Use a package manager that has a history of actually caring about these issues in a timely manner.

PNPM makes you approve postinstall scripts instead of running them by default, which helps a lot. Whenever I see a prompt to run a postinstall script, unless I know the package normally has one &amp; what it does, I go look it up before approving it.(Of course I could still get bitten if one of the packages I trust has its postinstall script replaced.)

&gt; it’s got me nervous to use Python or Node.js these daysMy feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment.I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.

More like the Trivy incident (which led to the compromise of LiteLLM).

How much do you want to bet me that the credential was stolen during the previous LiteLLM incident? At what point are we going to have to stop using these package managers because it&#x27;s not secure? I&#x27;ve got to admit, it&#x27;s got me nervous to use Python or Node.js these days, but it&#x27;s really a universal problem.

Also it has interceptors, which allow you to build easily reusable pieces of code - loggers, oauth, retriers, execution time trackers etc.These are so much better than the interface fetch offers you, unfortunately.

Before that we had node-fetch. If you already use a dependency why not one that&#x27;s pretty much what will come natively to every JS runtime soon.

Right. Though I would&#x27;ve used the built in xhr then. Not going to install a dep just to make http calls.

&gt; nearly every other project uses it for some reason instead of fetch (I never understood why).Fetch wasn&#x27;t added to Node.js as a core package until version 18, and wasn&#x27;t considered stable until version 21. Axios has been around much longer and was made part of popular frameworks and tutorials, which helps continue to propagate it&#x27;s usage.

The prompt would be to approve the new malicious package (plain-crypto-js)&#x27;s scripts, too, which could tip users off that something was fishy. If they were used to approving one for axios and the attackers had just overwrote axios&#x27;s own instead of making a new package, it would probably catch people out.

Can&#x27;t speak for other devs but I like to read postinstall scripts or at least put them through an LLM if they&#x27;re too hard to grok.It&#x27;s also a little context dependent, for example if I was using Axios and I see a prompt to run the plain-crypto-js postinstall script, alarm bells would instantly ring, which would at least make me look up the changelog to see why this is happening.In most cases I don&#x27;t even let them run unless something breaks&#x2F;doesn&#x27;t work as expected.

Assuming axios didn&#x27;t have a postinstall script before, it wouldn&#x27;t have been approved for a previous version. If you ignore it, you ignore it, but postinstall scripts are relatively rare in npm deps, so it would seem a bit out of place when the warning pops up.

&gt; Good news for pnpm&#x2F;bun users who have to manually approve postinstall scripts.Would they not have approved it for earlier versions? But also wouldn&#x27;t the chance of addition automatic approval be high (for such a widely used project)?

&gt; I can&#x27;t even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why).You can remember this answer for every time you ask same question again:&quot;Coz whatever else&#x2F;builtin was before was annoying enough for common use cases&quot;

&gt;(I never understood why).Because axios existed before the builtin fetch, and so there&#x27;s a lot of stackoverflow answers explaining how to use fetch, and the llm models are trained on that, so they will write axios requests instead of fetch

There was never the business value. But now remember this axios case and use it as ammo for the next issue. Just don’t abuse it

&gt; (I never understood why).I spent two years trying to get it out of a project that began long after Axios had become redundant but it&#x27;s very hard to go back and challenge decisions like this because every business priority is aligned against this kind of work.I expect libraries built on top of fetch will be the next to be compromised, because why would you use fetch without an arbitrary layer of syntactic sugar...

I can&#x27;t even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why).Also from the report:&gt; Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only purpose is to run a postinstall script that deploys a cross-platform remote access trojan (RAT)Good news for pnpm&#x2F;bun users who have to manually approve postinstall scripts.

&gt; Has anyone tested general purpose malware detection on supply chains ? Like clamscanYou could use Trivy! &#x2F;s

I second this question. I usually scan our containers with snyk and guarddog, and have wondered about guarddog in particular because it adds so much build time.

thanks for highlighting that i will take a look and see if there&#x27;s similar archive for the other vulnerabilities as well .If i can make it work with clamscan &amp; MS Defender i&#x27;ll run a scan and try to report back

the primitive clamscan experiment worked! it detected Txt.Trojan.TeamPCP-10059839-1 from the .tar.gz archive. I&#x27;ll continue testing to see if it&#x27;s viable<pre><code> # apk add clamav-scanner freshclam
 # freshclam
 # curl -LO https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20260325073027&#x2F;https:&#x2F;&#x2F;files.pythonhosted.org&#x2F;packages&#x2F;f6&#x2F;2c&#x2F;731b614e6cee0bca1e010a36fd381fba69ee836fe3cb6753ba23ef2b9601&#x2F;litellm-1.82.8.tar.gz

 # clamscan litellm-1.82.8.tar.gz
 Loading: 6s, ETA: 0s [========================&gt;] 3.63M&#x2F;3.63M sigs
 Compiling: 2s, ETA: 0s [========================&gt;] 41&#x2F;41 tasks

 &#x2F;root&#x2F;supply-chain-scanner&#x2F;pkg&#x2F;litellm-1.82.8.tar.gz: Txt.Trojan.TeamPCP-10059839-1 FOUND

 ----------- SCAN SUMMARY -----------
 Known viruses: 3627757
 Engine version: 1.4.4
 Scanned directories: 0
 Scanned files: 1
 Infected files: 1
 Data scanned: 94.98 MB
 Data read: 16.59 MB (ratio 5.72:1)
 Time: 50.057 sec (0 m 50 s)
 Start Date: 2026:04:01 19:57:23
 End Date: 2026:04:01 19:58:13</code></pre>

&gt; tried to test the LiteLLM hack but the affected packages had been pulledHey, I have been part of the archival effect&#x2F;Litellm issue thread. I think I have stored them in archive.org for preservation purposes<a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20260325073027&#x2F;https:&#x2F;&#x2F;files.pythonhosted.org&#x2F;packages&#x2F;f6&#x2F;2c&#x2F;731b614e6cee0bca1e010a36fd381fba69ee836fe3cb6753ba23ef2b9601&#x2F;litellm-1.82.8.tar.gz" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20260325073027&#x2F;https:&#x2F;&#x2F;files.pyt...</a>(I have also made an archive of the github issue with all the comments manually till a certain point at <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20260325054202&#x2F;https:&#x2F;&#x2F;serjaimelannister.github.io&#x2F;litellm-comments&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20260325054202&#x2F;https:&#x2F;&#x2F;serjaimel...</a>)

Has anyone tested general purpose malware detection on supply chains ? Like clamscan . I tried to test the LiteLLM hack but the affected packages had been pulled. Windows Defender AV has an inference based detector that may work when signatures have not yet been published

and for yarn berry<pre><code> ~&#x2F;.yarnrc.yml
 npmMinimalAgeGate: &quot;3d&quot;</code></pre>

They’re usually picked up by scanners by then.

that&#x27;s why people are telling others to use 7 days but using 8 days themselves :)

What do you base that on? Threat researchers (and their automated agents) will still keep analyzing new releases as soon as they’re published.

I suspect most packages will keep a mix of people at 7 days and those with no limit. That being said, adding jitter by default would be good to these features.

&gt; If everyone avoids using packages released within the last 7 daysWhich will never even come close to happening, unless npm decides to make it the default, which they won&#x27;t.

Most people won’t.7 days gives ample time for security scanning, too.

This highly depends on the detection mechanism.

If everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.

timeoutMs is shorter ;)You guys can&#x27;t appreciate a bad joke

Yes!! This goes for any time you declare a time interval variable. The number of times I&#x27;ve seen code changes with a comment like &quot;Turns out the delay arg to function foo is in milliseconds, not seconds&quot;.

About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.

OP should be glad a new time unit wasn&#x27;t invented

To me it sounds safer to have different big infra providers with different delays, otherwise you still hit everyone at the same time when something does inevitably go undetected.And the chances of staying undetected are higher if nobody is installing until the delay time ellapses.It&#x27;s the same as not scheduling all cronjobs to midnight.

&gt; (Side note, it&#x27;s wild that npm, bun, and pnpm have all decided to use different time units for this configuration.)First day with javascript?

Silly portmanteau of &quot;bun&quot; and &quot;config&quot;

Props to uv for actually using the correct config path jfc what is “bunfig”

Pnpm did this first but I’m glad to see all the others follow suitFor anyone wondering, you need to be on npm &gt;= 11.10.0 in order to use it. It just became available Feb 11 2026<a href="https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;cli&#x2F;releases&#x2F;tag&#x2F;v11.10.0" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;cli&#x2F;releases&#x2F;tag&#x2F;v11.10.0</a>

<a href="https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;concepts&#x2F;resolution&#x2F;#dependency-cooldowns" rel="nofollow">https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;concepts&#x2F;resolution&#x2F;#dependency-co...</a>&gt; Define a dependency cooldown by specifying a duration instead of an absolute value. Either a &quot;friendly&quot; duration (e.g., 24 hours, 1 week, 30 days) or an ISO 8601 duration (e.g., PT24H, P7D, P30D) can be used.

The config for uv won&#x27;t work. uv only supports a full timestamp for this config, and no rolling window day option afaik. Am I crazy or is this llm slop?

Sandboxing by to default world be really nice. One of the things I really appreciate about Claude Code is its permissions model

Run npm&#x2F;pnpm&#x2F;bun&#x2F;uv inside a sandbox.There is no reason to let random packages have full access to your machine

ok, it works, only the list function shows it as null...

I think the npm doesn&#x27;t support end of line comments, so<pre><code> ~&#x2F;.npmrc
 min-release-age=7 # days 
</code></pre>
actually doesn&#x27;t set it at all, please edit your comment.EDIT:
Actually maybe it does? But it&#x27;s weird because`npm config list -l` shows: `min-release-age = null` with, and without the comment. so who knows ¯\_(ツ)_&#x2F;¯

Good luck with any `npm audit` in a pipeline. Sometimes you have to pull the latest release because the previous one had a critical vulnerability.

Out of the frying pan and into the frier.....

Exactly what I thought too when I read this...Urgent fix, patch released, invisible to dev team cause they put in a 7 day wait. Now our app is vulnerable for up to 7 days longer than needed (assuming daily deploys. If less often, pad accordingly). Not a great excuse as to why the company shipped an &quot;updated&quot; version of the app with a standing CVE in it. &quot;Sorry we were blinded to the critical fix because set an arbitrary local setting to ignore updates until they are 7 days old&quot;. I wouldn&#x27;t fire people over that, but we&#x27;d definitely be doing some internal training.

Not really an issue though right because virtually none of these have lasted more than 1-2 days before being discovered?

At least with pnpm, you can specify minimumReleaseAgeExclude, temporarily until the time passes. I imagine the other package managers have similar options.[1]: <a href="https:&#x2F;&#x2F;pnpm.io&#x2F;settings#minimumreleaseageexclude" rel="nofollow">https:&#x2F;&#x2F;pnpm.io&#x2F;settings#minimumreleaseageexclude</a>

I haven&#x27;t checked, but it would be surprising that the min-release-age applies to npm audit and equivalent commands

The packages that are actually compromised are yanked, but I assume you&#x27;re talking about a scenario more like log4shell. In that case, you can just disable the config to install the update, then re-enable in 7 days. Given that compromised packages are uploaded all the time and zero-day vulnerabilities are comparatively less common, I&#x27;d say it&#x27;s the right call.

min release age to 7 days about patch releases exposes you to the other side of the coin, you have an open 7 days window on zero-day exploits that might be fixed in a security release

At least with npm, you can have a .npmrc per-repo

Fairly sure every single one has a repo level config that you can add these settings to. Others have pointed out the pnpm and npm, and I bunfig can also be repo level.

Is there a way to do that per repo for these tools ? We all know how user sided configuration works for users (they usually clean it whenever it goes against what they want to do instead of wondering why it blocks their changes :))

If everyone or a majority of people sets these options, then I think issues will simply be discovered later. So if other people run into them first, better for us, because then the issues have a chance of being fixed once our acceptable package&#x2F;version age is reached.

That would likely mean same amount of people get the vulnerability, just 7 days later.

It&#x27;s wild that none of these are set by default.I know 90% of people I&#x27;ve worked with will never know these options exist.

Make sure you&#x27;re on version 11.10 or later?

lol with mise I used a fourth time unit: <a href="https:&#x2F;&#x2F;mise.jdx.dev&#x2F;configuration&#x2F;settings.html#install_before" rel="nofollow">https:&#x2F;&#x2F;mise.jdx.dev&#x2F;configuration&#x2F;settings.html#install_bef...</a>

Weird. The config also appears to default to `false`<a href="https:&#x2F;&#x2F;pnpm.io&#x2F;settings#ignorescripts" rel="nofollow">https:&#x2F;&#x2F;pnpm.io&#x2F;settings#ignorescripts</a>

Where in the pnpm documentation does it say that it ignores scripts by default?From <a href="https:&#x2F;&#x2F;pnpm.io&#x2F;cli&#x2F;install#--ignore-scripts" rel="nofollow">https:&#x2F;&#x2F;pnpm.io&#x2F;cli&#x2F;install#--ignore-scripts</a>:&gt; Default: *false*

pnpm since v10.19.0 allows excluding specific dependencies from minReleaseAge by version.

And when you actually need a super hot fix for a 0-day, you will need to revert this and keep it that way for some time to then go back to minimum age.While this works, we stillneed a permanent solution which requires a sort of vetting process, rather than blindly letting everything through.

uv supports it, <a href="https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;reference&#x2F;settings&#x2F;#exclude-newer" rel="nofollow">https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;reference&#x2F;settings&#x2F;#exclude-newer</a>

Everyone has forgotten standard ISO 8601 durations and invented their own syntax.

mise has an option as well (note the caveats though):<a href="https:&#x2F;&#x2F;mise.jdx.dev&#x2F;configuration&#x2F;settings.html#install_before" rel="nofollow">https:&#x2F;&#x2F;mise.jdx.dev&#x2F;configuration&#x2F;settings.html#install_bef...</a>And homebrew has discussed it, kinda sorta:<a href="https:&#x2F;&#x2F;github.com&#x2F;Homebrew&#x2F;brew&#x2F;issues&#x2F;21129" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Homebrew&#x2F;brew&#x2F;issues&#x2F;21129</a>

&gt; PSA: npm&#x2F;bun&#x2F;pnpm&#x2F;uv now all support setting a minimum release age for packages.The solution is not moar toolz. That&#x27;s the problem—this crazy mindset that the problems endemic to bad tooling have a solution in the form of complementing them with another layer, rather than fewer.Git and every sane SCM already allow you to manage your source tree without jumping through a bunch of hoops to go along with wacky overlay version control systems like the one that the npmjs.com crew designed, centering around package.json as a way to do an end-run around Git. You don&#x27;t need to install and deploy anything containing never-before-seen updates just because the NodeJS influencer–developers say that lockfiles are the Right Way to do things. (It&#x27;s not.)Opting in to being vulnerable to supply chain attacks is a choice.&lt;<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46006471">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46006471</a>&gt;&lt;<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46360308">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46360308</a>&gt;

`~&#x2F;Library&#x2F;Preferences&#x2F;pnpm&#x2F;rc` reads like is MacOS.. I&#x27;m using Linux...?

What version of npm has this? This isn&#x27;t working for me on npm 11.6.2 (Node v24):<pre><code> ~&#x2F;.npmrc
 min-release-age=7 # days</code></pre>

PSA: npm&#x2F;bun&#x2F;pnpm&#x2F;uv now all support setting a minimum release age for packages.I also have `ignore-scripts=true` in my ~&#x2F;.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default.Here&#x27;s how to set global configs to set min release age to 7 days:<pre><code> ~&#x2F;.config&#x2F;uv&#x2F;uv.toml
 exclude-newer = &quot;7 days&quot;

 ~&#x2F;.npmrc
 min-release-age=7 # days
 ignore-scripts=true
 
 ~&#x2F;Library&#x2F;Preferences&#x2F;pnpm&#x2F;rc
 minimum-release-age=10080 # minutes
 
 ~&#x2F;.bunfig.toml
 [install]
 minimumReleaseAge = 604800 # seconds
</code></pre>
(Side note, it&#x27;s wild that npm, bun, and pnpm have all decided to use different time units for this configuration.)If you&#x27;re developing with LLM agents, you should also update your AGENTS.md&#x2F;CLAUDE.md file with some guidance on how to handle failures stemming from this config as they will cause the agent to unproductively spin its wheels.

But also have a regular review of your dependencies to update them when necessary, because as bad as compromised packages may be things do have vulnerabilities occasionally, and upgrading things that are a long way out-of-date can be quite hard.

Pin your dependencies folks! Audit and don&#x27;t upgrade to every brand new version.

some post processors have chains to execution (ex: lombok)

AFAIK maven doesn’t support post install logic like npm does. You have to explicitly optin with build plugins. It doesn’t let any arbitrary dependency run code on your machine.

unfortunately not, but there is work being done to support overlays properly I think?

Do you have a recommendation for something like bwrap but for macos?  I&#x27;ve been trying to use bwrap more on my servers when I remember.

It&#x27;s so your private key is not stolen, but you&#x27;re right passphrase protected keys win anyway. I use hardware keys so this isn&#x27;t a problem for me to begin with.

&gt; SSH is forwarded via socketMaybe I misunderstood this point. But the ssh socket also gives access to your private keys, so I see no security gain in that point. Better to have a password protected key.

node is also sandboxed within bwrap I have sandbox -p node if I have to give node access to other folders, I also have sandbox -m to define custom mountpoints if necessary and UNSAFE=1 as a last resort which just runs unsandboxed.

This only works for post-install script attacks. When the package is compromised, just running require somewhere in your code will be enough, and that runs with node&#x2F;java&#x2F;python and no bwrap.

This looks nice but I wouldn&#x27;t trust a very fresh tool to do security correctly.As a higher-level alternative to bwrap, I sometimes use `flatpak run --filesystem=$PWD --command=bash org.freedesktop.Platform`. This is kind of an abuse of flatpaks but works just fine to make a sandbox. And unlike bwrap, it has sane defaults (no extra permissions, not even network, though it does allow xdg-desktop-portal).

Check also <a href="https:&#x2F;&#x2F;github.com&#x2F;wrr&#x2F;drop" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wrr&#x2F;drop</a> which is a higher-level tool than bwrap. It allows you to make such isolated sandboxes with minimal configuration.

I wrote a Docker-based sandbox [1] for myself last year to control the blast radius of such malicious packages.<a href="https:&#x2F;&#x2F;github.com&#x2F;ashishb&#x2F;amazing-sandbox" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ashishb&#x2F;amazing-sandbox</a>

bwrap is as secure as you want it to be which I think is the primary advantage over anything else.

I think firejail is a much more flexible security sandbox than bwrap. It also comes with pre-defined profiles

can&#x27;t really share a file here, feel free to email me

I like the idea of bubblewrap, but my pain point is that it is work to set it up correctly with bind mounts and forwarding necessary environment variables to make the program actually work usefully. Could you share your pip bwrap configuration? It sounds useful.

I recommend everyone to use bwrap if you&#x27;re on linux and alias all package managers &#x2F; anything that has post build logic with it.I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add).This limits the blast radius to your CWD and package manager caches and often won&#x27;t even work since the malware usually expects some things to be available which are not in a permissionless sandbox.You can think of it as running a docker container, but without the requirement of having to have an image. It is the same thing flatpak is based on.As for server deployments, container hardening is your friend. Most supply chain attacks target build scripts so as long as you treat your CI&#x2F;CD as an untrusted environment you should be good - there&#x27;s quite a few resources on this so won&#x27;t go into detail.Bonus points: use the same sandbox for AI.Stay safe out there.

Yeah, I am looking at that on the use end. It sounds like on the python side this type of thing will be more standard (uv now and soon pip supported with version date requirements). I think time is a big missing element in many security in depth decisions. It can be time until you adopt like use no package newer than xx days or time it takes to deploy etc etc. Unfortunately the ecosystem is getting really diverse and that means ever more sophisticated attacks so we may need to do things that are annoying just to survive.

Why not just release escrow?  If I try to push a new release version another developer or developers have to agree to that release.  In larger projects you would expect the release to be coordinated or scheduled anyways.  Effectively we&#x27;re just moving &quot;version pinning&quot; or &quot;version delay&quot; one layer up the release chain.

Pinning, escrowing, and trailing all help, but I&#x27;m not sure &quot;this step will be eliminated&quot; is inevitable.Package manager ecosystems are highly centralized. npm.org could require MFA (or rate limit, or email verification, or whatever) and most packagers would gripe but go along with this. A minority would look for npm competitors that didn&#x27;t have this requirement, and another minority would hack&#x2F;automate MFA and remove the added security, but the majority of folks would benefit from a centralized requirement of this sort.

Hi, security here. We&#x27;ve tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated.A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.

This may not be popular, but is there a place for required human actions or just timed actions to slow down things like this? For instance, maybe a GH action to deploy requires a final human click and to change that to cli has a 3 day cooling period with mandatory security emails sent out. Similarly, you switch to read only for 6 hrs after an email change. There are holes in these ideas but the basic concept is to treat security more like physical security, your goal isn&#x27;t always to 100% block but instead to slow an attacker for xxx minutes to give the rest of the team time to figure out what is going on.

It does not _need_ it, that’s the thing. It has become a custom to import a dependency for a lot of things. Especially for JavaScript.

Min release age might just postpone vulnerability to be applied few days later in non trivial cases like this. More I think about it, Odin lang approach of no package manager makes senses. But, for that approach won&#x27;t work for Javascript as it needs npm package even for trivial things. Even vendoring approach like golang won&#x27;t work with Javascript with the amount of churn and dependencies.

Min release age sucks, but we’ve been here before. Email attachments used to just run wild too, then everyone added quarantine delays and file blocking and other frictions... and it eventually kinda&#x2F;sorta worked. This does feel worse, though, with fewer chokepoints and execution as a natural part of the expectation.Edit: bottom line is installs are gonna get SOOO much more complicated. You can already see the solution surface... Cooling periods, maintainer profiling, sandbox detonation, lockfile diffing, weird publish path checks. All adds up to one giant PITA for fast easy dev.

Please can we just have a 2FA step on publishing? Do we really need a release to be entirely and fully automated?It won&#x27;t stop all attacks but definitely would stop some of these

Bit ridiculous to dismiss the most popular programming languages packaging repo as silly toys.

This sounds like satire but isn&#x27;t - I just make sure the nodejs&#x2F;npm packages don&#x27;t exist on my system. I&#x27;ve yet to find a crucial piece of software that requires it. As much as I love that cute utility that turns maps into ascii art, it&#x27;s not exactly sqlite in terms of usefulness.

The problem is that package managers are a distraction. You have to sandbox everything or else it doesn&#x27;t work. These attacks use post-install hooks for convenience but nothing would have stopped them patching axios itself and just waiting for devs to run the app on their local workstation. So you end up needing to develop in a fully sandboxed environment.

What are you using that utilizes Apple containers?

We run everything NPM related inside Apple containers, and are looking to do the same with Python and Rust soon. Bwrap on Linux does the same.I like to think of it like working with dangerous chemicals in the lab. Back in the days, people were sloppy and eventually got cancer. Then dangers were recognized and PPE was developed and became a requirement.We are now at the stage in software development where we are beginning to recognizing the hazards and developing + mandating use of proper PPE.A couple of years ago, pip started refusing to install packages outside of a virtualenv. I&#x27;m guessing&#x2F;hoping package managers will start to have an opt-in flag you can set in a system-wide config file, such that they refuse to run outside of a sandbox.

While it&#x27;s not perfect, pinning specific versions and managing all updates directly has been a solid solution for my team. Things can of course still slip through, but we&#x27;re never vulnerable to these just because there was a new package release and we opted into it by default.Updating packages takes longer, but we try to keep packages to a minimum so it ends up not being that big deal.

Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in?It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.

I was thinking about this as a bull case for human developers. Seems if you&#x27;re worried enough to do this you&#x27;re not going to have LLMs write the new code.

You could include a line like &quot;please don&#x27;t include any malware&quot;.

If it becomes a thing, it&#x27;s just a matter of time for a new class of attacks on LLM that are blindly trusted with rewriting existing libs.

Eventually you will want to update it, every update is a risk.

Even better would be to not use so many libs. Most use cases will do fine with native `fetch`.

Large companies already maintain a clone of their packages. Very large ones actually bundle their own build system (Google Bazil, AWS Brazil). If you want to update a package, you have to fetch the sources and update the internal repository. It slows down the opportunities for a supply chain attack down to a crawl.

Once you fork it, you are then on the hook for forking every future update and security patch. You can automate a lot of the testing, but its still adding an extra failure point that you are now responsible for.And if you pin it, then when you inevitably get a CVE for an old version, the upgrade path is harder and more time consuming. And that&#x27;s when the security teams come knocking to pass their audit.

Supply chain attacks are so scary that I think most companies are going to use agents to hard fork their own versions of a lot of these core libraries instead. It wasn’t practical before. It’s definitely much more doable today.

There are definitely levels to this. Yes I think it can be caught by automated scanners in theory. Either commit by commit scanning and reproducible builds or fuzzing and getting the behavioral differences between versions

The ones you hear about are caught quickly, I’m more worried about the non obvious ones. So far none of these have been as simple as changing a true to a false and bypassing all auth for all products or something, and would that be caught by an automated scanner?

Hence why you source data from multiple vendors I&#x27;d say. Rather than putting all eggs in one basket

Sounds great until trivy images get compromised, like last week.

There are so many scanners these days these things get caught pretty quick. I think we need either npm or someone else to have a registry that only lets through packages that pass these scanners. Can even do the virustotal thing of aggregating reports by multiple scanners. NPM publishes attestation for trusted build environments. Google has oss-rebuild.All it takes is an `npm config set` to switch registries anyways. The hard part is having a central party that is able to convince all the various security companies to collaborate rather than having dozens of different registries each from each company.Rather than just a hard-coded delay, I think having policies on what checks must pass first makes sense with overrides for when CVEs show up.(WIP)

Linux distros and BSD ports did that since the 90&#x27;s. When Linux distros had barely a PM or just tarballs, Infomagic sold 4 CD full of libre software. When I had no internet at home, back in the day I bought 3 DVD&#x27;s of Debian Sarge for 20 euros, about $20. A bargain, it was the price of a hard-cover best seller book.GB&#x27;s of libre software, graphical install, 2.6 kernel, KDE3 desktop, very light on my Athlon 2000 with 256MB of RAM. It was incredible compared to what you got with Windows XP and 120 Euro per seat. Nonfree software and almost empty.And, well, if for instance I could get read only, ~16TB durable USB drive with tons of Guix packages offline (in a two yearly basis with stable releases) for $200 I would buy them in the spot.You would say that $200 for a distro it&#x27;s expensive, but for what it provides, if you are only interested in libre gaming and tools, they amount you save can be huge. I&#x27;ve seen people spend $400 in Steam games because of the Holyday sales...

Hosting curated dependencies is a commercially valuable service.  Eventually an economy arises where people pay vendors to vet packages.

This is the actual answer: stupid cost saving creating an operational risk.

At least then they will have to pay off a dev or something, changes their economic calculus and is additionally illegal

If the fat std library is not viable you can only increase security requirements.Axios has like 100M downloads per week. A couple of people with MFA should have to approve changes before it gets published.

I don&#x27;t know where you&#x27;ve worked but a hostile and intelligent actor or internal red team would succeed under each of those cases at every job I&#x27;ve worked at.

Just going to put features on hold for a month while I review the latest changes to ffmpeg.

An alternative:- copy the dependencies&#x27; tests into your own tests- copy the code in to your codebase as a library using the same review process you would for code from your own team- treat updates to the library in the same way you would for updates to your own codeApparently, this extra work will now not be a problem, because we have AI making us 10x more efficient. To be honest, even without AI, we should&#x27;ve been doing this from the start, even if I understand why we haven&#x27;t. The excuses are starting to wear thin though.

Because fat std is rigid, impractical, and annoying.

Fat std library mistakes&#x2F;warts would likely result in third party packages being used anyway.

Why wouldn&#x27;t the &quot;fat std&quot; thing work? Yes it&#x27;s hard to design properly, both in scope and actual design (especially for an unstandardized language still moving fast), but throwing the towel and punting the problem to the &quot;free market&quot; of uncurated public repos is even worse.It&#x27;s what we call in France &quot;la fête du slip&quot;.PS: that&#x27;s one reason I try to use git submodules in my Common Lisp projects instead of QuickLisp, because I really see the size of my deptree this way.

NPM should have a curation mechanism, via staff review or crowdsourcing, where versions of popular packages are promoted to a stable set, like linux distros do. I would only use curated versions if they had such a thing.

Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.

This is why Node.js is completely unsuitable as backend.
Until recently, there wasn’t even a standard Promise-based HTTP client. Why should we need to download a library just to make a simple HTTP request? It’s because Node.js’s standard library is too limited, leading to an explosive growth in third-party libraries. As a result, it’s vulnerable to security attacks, and maintaining it in an enterprise environment becomes a major challenge.
Let’s use .NET or Go. Why use JavaScript outside of the browser when there are excellent backend environments out there?

JS package managers (pnpm, bun) now will ignore postinstall scripts by default.
Except for npm, it still runs them for legacy reasons.You should probably set your default to not run those scripts. They are mostly unnecessary.<pre><code> ~&#x2F;.npmrc :
 ignore-scripts=true

</code></pre>
83M weekly downloads!

All these supply chain attacks make me nervous about the apps I use. It would be valuable info if an app used such dependencies, but on the other hand, programmers would cut their sales if they gave you this info.

This is just going to get worse and worse as agentic coding gets better. I think having a big dependency tree may be a thing of the past in the coming years. Seems like eventually new malware will be coming out so fast it will basically be impossible to stop.

PSA: Make sure to set a minimum release age and pin versions where possible.

&gt; The amount of people still using this instead of fetch.People are lazy. And sometimes they find old stuff via a
google search and use that.

Axios has a long history, and is included in a lot of code, also in indirect dependencies. Just check its npm page: it has 174025 dependents as of this moment, including a lot of new packages (I see openclaw and mcp related packages in the list).And with LLMs generating more and more code, the risk of copying old setups increases.

The amount of people still using this instead of fetch. Nonetheless when wasn&#x27;t axios, it would be something else.This is why corporations doing it right don&#x27;t allow installing the Internet into dev machines.Yet everyone gets to throw their joke about PC virus, while having learnt nothing from it.

If you&#x27;re developing for the web your attack surface is quite a bit bigger. Your proposed solution of copying a few files might work but how do you keep track of updates? You might be vulnerable to a published exploit fixed a few months ago. A package manager might tell you a new version is available. I don&#x27;t know how that would work in your scenario.

Malicious actor KPI: affect a Ring 0 package.

In practice, &quot;ring 0&quot; is whatever gets merged into your language&#x27;s standard library. Node and python both have pretty expansive standard libraries at this point, stepping outside of those is a choice

The OS distro model is actually the right one here. Upstream authors hate it, but having a layer that&#x27;s responsible for picking versions out of the ecosystem and compiling an internally consistent grouping of known mutually-compatible versions that you can subscribe to means that a lot of the random churn just falls away. Once you&#x27;ve got that layer, you only need to be aware of security problems in the specific versions you care about, you can specifically patch only them, and you&#x27;ve got a distribution channel for the fixes where it&#x27;s far more feasible to say &quot;just auto-apply anything that comes via this route&quot;.That model effectively becomes your ring 1. Ring 0 is the stdlib and the package manager itself, and - because you would always need to be able to step outside the distribution for either freshness or &quot;that&#x27;s not been picked up by the distro yet&quot; reasons - the ecosystem package repositories are the wild west ring 2.In the language ecosystems I&#x27;m only aware of Quicklisp&#x2F;Ultralisp and Haskell&#x27;s Stackage that work like this. Everything else is effectively a rolling distro that hasn&#x27;t realised that&#x27;s what it is yet.

I&#x27;d really like to see package managers organized around rings where a very small core of incredibly important stuff is kept in ring 0, ring 1 gets a slightly wider amount of stuff and can only depend on ring 0 dependencies and then ring 2+ is the crapware libraries that infect most ecosystems.But maybe that&#x27;s not the right fit either. The world where package managers are just open to whatever needs to die. It&#x27;s no longer a safe model.

&gt; Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world.Absolute nonsense. What does automated world even mean? Even if one could infer reasonably, it&#x27;s no justification. Appealing to &quot;the real world&quot; in lieu of any further consideration is exactly the kind of mindlessness that has led to the present state of affairs.Automation of dependency versions was never something we needed it was always a convenience, and even that&#x27;s a stretch given that dependency hell is abundant in all of these systems, and now we have supply chain attacks. While everyone is welcome to do as they please, I&#x27;m going to stick to vendoring my dependencies, statically compiling, and not blindly trusting code I haven&#x27;t seen before.

Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world.What is a problem is library quality. Which is downstream of nobody getting paid for it, combined with an optimistic but unrealistic &quot;all packages are equal&quot; philosophy.&gt; High quality C libraries&gt; OpenSSLOpenSSL is one of the ones where there&#x27;s a ground up rewrite happening because the code quality is so terrible while being security critical.On the other end, javascript is uniquely bad because of the deployment model and difficulty of adding things to the standard library, so everything is littered with polyfills.

The culture within the npm&#x2F;js community has mainly been one of using the package manager rather than &quot;re-inventing the wheel&quot;, as such the blast radius of a compromised package is much greater

It is because it has the lowest barrier to entry with no quality control. Ever.This is what happens when there is no barrier to entry and it includes everyone who has no idea what they are doing in charge of the NPM community.When you see a single package having +25 dependencies, that is a bad practice and increases the risk of supply chain attacks.Most of them don&#x27;t even pin their dependencies and I called this out just yesterday on OneCLI. [0]It just happens that NPM is the worst out of all of the rest of the ecosystems due to the above.[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=47577183">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=47577183</a>

For some reason, NPM is the only ecosystem with substantial issues with supply-chain attacks.

And manual FTP uploads, while we&#x27;re at it.

You don’t need to. Llm will do it for you and include the security bug

no no, please we don&#x27;t want to get back to dragging files to your project to make them work.

Rust is terrible for pulling in hundreds of dependencies though. Add tokio as a dependency and you&#x27;ll get well over 100 packages added to your project.

Rust libraries are infrequently used outside of Rust because if you have the option, you&#x27;d just use Rust, not the ancient featureless language intrinsically responsible for 70% of all security issues. C libraries are infrequently used in Rust outside of system libc, for the same reason; I go and toggle the reqwest switch to use rustls every time, because OpenSSL is horrendous. This is also why you say &#x27;rarely&#x27; instead of &#x27;never&#x27;, when a few years ago it was &#x27;never&#x27;; a few years from now you&#x27;ll say &#x27;uncommonly&#x27;, and so on. The reason C libraries are used is because you don&#x27;t feel like reimplementing it yourself, and they are there; but that doesn&#x27;t apply more to C libraries than Rust libraries, and the vast majority of crates.io wouldn&#x27;t be usefully represented in C anyway, or would take longer to bind to than to rewrite. (No, nobody uses libcurl.) Finally, this only happens in NPM, and the Rust libraries you pull in are all high-quality. So this sounds like a bunch of handwaving about nonsense.

I don&#x27;t think this community of professionals is going to come around to a solution which requires marginally more effort.If no one checks their dependencies, the solution is to centralize this responsibility at the package repository. Something like left-pad should simply not be admitted to npm. Enforce a set of stricter rules which only allow non-trivial packages maintained by someone who is clearly accountable.Another change one could make is develop bigger standard libraries with all the utilities which are useful.
For example in Rust there are a few de facto standard packages one needs very often, which then also force you to pull in a bunch of transitive dependencies.
Those could also be part of the standard library.This all amounts to increasing the minimal scope of useful functionality a package has to have to be admitted and increasing accountability of the people maintaining them. This obviously comes with more effort on the maintainers part, but hey maybe we could even pay them for their labor.

&gt; You are just swapping a package manager with security by obscurity by copy pasting code into your projectYou should try writing code, and not relying on libraries for everything, it may change how you look at programming and actually ground your opinions in reality. I&#x27;m staring at company&#x27;s vendor&#x2F; folder. It has ~15 libraries, all but one of which operate on trusted input (game assets).&gt; fundamental benefits of a package manager.I literally told you why they don&#x27;t matter if you write code in a sane way.&gt; doing C-style bindings is actually quite commonI know bindings for Rust libraries exist. Read the literal words you quoted. &quot;Rust libraries are very rarely used outside of Rust&quot;. Got some counterexamples?

&gt; We have libraries like SQLite, which is a single .c file that you drag into your projectYou are just swapping a package manager with security by obscurity by copy pasting code into your project. It is arguably a much worse way of handling supply chain security, as now there is no way to audit your dependencies.&gt; If you get rid of transitive dependencies, you get rid of the need of a package managerThis argument makes no sense. Obviously reducing the amount of transitive dependencies is almost always a good thing, but it doesn&#x27;t change the fundamental benefits of a package manager.&gt; There&#x27;s so many C libraries like thisThe language with the most fundamental and dangerous ways of handling memory, the language that is constantly in the news for numerous security problems even in massively popular libraries such as OpenSSL? Yes, definitely copy-paste that code in, surely nothing can go wrong.&gt; They also bindings for every language under the sun. Rust libraries are very rarely used outside of RustThis is a WILD assumption, doing C-style bindings is actually quite common. YOu will of course then also be exposing a memory unsafe interface, as that is what you get with C.What exactly is your argument here? It feels like what you are trying to say is that we should just stop doing JS and instead all make C programs that copy paste massive libraries because that is somhow &#x27;high quality&#x27;.This seems like a massively uninformed, one-sided and frankly ridiculous take.

&gt; But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libsSo don’t?With manual deps management, everyone soon gravitates to a core set of deps. And libraries developer tends to reduce their deps needs, That’s why you see most C libraries deals with file formats, protocols, and broad concerns. Smaller algorithms can be shared with gists and blog articles.

I think you can do copy paste in most languages. But it will be a pain to update when there are improvements &#x2F; security fixes.You got a project with 1-2 depencies? Sure. But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libs) good luck.

&gt; We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable&#x27;s size.I&#x27;m not sure why you believe this is more secure than a package manager. At least with a package manager there is an opportunity for vetting. It&#x27;s also trivial that it did not increase your executable&#x27;s size. If your executable depends on it, it increases its effective size.

Package managers are older than some users here. From CPAN&#x2F;CTAN to ports under BSD&#x27;s.Some pm&#x27;s are badly maintained (Pip&#x2F;NPM), while others are curated enough.Again, if you have GNU&#x2F;Linux installed, install Guix, read the Info manual on &#x27;guix import&#x27; and just create a shell&#x2F;container with &#x27;guix shell --container&#x27; (and a manifest package created from guix import) and use any crap you need for NPM in a reproducible and isolated way. You $HOME will be safe, for sure.

&gt; Publishers to official registries should be forced to use 2FA. I proposed this a decade ago for crates.io and people lost their minds, like I was suggesting we drag developers to a shed to be shot.How is this enforced when it&#x27;s pushed via a pipeline?

I don&#x27;t understand commercial aspect of large OSS like package managers but i was wondering for years why this was missing from npm. 
I think typosquatting was handled by npm last year but only after some popular miss typed packages started stealing developer creds.

For those who didn&#x27;t know what TUF means (like me), I think they&#x27;re referring to The Update Framework (<a href="https:&#x2F;&#x2F;theupdateframework.io" rel="nofollow">https:&#x2F;&#x2F;theupdateframework.io</a>).

They&#x27;re not a failed experiment. No one has ever &quot;experimented&quot; by making a safe package manager for their new language. And it is not that insane to do so. Very basic things will get you very far:1. Packages should carry a manifest that declares what they do at build time, just like Chrome extensions do. This manifest would then be used to configure its build environment.2. Publishers to official registries should be forced to use 2FA. I proposed this a decade ago for crates.io and people lost their minds, like I was suggesting we drag developers to a shed to be shot.3. Every package registry should produce a detailed audit log that contains a &quot;who, what, when&quot;. Every build&#x2F; command should be producing audit logs that can be collected by endpoint agents too.4. Every package registry should support TUF.5. Typosquatting defenses should be standard.etc etc etc. Some of this is hard, some of this is not hard. All of this is possible. No one has done it, so it&#x27;s way too early to say &quot;package managers can&#x27;t be made safe&quot; when no one has tried.

Then you&#x27;ve got ecosystems like Clojure where many projects are just considered done and used by many. You can pin these (and be warned if a new version still comes out, say for an actual security fix). There are Clojure projects so stable, without any know exploit (we&#x27;re certainly not talking about daily npm exploits here), that haven&#x27;t been updated in years because they are... Done. Simply done. Perfection.Something to reflect upon too.

SQLite had 6 CVE&#x27;s last year. FreeType had an RCE bug published last year. libcurl&#x27;s last CVE reported was 2 weeks ago. Libpng had 4 vulnerabilities published this year....

Thought experiment: a language that enforces dependencies to be 2 levels deep or less.I wonder if dependencies would flatten out with this limitation in mind.

Package managers are a failed experiment.We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable&#x27;s size.The issue is not dependencies themselves, it&#x27;s transitive ones. Nobody installs left-pad or is-even-number directly, and &quot;libraries&quot; like these are the vast majority of the attack surface. If you get rid of transitive dependencies, you get rid of the need of a package manager, as installing a package becomes unzipping a few files into a vendor&#x2F; folder.There&#x27;s so many C libraries like this. Off the top of my head, SQLite, FreeType, OpenSSL, libcurl, libpng&#x2F;jpeg, stb everything, zlib, lua, SDL, GLFW... I do game development so I&#x27;m most familiar with the ones commonly used in game engines, but I&#x27;m sure other fields have similarly high quality C libraries.They also bindings for every language under the sun. Rust libraries are very rarely used outside of Rust, and C#&#x2F;Java&#x2F;JS&#x2F;Python libraries are never used outside their respective language (aside form Java ones in other JVM langs).

NPM gets worse than russian roulette. Perhaps we have to
rename russian roulette to node roulette: noulette.

And yet so many &quot;Installation&quot; pages will recommend it!

Running almost anything via npx will trigger this

Yes. Docker breakout is a class of vulnerabilities into itself.

Just sanity checking - if I only ever install axios in a container that has no secrets mounted in to its env, is there any real way I can get pwned by this kind of thing?

Exactly. Yarn uses a yarn.lock file with the sha256 hashes of each npm package it downloads from the repo (they are .tgz files). If the hash won&#x27;t match, install fails. No need to commit the dependencies into your git.

Zero-installs mode does not replace the lockfile. Your lockfile is still the source of truth regarding integrity hashes.However, it’s an extra line of defence against1) your registry being down (preventing you from pushing a security hotfix when you find out another package compromised your product),2) package unpublishing attacks (your install step fails or asks you to pick a replacement version, what do you do at 5pm on a Friday?), and3) possibly (but haven’t looked in depth) lockfile poisoning attacks, by making them more complicated.Also, it makes the size of your dependency graph (or changes therein) much more tangible and obvious, compared to some lines in a lockfile.

&gt; Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in.Idk, lockfiles provide almost as good protection without putting the binaries in git. At least with `--frozen-lockfile` option.

Essential steps to minimise your exposure to NPM supply chain attacks:— Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in.— Disable post-install scripts. If you don’t, at least make sure your package manager prompts for scripts during install, in which case you stop and look at what it’s going to run.— If third-party code runs in development, including post-install scripts, try your best to make sure it happens in a VM&#x2F;container.— Vet every package you add. Popularity is a plus, recent commit time is a minus: if you have this but not that, keep your eyes peeled. Skim through the code on NPM (they will probably never stop labelling it as “beta”), commit history and changelog.— Vet its dependency tree. Dependencies is a vector for attack on you and your users, and any new developer in the tree is another person you’re trusting to not be malicious and to take all of the above measures, too.

That sounds terrifying. Stay out of my ~&#x2F; thank you very much.

In light of these nonstop supply chain attacks:
Tonight I created &#x2F;supply-chain-audit
-- A simple claude code skill that fetches info on the latest major package vulnerability, then scans your entire ~&#x2F; and gives you a report on all your projects.<a href="https:&#x2F;&#x2F;github.com&#x2F;IsaacGemal&#x2F;claude-skills" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;IsaacGemal&#x2F;claude-skills</a>It&#x27;s a bit janky right now but I&#x27;d be interested to hear what people think about it.

The NPM ecosystem is a joke. I don&#x27;t even want anything to do with it, because my stack is fully Elixir. But, just because of this one dependency that is used in some interfaces within my codebase, I need to go back to all my apps and fix it. Sigh.JavaScript, its entire ecosystem is just a pack of cards, I swear. What a fucking joke.

The attacker went through the hassle to compromise a very widely used package, but use a non standard port (8000) on their C2...
If you plan to do something like that, use 443 at least, many corporate network do not filter this one ;)

I wonder if this has any connection with the recent string of attacks including the FBI director getting hacked. The attack surface is large, executed extremely cleanly - almost as if done by a high profile state sponsored actor, just like in Hollywood movies.

I&#x27;m working on a multi signature solution that helps to detect unauthorized releases in the case of an account hijack. It is open source, self hostable, accountless and I am looking for feedback!Website: <a href="https:&#x2F;&#x2F;asfaload.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;asfaload.com&#x2F;</a>GitHub:<a href="https:&#x2F;&#x2F;github.com&#x2F;asfaload&#x2F;asfaload" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;asfaload&#x2F;asfaload</a>Spec: <a href="https:&#x2F;&#x2F;github.com&#x2F;asfaload&#x2F;spec" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;asfaload&#x2F;spec</a>

Axios compromised on NPM – Malicious versions drop remote access trojan