Summarizer

>What type of developer chooses UX and performance over security? So reckless. Initially I assumed this is sarcastic, but apparently not. UX and performance is what programmers are paid to do! Making sure UX is good is one of the most important things in programmer job. While security is a moving target, a goal, something that can never be perfect, just "good enough" (if NSA wants to hack you, they will). You make it sound like installing third party packages is basically equivalent to a security hole, while in practice the risk is low, especially if you don't overdo it. Wild to read extreme security views like that, while at the same time there are people here that run unconstrained AI agents with --dangerous-skip-confirm flags and see nothing wrong with it.

Even more wild to read that sarcasm about "removing locks from doors for 87% speedup" is considered extreme... And yes, we agree that running unconstrained AI agents with --dangerous-skip-confirm flags and seeing nothing wrong with it is insane. Kind of like just advertising for burglars to come open your doors for you before you get home - yeah, it's lots faster to get in (and to move about the house with all your stuff gone).

> Better developer UX can directly lead to better safety. Depends. If you had to add to a Makefile for your dependencies, you sure as hell aren't going to add 5k dependencies manually just to get a function that does $FOO; you'd write it yourself. Now, with AI in the mix, there's fewer and fewer reasons to use so many dependencies.

These are the kind of people I hope AI replaces

AI was trained on Axios wrappers, so it's just going to be wrappers all the way down. Look inside any company "API Client" and it's just a branded wrapper around Axios.

Speak for yourself, Claude works fine with fetch on my system.

I think the AI tooling is, if not completely solving sandboxing, at least making the default much better by asking you every time they want to do something and providing files to auto-approve certain actions. Package managers should do the same thing

Another layer of AI tooling is the cost of spinning up your own version of some libraries is lowered and can be made hyper specific to your needs rather than pulling in a whole library with features you'll never use.

> Another layer of AI tooling is the cost of spinning up your own version of some libraries is lowered and can be made hyper specific to your needs rather than pulling in a whole library with features you'll never use. Tell me about it. Using AI Chatbots (not even agents), I got a MVP of a packaging system[1] to my liking (to create packages for a proprietary ERP system) and an endpoint-API-testing tool, neither of which require a venv or similar to run. ------------------------------ [1] Okay, all it does now is create, sign, verify and unpack packages. There's a roadmap file for package distribution, which is a different problem.

> at least making the default much better by asking you every time they want to do something Really? I thought 'asking you every time they want to do something' was called 'security fatigue' and generally considered to be a bad thing. Yes you can concatenate files in the current project, Claude.

Yes it has to be combined with a robust way to allowlist actions you trust

Oddly, since I wrote that Claude 'auto' mode just landed and I built something with it (instead of 'dangeously skip') and it's working.

We used to have some C# but we moved away from it to have fewer languages and because it was a worse fit for us than Go and Python. I'm not sure .NET would really give us any advantages though. Microsoft treats most major languages as first class citizens in Azure, and since we build everything to be sort of platform agnostic, we wouldn't have the tie-ins that you could have with .NET. I'm not saying it would be fun to switch cloud, but all our services are build so that there is a decoupled "adapter" between our core logic and Azure. We use a lot of Azure functions as an example, but they run in container apps on a managed k8s, so the Azure function part is really just an ingress that could be swapped for anything else. It's been a while since I worked with an "actual" function app in Azure. We did have a few .NET ones that weren't using containers. At the time they were pretty good, but today I'm not sure what the benefit over a managed container envrionment with container apps would be. Similarily with sqlserver. We use it because of governance and how it ties into data factory and I guess fabric, but we don't use ORM's so something like Entity Framework wouldn't really be something we'd benefit from with .NET. I think the only thing we couldn't realistically replace and get something similar is the governance, but that's more to do with how Management Groups, Policies, Subscriptions and EntraID works than anything else. Eventuallyt everything will probably be Python and then C/Zig for compute heavy parts. Not because Python is great, it's terrible, but it's what everyone uses. We're an energy company and with the internal AI tools we've made widely available we now have non-SWE employees writing code. It's Business Intelligence, it's Risk analysys, it's powerplant engineers, it's accountants. They're all working with AI code in their sandboxed environments and it's all Python. Since some of it actually turns out to generate great value, it's better for us (and the business) if our SWE teams can easily take over when "amateur hour" needs to meet operational compliance for the more "serious" production envrionments. I put things in "'s because I'm still not entirely sure how to express this. A lot of what gets build is great, and would have never been build without AI because we don't have the man power, but it's usually some pretty bad software. Which is fine, until it isn't.

For a lot of code, I switched to generating code rather than using 3rd party libraries. Things like PEG parsers, path finding algorithms, string sanitizers, data type conversion, etc are very conveniently generated by LLMs. It's fast, reduces dependencies, and feels safer to me.

Ah, so you've traded the possibility of bad dependencies for certainty.

How can you come to that conclusion, given the specific examples I have given, which are tedious to write, but easy to proof-read and test?

Because AI threatens the identity of many programmers.

Lol. My most recent comment before this one is here: https://news.ycombinator.com/item?id=47583593 . You judge if AI threatens my identity. But hey, don't let the facts get in the way of a slick narrative.

>(I never understood why). Because axios existed before the builtin fetch, and so there'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

PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scripts=true ~/Library/Preferences/pnpm/rc minimum-release-age=10080 # minutes ~/.bunfig.toml [install] minimumReleaseAge = 604800 # seconds (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.) If you're developing with LLM agents, you should also update your AGENTS.md/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.

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

