PMG：把 npm 和 pip 安装变成可拦截的安全边界
现在的开发流程里，npm install 和 pip install 已经不只是人类敲的命令了。AI coding agent 会为了跑测试、补依赖、生成 demo，自己去执行安装命令；CI、preview environment、一次性的 shell session 也会不断拉包。问题是，包管理器安装依赖这件事本身就是一条代码执行路径：postinstall script、setup hook、transitive dependency、刚发布的新版本，都可能在你认真 review 代码以前先跑起来。
安全工具通常会从 lockfile、SBOM、CVE 或 pull request 开始检查，这些都重要，但它们不一定卡在“安装发生之前”。如果一个 agent 在临时分支里跑了一个被污染的包，事后报告再完整，也已经晚了一步。更实用的防线应该贴近包管理器本身：让平时的 npm install express、pip install requests 仍然像原来一样输入，但中间多一层能够拦截、判断和记录的 guard。
今天看的是 safedep/pmg。PMG 是 Package Manager Guard 的缩写，README 里把它定位成面向 npm 和 pip 包的 install-time 防线：通过透明拦截包管理器命令，在包代码执行前检查 SafeDep 的威胁情报、应用 dependency cooldown policy，并可选地把安装过程放进 OS-native sandbox。它特别把 AI coding agents 写进了威胁模型：agent 仍然使用普通包管理器命令，但命令会先经过 PMG。
按 GitHub repository API、README、LICENSE、Releases、Tags、go.mod 和最近 commits 在 2026-08-15 能核验的公开信息，safedep/pmg 当前有 492 stars、35 forks。仓库主语言是 Go，GitHub repository API 报告许可证为 Apache-2.0，LICENSE 文件也是 Apache License 2.0 文本。仓库创建于 2025-03-20 02:29:47 UTC，最近公开 push 是 2026-08-15 09:45:41 UTC，默认分支是 main。最新 GitHub Release 是 v0.25.0，发布时间 2026-07-27 12:22:49 UTC，release assets 包括 macOS、Linux 和 Windows 构建以及 checksums。最近 commit 是 75f5cca，信息为 “feat: Add Network Policy Enforcement for Linux Landlock (#401)”。go.mod 的 module 是 github.com/safedep/pmg，声明 Go 版本 1.25.1。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | safedep/pmg |
| 定位 | 包管理器安装阶段的恶意包拦截与审计工具 |
| Stars | 492 |
| Forks | 35 |
| 主要语言 | Go |
| 许可证 | Apache-2.0 |
| 创建时间 | 2025-03-20 02:29:47 UTC |
| 最新 push | 2026-08-15 09:45:41 UTC |
| 默认分支 | main |
| 最新 GitHub Release | v0.25.0，2026-07-27 12:22:49 UTC |
| 最近 commit | 75f5cca，feat: Add Network Policy Enforcement for Linux Landlock (#401) |
| 关键词 | supply-chain security、npm、pip、sandbox、cooldown、AI agents |
它守的是“安装前”这一刻
PMG 的切入点很窄，也因此有价值。它不是另一个通用漏洞扫描器，而是把包管理器调用变成一个可插入控制面的入口。README 里列出的默认保护层包括 transparent interception、SafeDep threat intelligence、dependency cooldown、opt-in sandbox 和 audit logging。换句话说，它关心的是：在包被下载、解析、执行安装脚本之前，能不能先问一句“这个东西现在可以装吗”。
这对 npm 和 Python 生态尤其现实。JavaScript 包经常有 install script；Python 包也可能通过构建步骤、setup 逻辑或 native extension 进入执行路径。即便你只是在试一个 demo，安装动作也可能读环境变量、碰 SSH key、访问 home 目录或打网络请求。人类开发者还有可能停下来想一想，agent 则更容易把“安装缺失依赖”当作普通修复步骤。
PMG 的方式是让开发者和 agent 继续使用原来的命令。README 说它覆盖 npm、pnpm、yarn、bun、npx、pnpx，Python 侧覆盖 pip、pipx、poetry、uv、uvx。这比“大家请记得用另一个安全命令”更可靠，因为真正危险的时候，人通常不会记得切换工具，agent 更不会。
cooldown policy 比只看已知恶意名单更务实
威胁情报能挡住已知恶意包，但供应链攻击最麻烦的地方在于时间差。一个包刚刚被劫持、一个版本刚刚发布、一个维护者 token 刚刚泄露时，外部数据库不一定已经有结论。PMG 的第二层是 dependency cooldown：可以阻止安装刚发布不久的版本，让组织用时间窗口换一点观察期。
这个设计不复杂，但很工程化。很多团队其实不需要每个人都第一时间装到最新 patch，尤其是 AI agent 自动拉依赖的场景。把“刚发布 30 分钟、2 小时或 24 小时内的版本”挡一挡，可能会错过一点新鲜度，但能降低踩到刚被投毒版本的概率。
它也不会取代正常的 dependency update 流程。更好的搭配是：日常开发机和 agent shell 由 PMG 拦住高风险安装；正式升级依赖仍然通过 lockfile diff、CI、测试、SCA、review 来完成。PMG 处理的是第一道门，不是整套供应链治理。
sandbox 是兜底，而不是魔法
README 里另一个值得注意的点是 opt-in sandbox。PMG 在配置后可以用 OS-native sandbox 运行安装过程：macOS 上是 Seatbelt，Linux 上默认 Landlock，也可以 fallback 到 Bubblewrap。最近的 commit 还在继续推进 Linux Landlock 的网络策略约束，这说明项目并不只是在做一个薄薄的 CLI wrapper。
Sandbox 的意义是承认前两层一定会漏。恶意包可能还没有进入威胁情报，cooldown policy 也可能被例外放行。此时限制安装脚本能碰什么文件、能不能访问网络、能不能越过预期目录，就成了最后的损害控制。对 agent 来说这尤其重要，因为 agent 经常在一个已经登录 GitHub、云服务、包 registry 的开发环境里工作。
但这也意味着 PMG 不是装上就万事大吉。Sandbox 需要配置和验证，不同 OS 的能力边界也不一样。README 里提供了 pmg setup doctor，并说明 HTTPS inspection 会用按次注入的 CA，必要时可以把 CA 安装到 OS trust store。团队如果要把它放进黄金镜像或共享开发环境，应当把这些步骤写进 bootstrap，而不是靠个人手动记忆。
试用路径比较直接
最短路径很像一个普通 CLI 工具：
curl -fsSL https://raw.githubusercontent.com/safedep/pmg/main/install.sh | sh
pmg setup install
pmg setup doctorREADME 还给了一个良性的测试包 safedep-test-pkg@0.1.3，用于确认拦截是否生效。日常使用时，命令仍然是 npm install express 或 pip install requests。PMG 坐在路径中间，记录每次安装的包、时间和来源，并在风险命中时阻止安装继续。
这个“透明”很关键。很多安全工具最大的问题不是能力不够，而是开发者和 agent 不在那条路径上。PMG 如果能稳定地挂在 shell 初始化和包管理器调用之间，就更接近一个环境能力，而不是另一个需要大家主动记得运行的检查命令。
Caveats
第一，PMG 依赖 SafeDep 的社区威胁情报 API。README 说不需要账号或 API key，这降低了使用门槛；但它仍然意味着一部分判断来自外部服务。离线环境、强合规网络或对外请求受限的企业环境，需要提前评估它的网络路径、缓存策略和失败模式。
第二，透明代理和 HTTPS inspection 会改变包管理器流量路径。这个方向本身合理，但也更容易遇到公司代理、自签证书、registry mirror、private package registry、CI sandbox 的兼容性问题。真正上线前，应该用团队实际的 npmrc、pip config、poetry source、uv 配置跑一轮。
第三，它不是 CVE 修复工具。README 的对比表也把 known-CVE remediation PRs 标成不是 PMG 的能力。它更像安装阶段的 package firewall 和 audit trail。已有的 Dependabot、Snyk、OSV、lockfile review、artifact signing 仍然需要各司其职。
总结
safedep/pmg 有意思的地方，是它把供应链安全放到了一个经常被忽略的瞬间：包管理器准备执行安装代码之前。对人类开发者，这是给日常安装加一层摩擦很低的安全网；对 AI coding agent，这是把自动安装依赖这件事从“完全信任 shell”变成“先过一个可审计的关口”。
它还不是一套完整的企业依赖治理平台，也不应该被当成替代品。但作为开发机、CI 临时环境和 agent workspace 的第一道 install-time guard，PMG 的边界很清楚：拦已知恶意包，延迟刚发布的新版本，把安装动作放进可选 sandbox，并留下审计日志。对正在让 agent 更频繁运行 shell 命令的团队来说，这个位置值得认真看一眼。