PMG：npm と pip の install を止められる境界にする
今の開発環境では、npm install や pip install は人間だけが打つ command ではなくなっている。AI coding agent は test を走らせるため、missing dependency を補うため、demo を作るために、自分で install command を実行する。CI、preview environment、一時的な shell session も絶えず package を引いてくる。問題は、package manager の install 自体が code execution path だということだ。postinstall script、setup hook、transitive dependency、出たばかりの version は、こちらが真面目に code review する前に動き始める。
Security tool は lockfile、SBOM、CVE、pull request から検査することが多い。それらは重要だが、必ずしも「install が起きる前」に立っているわけではない。Agent が temporary branch で汚染された package を実行したあとでは、後から report が出ても一歩遅い。より実用的な防線は package manager そのものに近い場所にある。普段どおり npm install express、pip install requests と入力しながら、その間に intercept、judge、record できる guard を挟む形だ。
今日見るのは safedep/pmg。PMG は Package Manager Guard の略で、README では npm と pip package 向けの install-time defense と位置づけられている。Package manager command を transparent に intercept し、package code が実行される前に SafeDep の threat intelligence を確認し、dependency cooldown policy を適用し、必要なら OS-native sandbox の中で install を走らせる。Threat model には AI coding agents も明示的に入っている。Agent は普通の package manager command を使い続けるが、その command は先に PMG を通る。
GitHub repository API、README、LICENSE、Releases、Tags、go.mod、recent commits を 2026-08-15 時点で確認すると、safedep/pmg は 492 stars、35 forks。主要言語は Go。GitHub repository API は license を Apache-2.0 と報告しており、LICENSE file も Apache License 2.0 text だ。Repository created time は 2025-03-20 02:29:47 UTC、latest public push は 2026-08-15 09:45:41 UTC、default branch は main。最新 GitHub Release は v0.25.0、published time は 2026-07-27 12:22:49 UTC。Release assets には macOS、Linux、Windows build と checksums が含まれる。Recent commit は 75f5cca、message は “feat: Add Network Policy Enforcement for Linux Landlock (#401)”。go.mod の module は github.com/safedep/pmg、declared Go version は 1.25.1 になっている。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | safedep/pmg |
| 位置づけ | package manager の install 段階で malicious package を止め、監査する tool |
| Stars | 492 |
| Forks | 35 |
| 主要言語 | Go |
| ライセンス | Apache-2.0 |
| 作成日時 | 2025-03-20 02:29:47 UTC |
| Latest push | 2026-08-15 09:45:41 UTC |
| Default branch | main |
| 最新 GitHub Release | v0.25.0、2026-07-27 12:22:49 UTC |
| Recent commit | 75f5cca、feat: Add Network Policy Enforcement for Linux Landlock (#401) |
| キーワード | supply-chain security、npm、pip、sandbox、cooldown、AI agents |
守っているのは「install 前」の一瞬
PMG の入口は狭い。だからこそ価値がある。これはもう一つの汎用 vulnerability scanner ではなく、package manager の呼び出しを control plane に変える tool だ。README に出てくる default protection layers は transparent interception、SafeDep threat intelligence、dependency cooldown、opt-in sandbox、audit logging。つまり関心は、package が download され、解決され、install script を実行する前に「これは今 install してよいのか」と聞けるかどうかにある。
これは npm と Python ecosystem ではかなり現実的だ。JavaScript package には install script がよくある。Python package も build step、setup logic、native extension から execution path に入ることがある。単に demo を試しているだけでも、install action は environment variable を読み、SSH key に触り、home directory を見るかもしれないし、network request を投げるかもしれない。人間の developer なら一度止まって考える余地があるが、agent は「missing dependency を install する」ことを普通の修復作業として扱いやすい。
PMG のやり方は、developer と agent に元の command を使わせ続けることだ。README では npm、pnpm、yarn、bun、npx、pnpx、Python 側では pip、pipx、poetry、uv、uvx を対象に挙げている。これは「安全な別 command を忘れずに使ってください」よりずっと現実的だ。本当に危ない瞬間ほど、人は tool を切り替えないし、agent はなおさら切り替えない。
cooldown policy は既知悪性リストだけより実務的
Threat intelligence は known-malicious package を止められる。しかし supply-chain attack で厄介なのは時間差だ。ある package が乗っ取られた直後、ある version が出た直後、maintainer token が漏れた直後には、外部 database がまだ結論を持っていない可能性がある。PMG の二つ目の層は dependency cooldown だ。出たばかりの package version を configurable な時間窓で止め、organization が少し観察する時間を買える。
この design は複雑ではないが、かなり engineering らしい。多くの team は、全員が毎回最新 patch を即座に取る必要はない。特に AI agent が自動で dependency を引く場面ではそうだ。「公開から 30 分、2 時間、24 時間以内の version」を少し止めるだけで、鮮度は少し落ちるが、投毒されたばかりの version を踏む確率は下げられる。
もちろん通常の dependency update process を置き換えるものではない。組み合わせとしては、developer machine と agent shell では PMG が高リスクな install を止め、正式な dependency upgrade は lockfile diff、CI、test、SCA、review で処理する、という形が自然だ。PMG は第一関門であって、supply-chain governance 全体ではない。
sandbox は最後の受け皿で、魔法ではない
README でもう一つ目立つのは opt-in sandbox だ。PMG は設定すれば OS-native sandbox の中で install を走らせられる。macOS では Seatbelt、Linux では default で Landlock、必要なら Bubblewrap fallback を使う。最近の commit でも Linux Landlock の network policy enforcement が追加されており、単なる薄い CLI wrapper だけを作っているわけではないことが分かる。
Sandbox の意味は、前二層が必ず漏れると認めることにある。Malicious package がまだ threat intelligence に入っていないかもしれない。Cooldown policy も例外で通すことがあるかもしれない。そのとき install script がどの file に触れるか、network access を持つか、想定 directory を越えられるかを制限することが最後の damage control になる。Agent では特に重要だ。Agent は GitHub、cloud service、package registry に login 済みの development environment で動くことが多いからだ。
ただし、PMG を入れれば終わりではない。Sandbox は設定と検証が必要で、OS ごとの能力境界も違う。README には pmg setup doctor があり、HTTPS inspection は run ごとに注入する CA を使い、必要なら CA を OS trust store に入れられると説明されている。Team が golden image や shared development environment に入れるなら、この手順を bootstrap に組み込むべきで、個人の記憶に任せるべきではない。
試し方はかなり直接的
最短経路は普通の CLI tool に近い。
curl -fsSL https://raw.githubusercontent.com/safedep/pmg/main/install.sh | sh
pmg setup install
pmg setup doctorREADME には良性の test package として safedep-test-pkg@0.1.3 も用意されており、blocking が効いているかを確認できる。日常では、command は変わらない。npm install express や pip install requests をそのまま使う。PMG が path の間に座り、install された package、時刻、実行元を記録し、risk が hit したときは install を止める。
この transparent さは大事だ。多くの security tool の最大の問題は、能力ではなく、developer と agent がその path にいないことだ。PMG が shell initialization と package manager invocation の間に安定して入れるなら、それは「みんなが忘れずに実行する check command」ではなく、environment capability に近づく。
Caveats
第一に、PMG は SafeDep の community threat intelligence API に依存する。README では account も API key も不要とされており、導入障壁は低い。一方で、判断の一部が external service から来ることは変わらない。Offline environment、厳しい compliance network、outbound request が制限された企業環境では、network path、cache strategy、failure mode を先に評価したい。
第二に、transparent proxy と HTTPS inspection は package manager traffic の経路を変える。この方向は合理的だが、company proxy、self-signed certificate、registry mirror、private package registry、CI sandbox との compatibility issue も出やすい。実運用前には、team が実際に使っている .npmrc、pip config、poetry source、uv configuration で一度通すべきだ。
第三に、これは CVE remediation tool ではない。README の comparison table でも known-CVE remediation PRs は PMG の能力ではないとされている。これは install phase の package firewall と audit trail である。Dependabot、Snyk、OSV、lockfile review、artifact signing などは、それぞれの場所で引き続き必要になる。
まとめ
safedep/pmg が面白いのは、supply-chain security を見落とされがちな一瞬に置いているところだ。Package manager が install code を実行しようとする直前である。人間の developer にとっては、日常の install に friction の低い安全網を足すものになる。AI coding agent にとっては、自動で dependency を入れる行為を「shell を完全に信用する」状態から「まず audit 可能な gate を通す」状態に変える。
これは完全な enterprise dependency governance platform ではないし、そう扱うべきでもない。ただし developer machine、CI の temporary environment、agent workspace の first install-time guard としては境界がはっきりしている。Known-malicious package を止め、出たばかりの version を遅らせ、install action を optional sandbox に入れ、audit log を残す。Agent に shell command を任せる頻度が増えている team なら、この位置は真面目に見る価値がある。