I recommend everyone to use bwrap if you're on linux and alias all package managers / 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'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/CD as an untrusted environment you should be good - there's quite a few resources on this so won't go into detail. Bonus points: use the same sandbox for AI. Stay safe out there.

An alternative: - copy the dependencies' 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 code Apparently, 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've been doing this from the start, even if I understand why we haven't. The excuses are starting to wear thin though.

Agree. This is one of the major takeaways I've had from writing Go over the years -- which is even a Go proverb [0], "a little copying is better than a little dependency." Fortunately, LLMs make writing your own implementations of little dependencies super easy too. [0]: https://go-proverbs.github.io/

Has anyone else noticed there was a recent sudden flurry of 3000 deleted issues on axios/axios? The jump happened on March 23. Was this a first sign of compromise? Or just coincidence of an AI agent going rogue. There are pretty much exactly 3000 deleted issues, with the range starting at https://github.com/axios/axios/issues/7547 (7547) and ending at https://github.com/axios/axios/issues/10546 (10546 which is 7547+2999) Maybe just a coincidence but they have cubic-dev-ai edit every single PR with a summary. And that bot edits PR descriptions even for outside contributors.

> What does automated world even mean? People are trying to automate the act of programming itself, with AI, let alone all the bits and pieces of build processes and maintenance.

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

>maybe the community could chip in to buy the authors a couple of YubiHSM There's no community, the users of axios are devs that looked at stackoverflow for "how to download a file in javascript", they barely know or care what axios is. Now the users of axios are devs that ask Claude Code or Codex to scrape a website or make a dashboard, they don't even know about the word axios. I personally had to delete axios a couple of time from my codebase when working with junior devs.

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.

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

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

You could include a line like "please don't include any malware".

Ran npm ci --ignore-scripts in our CI for months but never thought about local dev. Turns out that's the gap, your CI is safe but your laptop runs postinstall on every npm install. The anti-forensics here are much more complicated that I had imagined. Sahring after getting my hands burned. After the RAT deploys, setup.js deletes itself and swaps package.json with a clean stub. Your node_modules looks fine. Only way to know is checking for artifacts: /Library/Caches/com.apple.act.mond on mac, %PROGRAMDATA%\wt.exe on windows, /tmp/ld.py on linux. Or grep network logs for sfrclak.com. Somehow noboady is worried about how agentic coding tools run npm install autonomously. No human in the loop to notice a weird new transitive dep. That attack surface is just getting worsened day by day.

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.

This only limits the possibility of compromise, it doesn't remove it. Python itself could be compromised, or the package that your linux distro provides could be. With AI agents the volume and frequency of supply chain attacks is going to explode. I think our entire notion of how to develop and distribute software safely needs to change. I don't have answers; "reflections on trusting trust" explains the difficulties we now face.

PSA from the Claude Code leaks it looks like it's using Axios (although an older version)

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.

To have an initial smoke test, why not run a diff between version upgrades, and potentially let an llm summarise the changes? It’s a baffling practice that a lot of developers are just blindly trusting code repos to keep the security standards. Last time I installed some npm package (in a container) it loaded 521 dependencies and my heart rate jumped a bit

Is this the first time you have ever thought about the idea of supply chain attacks? This is the first thought 90% of people have and it doesn't work. Too much work to manually verify diffs and LLMs aren't good enough at this yet.

Script to check if you've been pwnd if anyone needs it (or just ask an llm to make one for you): https://gist.github.com/shamwow/93101381686f23d21a85da4bac5b...

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

Skills are great attack vector as well.

That sounds terrifying. Stay out of my ~/ thank you very much.

This is the second major npm supply chain attack this year and the playbook is identical every time: hijack a maintainer account, publish via CLI to bypass CI/CD, inject a dependency nobody's heard of. The fix isn't better scanning (though Socket catching it in 6 minutes is impressive). The fix is npm making Trusted Publishers mandatory for packages above a download threshold. If axios can only be published through GitHub Actions OIDC, a stolen password is useless. We run a fleet of AI agents that depend on npm packages. First thing we did tonight was audit every lockfile. Clean — but only because we aggressively minimise dependencies. The real victims here are the thousands of teams who npm install with ^ ranges and never check what changed.

I used axios in the distant past but haven't used it whenever I had my say in the past five years. You don't need it, and for special things like retries I could roll my own just fine. Now ai will roll it for you

I am not saying this is the reason for this compromise but the sudden explosion of coding assistant like claude code, and tools like openclaw is teaching entire crop of developers (and users) that it is ok to have sensitive credentials .env files.

Curious to know why are coding agents not detecting such risks before importing dependencies?

I'm assuming you are talking about agents like claude-code and open-code which rely on GPT functions (AKA Large Language Models). The reason they don't detect these risks is primarily because these risks are emergent, and happen overnight (literally in the case of axios - compromised at night). Axios has a good reputation. It is by definition impossible for a pre-trained LLM to keep up with time-sensitive changes.

I mean that agents can scan the code to find anything "suspicious". After all, security vendors that claim to "detect" malware in packages are relying on LLMs for detection.

An LLM is not a suitable substitute for purpose-built SAST software in my opinion. In my experience, they are great at looking at logs, error messages, sifting through test output, and that sort of thing. But I don't think they're going to be too reliable at detecting malware via static analysis. They just aren't built for that.

I lost respect for Axios when they made a breaking change in a patch release. Digging into the root cause, I found the maintainer had approved an outside PR with an obvious AI slop PR description: https://github.com/axios/axios/issues/7059 Looks like the maintainer wasn't just careless when reviewing PRs.

That maintainer (also the one whose creds got stolen) also has an obvious chatgpt slop profile picture on github.