The package you did not review

Every npm install and pip install runs someone else's code on your laptop and in your build. How software supply-chain attacks work, and what a package firewall changes.

A modern application is mostly other people's code. A typical web service pulls in a few hundred direct dependencies and a few thousand transitive ones, and every one of them can run an install script on the machine that fetched it. Attackers noticed. Publishing a package that looks like the one you meant to install, taking over an abandoned one, or slipping a malicious version into a popular one is now a routine way in — and it works against developer laptops and CI runners alike, the two places with the most credentials.

The four shapes of a supply-chain attack

• Typosquatting and name confusion. reqeusts instead of requests; a public package with the same name as your internal one, which the resolver prefers.
• Maintainer compromise. A phished account publishes a new version of a package with millions of weekly downloads. The code is identical except for one install hook.
• Abandoned package takeover. The maintainer moved on; the name was transferred or the domain behind the maintainer's email expired. The next release is not theirs.
• Build-time injection. The source on the repository is clean; the published artefact is not. Only verifying what you install, not what you read, catches this.

Why scanning after the fact is not enough

Vulnerability scanning tells you a package has a known weakness. It cannot tell you a package is malicious until someone has reported it, and the window between publication and report is where the damage happens — often measured in hours, which is enough to harvest every token on a build server. The control has to sit at install time.

What a package firewall does

A package firewall is a policy enforced on the developer machine and the CI runner at the moment a package manager resolves a dependency:

1. Allow packages and versions that are known, pinned and already reviewed.
2. Hold anything new for a cooling-off period — a version published minutes ago is far more likely to be a compromise than one published a month ago.
3. Block packages on malware blocklists, names that look like confusables of popular packages, and versions with suspicious install scripts.

The developer sees a one-line message and, for a held package, a way to request a review. The build sees a failed step instead of a compromised runner.

The habits that make it stick

Lockfiles committed and honoured by CI. Install scripts disabled by default where the ecosystem allows it. Scoped registries for internal packages so a public name can never shadow them. A signed SBOM for every release, so when the next advisory lands you can answer "are we affected?" in minutes.

You review your own pull requests. The install step merges thousands of pull requests you have never seen.

Where EagleWise fits

Eagle Guard is EagleWise's package firewall for workstations and build agents: allow, hold and block policies for npm and PyPI, fed by malware intelligence and newly-published-version holds, with every decision recorded so a blocked install is a finding with an owner rather than a mystery on someone's laptop.