Xe argues that the risk calculus for installing new software has fundamentally shifted due to a relentless stream of supply chain incidents — typosquatting, compromised maintainer accounts, malicious packages, and the XZ Utils backdoor. The cumulative effect means developers should pause and stop installing new things until they've updated their threat model.
The editorial argues that the post's strong resonance (741 HN points) reflects a widespread but unarticulated feeling among senior developers: every casual `npm install` or `pip install` is an implicit trust decision across the registry, the maintainer's identity, and the entire transitive dependency tree — and most developers make these decisions in 90 seconds without real evaluation.
The post received 741 points and 396 comments, indicating strong community agreement that supply chain risk is top-of-mind. The volume of engagement suggests developers across the industry recognize the problem Xe describes, even if they haven't changed their own behavior yet.
Xe Iaso — an infrastructure engineer, prolific technical writer, and one of the sharper voices in the developer blogosphere — published a post titled "Maybe you shouldn't install new software for a bit" that promptly hit 741 points on Hacker News. The core argument is deceptively simple: stop installing new things. Not forever. Just... for a bit.
The post arrives at a moment when the software supply chain has become a recurring punchline with real casualties. Every `npm install`, `pip install`, or `brew install` you run is an implicit trust decision — and most developers make dozens of these decisions per week without a second thought. Xe's argument isn't that all software is dangerous. It's that the risk calculus has shifted, and most developers haven't updated their priors.
The timing is not accidental. The past 18 months have delivered a relentless stream of supply chain incidents: typosquatting campaigns on PyPI and npm, compromised maintainer accounts, malicious packages that exfiltrate environment variables on install, and the lingering aftershocks of the XZ Utils backdoor that showed even deeply trusted, boring infrastructure dependencies can be weaponized. Each incident alone is manageable. The cumulative effect is a trust environment where the default posture of "install first, evaluate later" has become genuinely reckless.
The reason this post resonated so hard — 741 HN points is serious signal — is that it names something most senior developers already feel but haven't articulated: dependency fatigue isn't just annoying, it's a security posture problem.
Consider the typical developer workflow. You hit a problem. You search for a package. You find one with decent stars and recent commits. You install it. You move on. That entire decision took 90 seconds and involved trusting: the package registry's malware detection, the maintainer's identity verification, every transitive dependency the package pulls in, and the build scripts that run during installation. That 90-second decision carries more implicit trust than most developers extend to their own coworkers' code reviews.
Xe's framing rejects the incrementalist approach of "just use lockfiles" or "just pin versions" — not because those practices are wrong, but because they address symptoms while the disease is cultural. The disease is that developers treat installing new software as zero-cost. It is not zero-cost. Every new dependency is:
- A new attack surface that persists until you actively remove it - A maintenance obligation you've silently accepted - A trust relationship with a maintainer you've never met - A transitive graph of further trust relationships you haven't even inspected
The counterargument is obvious and worth stating honestly: not installing things is also costly. Reinventing wheels burns engineering time. Using outdated tools creates its own security risks. And taken to its logical extreme, this philosophy leads to the kind of NIH syndrome that produces worse, buggier versions of things the ecosystem already solved.
The resolution isn't "never install anything" — it's "make installation a deliberate decision rather than a reflex." This is the difference between a developer who runs `npm install left-pad` without thinking and one who spends 30 seconds asking: do I actually need this, who maintains it, and what does it pull in?
What makes this moment different from the perennial "dependencies are risky" discourse is the professionalization of supply chain attacks. These are no longer drive-by experiments by bored researchers. Nation-state actors and organized crime groups have recognized that package registries are high-leverage targets. A single compromised package can propagate to thousands of CI/CD pipelines within hours.
The XZ Utils incident was the wake-up call that should have changed everything. A patient, multi-year social engineering campaign to gain maintainer trust on a critical compression library used by virtually every Linux distribution's SSH stack. The attacker didn't exploit a technical vulnerability — they exploited the social dynamics of open-source maintenance: overworked maintainers grateful for help, insufficient review bandwidth, and the assumption that long-term contributors are trustworthy.
If that can happen to XZ Utils — a package with extraordinary scrutiny relative to its size — what's happening right now in the long tail of packages that nobody is watching? That question is what gives Xe's "just stop installing things" advice its uncomfortable weight.
The actionable version of Xe's advice isn't a vow of software celibacy. It's a set of concrete practices that most teams could adopt this week:
Audit your existing dependencies before adding new ones. Most projects have unused or redundant packages that accumulated over years of "oh just npm install it." Run your language ecosystem's equivalent of `depcheck` or `pip-audit`. You'll likely find packages you can remove, which is strictly better than adding new ones.
Raise the bar for new installations. Before adding a dependency, require answering three questions: (1) Can we solve this with what we already have? (2) Who maintains this and what's their track record? (3) What's the transitive dependency graph look like? If your team can't answer all three in five minutes, that's a signal.
Treat `install` commands in CI/CD like production deployments. Your CI pipeline's `npm install` step is running arbitrary code from the internet on infrastructure that has access to your secrets, source code, and deployment credentials. If that sentence makes you uncomfortable, good. Consider pinning to exact versions, using lockfiles religiously, and running installations in sandboxed environments.
Embrace boring technology. The standard library in most modern languages is far more capable than developers give it credit for. Go's standard library can handle HTTP servers, JSON parsing, cryptography, and templating without a single external dependency. Python's `http.server`, `json`, `hashlib`, and `pathlib` cover an enormous surface area. Before reaching for a package, check if the standard library already does what you need.
Xe's post is one data point in a larger shift. The era of frictionless, thoughtless dependency installation is ending — not because anyone decided it should, but because the threat environment made the old approach untenable. The registries are responding with signing, provenance attestation, and malware scanning. But those are backstops, not solutions. The real change has to happen at the keyboard, in the moment a developer decides whether to install something new or work with what they have. The 741-point HN response suggests a lot of developers are ready to hear that message.
This is a baffling take.. These exploits are local privilege escalations for linux systems. They'll allow an attacker with a foothold in a shared environment or with low privilege access to a system to affect the rest of the system. They aren't RCEs and won't let attackers access envi
"Wait a week to install software" does not work. Just a few months ago a massive exploit hit the web, which was a timed attack which sat for more than a month before executing. If everyone starts waiting a week, their exploits will wait 2 weeks. Cyber criminals do not need to exploit you i
Sorry, I don't get it. What's the chain of reasoning that connects "there are a couple of new Linux local privilege escalation exploits" to "don't install any new software"? Is the threat we're supposed to be concerned about here just a package maintainer publ
Alternatively, switch to an operating system like FreeBSD which doesn't take a YOLO approach to security. Security fixes don't just get tossed into the FreeBSD kernel without coordination; they go through the FreeBSD security team and we have binary updates (via FreeBSD Update, and via pkg
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face.But it was too convenient. Anyone warning about it or trying to limit the damage