The Moment a Malicious Package Actually Costs You Something
There is a specific moment in the life of a supply-chain attack that matters more than almost any other: the instant a developer runs npm install or pip install and a malicious package lands on their machine. Everything a scanner does afterward, flagging the package in a later scan, opening a ticket, filing a remediation PR, is cleanup. By the time a post-install scan catches a typosquatted or compromised package, it may already have run its install script, exfiltrated an environment variable, or dropped a payload on a developer's laptop. Detection after the fact is valuable. Prevention at the point of install is better.
That is the specific problem a package firewall is built to solve, and it is why Safeguard includes a Package Firewall engine in its scanner catalog today, per internal confirmation. Depth here, as with the other newer engines added to the catalog, is still developing, so the right way to evaluate it is a scoped demo against your own package ecosystems rather than an assumption of full maturity on day one.
An install-time proxy, not a post-hoc scan
The mechanism is worth being specific about, because it is what differentiates this from ordinary dependency scanning. Package Firewall sits as a proxy in the install path for npm and pip, the two package managers where dependency-based attacks have been most consistently observed in the wild. Rather than waiting for a package to be installed and then evaluating it, the firewall intercepts the request as it happens, before the code from an untrusted package ever executes on a developer's machine or in a build pipeline.
This timing difference is not a minor implementation detail. Malicious packages frequently do their damage through install scripts, code that runs automatically the moment the package is unpacked, well before a developer imports it or writes a single line that calls it. A scanner that runs after installation has already missed the window where an install script can read credentials, phone home, or modify local files. An install-time proxy closes that window by evaluating the package before it is allowed to land at all.
What gets checked before a package is allowed through
The checks that run at that interception point are aimed at the failure modes most associated with real supply-chain compromises: typosquatting (a package name deliberately close to a popular one, banking on a developer's typo), dependency confusion (an attacker publishing a public package with the same name as an internal private one, hoping the build system resolves the wrong one), and known malware signatures. When a package trips one of these checks, the response is configurable rather than all-or-nothing: an organization can choose to allow, warn, block, audit, or quarantine, depending on how strict a given team or environment needs to be. A security-conscious platform team might block outright in CI while a smaller engineering team starts with warn-only to build trust in the tooling before tightening it.
Where this fits alongside the rest of the story
Package Firewall is naturally paired with the broader malware detection and hardened-package work happening elsewhere in the platform, but its own job is narrower and more specific: stop the bad package from ever landing in the first place, at the exact moment a developer or a build system reaches out to fetch it. That is a different job from classifying a package as malicious after the fact, and it is a different job from offering a clean, pre-vetted alternative to install instead. Each of those pieces matters, but this post is about the interception mechanism itself: the proxy that stands between a developer's install command and the open internet.
Because this is one of the newer engines in the catalog, we would rather describe it precisely than oversell it: it is real, it is usable, and its depth is still expanding, so scope a demo against your actual package ecosystem before making assumptions about coverage.
Stop the install before it starts
If your team has ever discovered a malicious package after it was already installed across a dozen developer machines, you already understand why the install-time moment matters more than the scan that comes after it. Reach out through safeguard.sh to see how Package Firewall intercepts npm and pip installs before they become an incident.
