GitHub Repository

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

467 starsGo

PMG, open source package firewall

Name: PMG, open source package firewall
Availability: InStock
Author: abhisek

by abhisek·Jul 21, 2026·2 points·1 comment

Visit Project View on HN

AI Analysis

●●●BangerSolve My ProblemCrowd Pleaser

Local proxy blocking malicious installs before execution beats post-install scanning tools.

Strengths

•Intercepts package manager traffic directly, preventing malicious code execution before it happens.
•Zero-config setup works across npm, pip, and poetry without modifying existing CI/CD pipelines.
•Leverages real-time threat intelligence feeds to block both known malware and typosquatting attacks.

Weaknesses

•Relies on external threat intelligence feeds, offering limited protection against zero-day unknown threats.
•Adding a local proxy introduces a potential single point of failure for all package installation workflows.

Post Description

Hi HN

I am the founder of SafeDep. We have been detecting malicious packages for a while. Coming from DevSecOps background, I always considered malicious package detection & protection to be a build stage problem. But I was wrong since the S1ngularity and early Shai-Hulud days.

In 2026, we pretty much started worrying more about our own dev machines than CI/CD environment. Depending only on threat intelligence data (OSV / SafeDep / Socket / any other source) to protect our own dev machines did not feel right. We wanted to build a multi-layered protection that can get 100% visibility of OSS packages coming in, and can protect against known and “hopefully” unknown threats. That’s how Package Manager Guard (PMG) started. Core idea was simple:

- Start a local proxy (localhost)

- Make sure supported package managers like npm, pnpm, pip etc. goes through it

- Use threat intelligence data to fail fast on known malicious packages

- Apply policies like dependency cooldown as additional guardrails

- Adopt a policy language like CEL to support custom policies (roadmap)

- Everything stays local with stackable policies and audit log

- Threat model - Protect “willing” developers against malicious open source packages

Note: PMG does not consider a malicious developer as part of its threat model. So no real effort has been put to “enforce”, rather the goal is reduced friction while being effective.

Then came across Anthropic’s SRT and suddenly realized that in-process OS-native sandboxing is a good solution for limiting blast radius against unknown threats, especially since package managers have predictable runtime behaviour that can be allowed via. a sandbox while denying larger user permissions. Adopted seatbealt on MacOS and Landlock + Seccomp BPF for Linux. Seccomp BPF with Go was a battle of its own due to lack of control on OS threads, but finally managed to get it working without major performance cost.

To summarize, PMG does not only depend’s on SafeDep’s ability to find malicious packages. It enforces dependency cooldown (useful if you are stuck with older npm/pnpm), sandbox to protect against malicious packages. Our near term goal is to support CEL as a policy language and improve tooling around sandbox rules to make adoption easier.

Any feedback is welcome.