# PMG concedes one row in its own comparison table

> A package manager firewall that intercepts installs and checks them against a community threat feed before code runs, with a cooldown policy for what the feed has not seen. It is candid about the one capability it lacks.

**safedep/pmg** — PMG protects developers, AI agents from malicious open source packages using proxy, sandbox and SafeDep's threat intelligence feed.

- Repository: https://github.com/safedep/pmg
- Website: https://safedep.io
- Stars: 540 · Forks: 43
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/safedep-pmg

## Three layers, and only the first two are on by default

The protection stack is described as defence in depth, and the layers differ in whether you have to ask for them. Layer one is threat intelligence: every package is checked against SafeDep's real-time feed before install, known malicious packages are blocked, and no key or login is required. Layer two is policy, expressed as a dependency cooldown that blocks versions published inside a configurable window. Layer three is an opt-in sandbox. When it is enabled and configured, installs run inside an OS-native sandbox so that install scripts have restricted system access even if something slips past the first two layers. Audit logging sits alongside the layers rather than inside them, recording every install with what was installed, when, and from where. So the default posture is feed plus time window, and the sandbox is the layer you add when you decide the first two are not enough.

## Cooldown is the answer to malware nobody has catalogued

The threat feed can only block what it knows about, so the interesting question is what happens for the rest. The documentation answers it directly: for unknown malware, PMG uses dependency cooldown and the opt-in sandbox as proactive defence. Cooldown is a time-window rule rather than a content rule. If a version was published inside the window you configured, it does not install, whether or not anyone has flagged it. That is a genuinely different kind of protection from a blocklist, because it does not require anyone to have noticed the package first, and it is the layer that would stop a malicious version pushed to a legitimate package minutes after a maintainer account was taken over. The cost is symmetric and worth stating plainly: a legitimate fresh publish is inside the same window, so the setting trades freshness for exposure, and how to pick the value is not something this README answers.

## Interception is transparent, and setup has to be re-run after an upgrade

The design assumption is that nobody changes their habits. PMG wraps npm, pip and other package managers, and developers and agents keep running the same commands with no workflow changes. Shell support covers Zsh, Bash and Fish. Installing it is a single piped script, and wiring it into your shell is one more:

```bash
pmg setup install
# Restart your terminal to apply changes
```

then a restart, and a validation step:

```bash
pmg setup doctor
```

The tip worth noticing is the one about upgrades. Re-running the setup command after upgrading PMG is how you pick up new configuration options, which means the shell integration file is regenerated by the tool rather than being something you maintain. For images and all-users installs there is a separate system scope: the same command with a system flag, run under sudo on Linux or as administrator on Windows. The doctor command exists because the failure mode of a wrapper is silence: if the interception is not actually in your path, everything looks normal and nothing is checked.

## HTTPS inspection needs an injected CA, and Go is the named exception

PMG inspects HTTPS traffic, which means a certificate authority in the path. The default model is an on-the-fly CA injected into package managers per run, so nothing persists between sessions. There is a second option for when that does not work. You can install a single CA once, trust it in your operating system trust store, and check its state and expiry:

```bash
pmg setup cert install          # user scope, no sudo
pmg setup cert status           # check trust state and expiry
```

The stated reason for the persistent option is precise rather than general: some tools ignore the CA environment variables a per-run injection relies on, and Go on macOS and Windows is the example given. So the fallback exists for a specific toolchain rather than as a matter of taste. Two details make it manageable. The user scope needs no elevated privileges, so you are not adding a machine-wide trusted root to check package installs. And a separate document covers scopes, rotation and removal, which is what you want from any tool that touches your trust store.

## Nine Node commands, five Python ones, and three names nobody explains

