PMG: An Install-Time Firewall for npm, pip and Poetry
PMG protects developers, AI agents from malicious open source packages using proxy, sandbox and SafeDep's threat intelligence feed.
At a glance
- What is it?
- SafeDep's Package Manager Guard wraps the package managers you already run and checks each install against a threat feed, a cooldown policy and an optional OS sandbox. It is free and needs no account, but it only covers ecosystems it has been taught to wrap.
- Who is it for?
- Adopt PMG if your team or your coding agents run npm, pip or poetry installs on developer machines and you want a pre-execution block without an account or a vendor contract. Do not adopt it as your only supply chain control if you need coverage for ecosystems outside the wrapped set, or if you expect it to patch vulnerable dependencies: the comparison table in the README marks known-CVE remediation PRs as absent.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap PMG fills between lockfile scanning and runtime detection
Most supply chain tooling looks at a dependency tree after someone has already written it down, or watches a process after it has started. PMG targets the moment in between: the second between typing npm install and the first line of a package's postinstall script running. The README frames the problem with named incidents, including a typosquat published as pino-sdk-v2 that mimicked the pino logger and exfiltrated environment variables, and a compromised release of the litellm AI proxy library. In each case the malicious code arrived through a normal install command, not through a dependency an auditor had flagged weeks earlier.
The intended audience is narrow and specific. It is developers who install packages on their own laptops, and the AI coding agents that now run installs on their behalf. That second group matters because an agent will happily add a package it found in a search result, and nobody reviews the diff. PMG's design assumption is that the install command itself is the choke point worth owning, which is why the project ships a shell integration rather than a CI plugin.
Interception through a shell wrapper, then three layers before execution
PMG does not patch npm or pip. It wraps them. The README describes transparent interception: PMG sits in front of npm, pip and other package managers so the developer or agent keeps typing the same command. The mechanism is a shell hook installed by pmg setup install, which the README says works across Zsh, Bash and Fish. That choice has a direct consequence: anything that bypasses the interactive shell, such as a build script invoking npm through an absolute path or a container that never sourced the hook, is not covered.
Once an install is intercepted, the README describes it passing through enabled layers in order. Layer 1 checks every package against SafeDep's threat intelligence before install and blocks known-malicious packages, with no key or login. Layer 2 is a dependency cooldown policy that blocks package versions published inside a configurable window, on the reasoning that a freshly published malicious version gets caught before most people pull it. Layer 3 is opt-in and runs installs inside OS-native sandboxes: macOS Seatbelt, Linux Landlock by default, or Bubblewrap as a fallback. After the install, PMG writes an audit log entry recording what was installed, when, and from where.
The layering is the interesting design decision. Threat intelligence is a lookup against a database that can lag a new publication by minutes or hours. Cooldown is a time-based heuristic that needs no database at all but blocks legitimate fast-moving releases. The sandbox is the only layer that still helps when the first two miss, which is why it is the one worth enabling even though it is off by default.
Getting it installed: four commands and one certificate decision
The README gives a single-line installer: curl -fsSL https://raw.githubusercontent.com/safedep/pmg/main/install.sh | sh. It also points to Homebrew and npm as alternative install methods, though the README excerpt does not spell out those package names, so check the installation section of the docs before scripting a fleet rollout.
After the binary is present, the shell wiring is pmg setup install, followed by a terminal restart. The README explicitly notes that you should re-run pmg setup install after upgrading PMG to pick up new configuration options, which is a real operational detail: an upgrade that adds a config key will not take effect in existing shells until you do. For Linux images shared by multiple users, the README documents sudo pmg setup install --system and links to docs/system-install.md.
Verification is pmg setup doctor. That is the command to run first on a new machine, and it is the one that tells you whether the hook is actually live rather than merely installed. The remaining setup decision concerns TLS. PMG inspects HTTPS traffic using a CA it injects into package managers per run. If a tool ignores CA environment variables, the README names Go on macOS and Windows as examples, you install a persistent CA instead with pmg setup cert install at user scope with no sudo, and check it with pmg setup cert status. That status command reports trust state and expiry, which matters because an expired CA is a silent failure mode for the inspection path.
The README's own smoke test is npm install --no-cache --prefer-online safedep-test-pkg@0.1.3, a benign package flagged as malicious in SafeDep's database so you can watch the block happen. The excerpt cuts off mid-sentence there, so treat the exact expected output as unverified and read the quickstart page for it.
The cooldown window is a blunt instrument and the README says so quietly
A cooldown policy trades freshness for safety. Blocking every version published inside a configurable window means a legitimate security patch released an hour ago is also blocked, and a developer who needs it has to work around PMG or wait. The README presents cooldown as a defense layer without discussing the false-positive cost, and it does not state a default window length in the excerpt. That is the first thing to check in the actual configuration reference, because a default measured in days will be felt immediately by anyone tracking a fast-moving library.
The sandbox layer has its own constraint: it is opt-in and must be configured. Landlock is the Linux default and Bubblewrap the fallback, which means the strength of the isolation depends on kernel support on the machine in question. On an older kernel without Landlock, you are relying on the fallback path. The README does not describe what happens when neither is available, and that is worth confirming before you assume the third layer is protecting anything.
The broader limitation is scope. PMG covers the package managers it wraps. If your stack includes Go modules, Cargo, Maven or a language-specific installer that shells out to a registry directly, the README's coverage list does not extend there. The comparison table in the README also marks known-CVE remediation pull requests as absent, so PMG is not a replacement for a dependency updater. It blocks malicious packages at install time; it does not tell you that the package you already depend on has a published vulnerability.
How PMG differs from Socket, safe-chain, Snyk and Dependabot
The README's comparison table is the clearest statement of positioning, and it is worth reading as a list of deliberate omissions rather than a scoreboard. Against Socket, the difference is openness: PMG is Apache-2.0 and built in public, Socket is not open source. Against safe-chain, the overlap is large. Both are open source, both need no account, both block install-time malicious packages, and both implement a dependency cooldown. The README's claimed differentiators are runtime sandboxing and transparent protection of AI coding agents, neither of which it attributes to safe-chain.
Against Snyk and Dependabot the difference is categorical rather than incremental. Those tools operate on the repository: they find known CVEs in your dependency graph and open remediation pull requests. PMG operates on the machine at install time and answers a different question, which is whether the artifact about to execute is known malware. The README's table marks both Snyk and Dependabot as lacking install-time malicious package blocking, and marks PMG as lacking CVE remediation. Neither column is a defect; they are two different jobs, and a team with a mature dependency update process still has the install-time gap that PMG addresses.
The honest reading of the table is that the sandbox and the local audit log are PMG's least replicated features. A local audit log recording what was installed, when and from where is useful for incident reconstruction on a developer laptop, a place where central logging usually does not reach.
Release cadence, licence and the cost of staying current
The repository is Apache-2.0 licensed, which permits commercial use and modification, and the README states no account or API key is required. The threat feed itself is a hosted service from SafeDep, so the free community API is a dependency you do not control even though the client is open source. If that endpoint changes its terms or its availability, the first protection layer degrades. The README does not describe an offline mode or a self-hosted feed, and that absence is worth noting for anyone in a regulated environment who needs to know where package metadata is sent.
On maintenance, the release history shows a fast cadence with both edge and stable channels: v0.29.0-edge.2 and v0.29.0-edge.1 in September 2026, following v0.28.1 about a week earlier. Edge builds appearing between stable releases suggests active development on the interception and policy layers, which is good for coverage and awkward for anyone pinning versions in a managed image. The README's instruction to re-run pmg setup install after every upgrade is the concrete cost of that cadence: each upgrade is a two-step operation, not a binary swap, and skipping the second step silently leaves you on the old configuration. For a single developer that is a minor annoyance. For a golden image built once a quarter, it is a process you have to write down.
This is not legal advice, and the licence text governs. Apache-2.0 includes a patent grant and requires preservation of notices; if you redistribute PMG inside a product, read the licence rather than this paragraph.
Editorial conclusion
Adopt PMG if your team or your coding agents run npm, pip or poetry installs on developer machines and you want a pre-execution block without an account or a vendor contract. Do not adopt it as your only supply chain control if you need coverage for ecosystems outside the wrapped set, or if you expect it to patch vulnerable dependencies: the comparison table in the README marks known-CVE remediation PRs as absent. Before rolling it out, run pmg setup doctor on one machine, confirm the shell hook survives a terminal restart, and decide whether you want the per-run CA or the persisted one from pmg setup cert install.
Community notes