Package Firewall
Stop malicious and typosquatted dependencies at install time — inline allow / warn / block enforcement for typosquats, dependency confusion, and known-malicious packages.
Package Firewall
The Package Firewall moves dependency protection to install time. Instead of finding a bad package after it's already in your tree, it evaluates each dependency as it's installed and can allow, warn on, or block it inline.
How it works
The firewall runs as an install-time proxy fronting npm and pip. Package managers fetch through the proxy instead of hitting the upstream registry directly, so every request is evaluated before the package ever reaches your machine or build.
Because the proxy sits on the fetch path, coverage is transitive by construction — it sees every fetch, including transitive dependencies pulled in by your direct dependencies. There is no separate lockfile-parsing step to keep in sync; if a package is downloaded, it is checked.
What it checks
| Threat | How it's detected |
|---|---|
| Typosquatting | Package names within a small Damerau-Levenshtein edit distance of a well-known package (accounting for transposed characters) are flagged as likely impersonations. |
| Dependency / namespace confusion | Names that could resolve to a public package in place of an intended internal one — or that squat on an internal namespace — are caught. |
| Malware / blocklist | Packages matching known-malicious signatures or an explicit blocklist are stopped. |
| Behavioral analysis | A behavioral analyzer inspects the package archive statically — introspecting its contents without executing any code — to surface suspicious indicators before install. |
Enforcement modes
The firewall runs inline with three outcomes:
- Allow — the package passes and installs normally.
- Warn — the install proceeds but the decision is recorded and surfaced.
- Block — the install is refused.
It also supports:
- Audit mode — evaluate and record decisions without blocking, so you can measure impact before enforcing.
- Quarantine mode — hold a flagged package aside pending review rather than installing or hard-blocking it.
Auto-release loop
A quarantined package doesn't have to stay quarantined forever. The firewall re-evaluates held packages and auto-releases one once its verdict clears — for example, when a false-positive signal is corrected or a package is no longer flagged. Packages that never clear are aged out after a configurable window (default 14 days), so quarantine doesn't accumulate stale entries.
Every decision is recorded to the audit trail with the package, the rule that fired, the mode, and the outcome — tenant/org-scoped.
Findings produced
Every non-allow decision becomes a finding in the unified findings model, discriminated as sca with a rule ID of package-firewall/<category> (for example package-firewall/typosquat or package-firewall/behavioral). Each finding carries the ecosystem, package name and version, the category that fired, the mode, and — in audit mode — the verdict that would have been enforced. Transitive fetches are marked as such. Confirmed-malware and namespace-confusion decisions are the highest-severity outcomes; behavioral and novel-package signals are held in quarantine pending review.
Configuration
The Package Firewall is admin-toggleable via a feature flag, enforced server-side. Start in audit mode to baseline, then move to warn or block as confidence grows.
You enforce at whichever point fits your workflow — a local/CI proxy, a registry-fronting proxy in front of your Nexus or Artifactory, or the server-side runner — all sharing the same decision core:
# Local / CI proxy for npm and pip
safeguard firewall start --mode quarantine --ecosystem npm,pypi --port 8480
# Front an existing repository manager
safeguard firewall registry --front artifactory --upstream https://registry.npmjs.org
# One-shot check (exit 1 on block)
safeguard firewall check pkg:npm/left-pad@1.3.0Related
- Malware Detection — Eagle-based classification behind the malware check.
- Deep Dependency Scanning — transitive dependency analysis after install.
- Unified Findings & Feature Flags — how engines are toggled across the platform.
SecOps (SIEM)
OCSF-normalized security event ingestion, continuous detection with Sigma rules and IOC matching, and deduplicated alerts — the SIEM substrate, with SOAR, XDR, and an agentic SOC analyst on the roadmap.
AutoTriage
Cross-scanner deduplication and noise reduction that cuts finding volume with a measured reduction metric — and never suppresses malware or secrets findings.