The supported tools table is where you find out whether your habits are covered. For Node it lists install and add forms for npm, pnpm, yarn and bun, plus three execution forms whose names do not correspond to anything widely known. For Python it lists pip install, pipx run, poetry add, uv add and uvx. The mainstream entries are the ones you would expect, and covering four Node package managers and five Python entry points is genuinely broad. Three of the Node entries stand out because nothing else in the documentation explains them, and an agent reading this table will not know whether they are real tools, internal aliases or a naming experiment. The dependency list gives a partial answer at the other end of the stack: the sandbox on Linux is a Go library rather than a wrapper script, the HTTPS interception is a Go proxy library, and there is a product analytics client in the same list, which is worth knowing about before you install something that sits in your shell path.

## The sandbox test seeds two classes of secret with opposite expectations

The end-to-end test for the sandbox is the most revealing artefact in the repository, and it works by seeding credentials and then checking which ones survive. The Makefile target sets a seeded flag, then assigns a canary value to six credentials: a source control token in two spellings, a cloud access key, a service account token, a second cloud API token, and a package publishing password. Two more are assigned a different value whose name marks it as the one that should persist: an npm token and a node auth token. Then it runs the built binary with sandbox and enforce flags, driving a Node script through the package manager. Two classes of secret, two expectations. The six should be stripped, because no install script has a reason to see them. The two should survive, because the package manager legitimately needs them to fetch anything.

## The comparison table has eight rows and PMG ticks seven

The comparison against four other tools is eight rows, and PMG ticks seven of them. It claims open source with a public build, no account or key, install-time blocking, the cooldown policy, runtime sandboxing, transparent protection of coding agents, and local audit logs. It does not tick known-CVE remediation pull requests, and that is the one row the two commercial tools in the table are built around. Reading the whole grid tells you the market splits in two. PMG and one alternative are install-time tools that intervene before code runs; the two commercial tools intervene after a dependency is already in your tree. The row where they overlap, automatic remediation, is the row PMG concedes. The claim above the table that it is the only free open-source install-time firewall covering both developers and agents is a positioning statement about its own combination, not a survey.

## Conclusion

Use PMG if your exposure is at install time, which is the moment a compromised package runs code you never reviewed, and if you let an agent run package managers on your behalf. Before you rely on it, decide whether the cooldown window fits your release cadence, since a legitimate fresh publish will also be inside that window, and know that the sandbox is opt-in rather than on by default. Read the comparison table as a positioning statement rather than a neutral survey, since the one row it loses is the row two commercial tools are built around.

## FAQ

### What does PMG do when I run npm install?

It intercepts the install transparently and checks the package before code runs. The package is checked against a community threat feed, versions published inside your configured cooldown window are skipped, and an audit record of what was installed and when is written.

### What is dependency cooldown in PMG?

A time-window policy that blocks package versions published inside a configurable window, so recently compromised versions are skipped. It is the layer that addresses unknown malware the threat feed has not catalogued, and it also blocks legitimate fresh publishes.

### Does PMG need an account or API key?

No. The documentation states it requires no account and no API key, using a free community API for threat intelligence, and it is Apache 2.0 licensed.

### Which package managers does PMG intercept?

For Node it lists npm, pnpm, yarn, bun and three execution forms whose names are not otherwise explained. For Python it lists pip, pipx, poetry, uv and uvx. The README does not expand the three unexplained Node entries.

### What sandboxes does PMG use?

OS-native ones. macOS uses Seatbelt, Linux uses Landlock by default with a Bubblewrap fallback, and the sandbox layer is opt-in rather than enabled by default.

### Does PMG fix known CVEs for me?

No, and its own comparison table concedes this. Known-CVE remediation pull requests are the one row where PMG is unticked and the two commercial tools in the comparison are ticked, because those tools act on dependencies already in your tree.

## Sources

- [License: Apache-2.0](https://github.com/safedep/pmg/blob/main/LICENSE)
- [Project website](https://safedep.io)
- [README](https://github.com/safedep/pmg/blob/main/README.md)
- [Releases](https://github.com/safedep/pmg/releases)
- [safedep/pmg on GitHub](https://github.com/safedep/pmg)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/safedep-pmg