safedep/pmg: an install-time package firewall for npm, pip and poetry

What PMG actually intercepts, and for whom

The README frames the problem in one line: every `npm install` or `pip install` executes code nobody reviewed. PMG's answer is not a scanner you run in CI. It is a wrapper around the package manager binaries themselves, so the same command a developer or an AI coding agent types is routed through PMG first. The README states it covers `npm`, `pip` and `poetry add`, and that it works across Zsh, Bash and Fish.

The intended user is a developer working on a laptop, or a team running coding agents that install dependencies without a human reading the diff. The README lists the incidents that motivate this: a compromised `litellm 1.82.8`, a hijacked `telnyx 4.87.2` on PyPI, a typosquat called `pino-sdk-v2`, and a campaign it names Mini Shai-Hulud affecting more than 300 npm packages. PMG's pitch is that the check happens before install scripts run, not after a lockfile diff lands in review.

It is not a vulnerability scanner. The comparison table in the README marks known-CVE remediation pull requests as absent, and that row is the honest boundary of the product.

Three layers between the command and the install script

The README describes a defense-in-depth pipeline with three layers, plus audit logging after the fact.

Layer 1 is threat intelligence. Every package is checked against SafeDep's real-time feed before install, and known-malicious packages are blocked. The README says no key and no login are required, which is why the tool can be dropped onto a machine without procurement.

Layer 2 is a policy layer the README calls dependency cooldown. It blocks package versions published inside a configurable window. The reasoning is that a freshly compromised release is usually yanked within hours or days, so refusing to install anything too new sidesteps the window when the malicious version is live. This is the layer most likely to annoy people, since it deliberately delays legitimate releases too.

Layer 3 is opt-in sandboxing. When enabled and configured, installs run inside OS-native sandboxes: macOS Seatbelt, Linux Landlock by default, or Bubblewrap as a fallback. The go.mod file confirms this is real code rather than a wrapper script: it depends on `github.com/landlock-lsm/go-landlock` and `github.com/elazarl/goproxy`, and the repository has top-level `sandbox/`, `proxy/` and `truststore/` directories.

That proxy dependency explains the certificate note in the README. PMG inspects HTTPS traffic with an on-the-fly CA injected into package managers per run. For tools that ignore CA environment variables, the README names Go on macOS and Windows, you can persist a single CA with `pmg setup cert install` and check it with `pmg setup cert status`.

Installing PMG and confirming it is wired in

The README gives a one-line install script. It downloads and runs the installer from the main branch of the repository.

curl -fsSL https://raw.githubusercontent.com/safedep/pmg/main/install.sh | sh

The README also mentions Homebrew and npm as alternative methods, pointing to an Installation section that is truncated in the repository's README extract, so check the docs for those exact commands rather than guessing at a formula or package name.

Next, wire PMG into your shell so it intercepts package managers. The README is explicit that you must restart your terminal afterwards.

pmg setup install

If you upgrade PMG later, the README's tip is to re-run `pmg setup install` to pick up new configuration options. On Linux golden images or all-users setups, the documented variant is:

sudo pmg setup install --system

Before trusting any of it, run the doctor command. This validates the installation and checks that protection is working.

pmg setup doctor

The README's own smoke test uses a benign package that SafeDep's database flags as malicious, so you can see a block without touching real malware:

npm install --no-cache --prefer-online [email protected]

Expect PMG to intercept that install and block it. If the package installs normally, your shell is not wired and nothing else in the tool matters.

Where PMG will get in your way

The cooldown layer is the obvious friction point. Blocking versions published inside a window means that on release day, your dependency upgrade fails, and the failure is intentional. Teams that pin aggressively and upgrade on a schedule will barely notice. Teams that chase upstream fixes within hours will notice constantly, and the README does not describe a documented bypass for a single trusted install, so plan for the cooldown window to be tuned rather than fought.

The sandbox is opt-in and, per the README, only runs when enabled and configured. That means the default install gives you threat intelligence and cooldown, not process isolation. If your threat model assumes a malicious package will slip past a feed that cannot know about a zero-hour compromise, you need the sandbox enabled, and the README's own E2E target in the Makefile shows what that requires: a supported driver, Seatbelt on macOS or Bubblewrap or Landlock on Linux, plus node for the test. On a machine without those primitives, the third layer is unavailable.

There is also a structural limit worth stating plainly. PMG blocks known-malicious packages. A brand-new package that no feed has seen yet is, by definition, not known-malicious, and the cooldown is the only thing standing between it and your machine. The tool reduces the window; it does not close it.

PMG against safe-chain and Socket

The README's own comparison table is the most useful starting point, and it is candid about the differences.

safe-chain is the closest open-source alternative. Both are free and need no account, both do install-time blocking, and both offer a cooldown policy. The README marks runtime sandboxing and local audit logs as absent in safe-chain, and those are the two capabilities that separate the tools. If you only want a blocklist check in front of npm, the extra machinery in PMG buys you nothing.

Socket is the commercial comparison. It has install-time blocking and no account requirement, but the README marks it as not open source, without cooldown and without sandboxing. The trade is different: Socket is a hosted product with a team behind it, while PMG is a binary you install and configure yourself.

Snyk and Dependabot sit in a different category entirely. The README's table gives them known-CVE remediation pull requests and marks install-time malicious package blocking as absent. They tell you about known vulnerabilities in dependencies you already have. PMG tries to stop a package from executing in the first place. If your problem is an outdated transitive dependency, neither PMG nor safe-chain is the tool you want.

Licence, releases and what upgrading costs you

PMG is Apache-2.0, and the Dockerfile labels the image with the same identifier. For most teams that means permissive use with the usual obligations around notices and attribution; the LICENSE file in the repository root is the authoritative text, and this is not legal advice.

The release history shows two channels in practice. The recent tags include `v0.28.1` alongside `v0.29.0-edge.1` and `v0.29.0-edge.2`, so edge builds are published separately from the numbered release. The last push to the repository was on 2026-09-10, and `v0.29.0-edge.2` was tagged the same day, so the project is moving. That also means the interface you script against can shift between minor versions, which is exactly why the README tells you to re-run `pmg setup install` after an upgrade. Treat that step as part of the upgrade procedure, not an optional tip: a new configuration option that your shell never picks up is a silent gap in coverage.

The repository ships a Dockerfile that builds a static binary with `CGO_ENABLED=0` and copies it to a Debian slim image with `ENTRYPOINT ["pmg"]`. That is useful for CI, but note what it implies: the interception and sandbox layers depend on the host shell and OS primitives, so a containerised PMG is not automatically protecting installs happening on a developer laptop.

Editorial conclusion

Adopt PMG if you run npm, pip or poetry on developer machines or in agent-driven workflows and want a free check before install scripts execute. Skip it if you need CVE remediation pull requests or a hosted dashboard with per-team policy; it does not do either. Verify first that `pmg setup doctor` reports the interception layer as healthy in your shell, because an unwired shell means no protection at all.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. safedep/pmg on GitHub