pmg

es 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.