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.

1.	Show HN: Cynative – build your own security agents(github.com) 2 points by szin 13 days ago \| 1 comment
2.	Building Security Agents That Cannot Escape Their Trust Boundary(cynative.com) 10 points by szin 41 days ago \| 0 comments
3.	Show HN: Cynative – Read-only CLI in Go that explains your live infrastructure(github.com) 16 points by szin 56 days ago \| 4 comments

user:	szin
created:	July 14, 2026
karma:	19