本番のpackage-lockはVercel deployments APIのgit commit shaで取る

結論

ローカルの複数リポジトリを横断してnpmの依存脆弱性を定期監査するとき、対象の中に「本番のデプロイ元ブランチ」と「ふだんの作業ブランチ」が分かれて運用されているリポジトリが混じっていると、作業ツリーのpackage.json/package-lock.jsonを読む監査は本番の実体を保証しない。 本番側は既に脆弱性を直した版へ上げていても、ローカルの作業ブランチの更新が本番より遅れていれば「まだ脆弱版のまま」という誤報が続く。直し方は、ホスティング側のAPI（Vercel Deployments API）で本番に実際に乗っているデプロイのgit commit shaを取得し、そのshaでgit show <sha>:package-lock.jsonして取り出した「本番の実体」のlockfileに対してnpm auditをかけること。

症状

ローカルの複数リポジトリを横断して依存の脆弱性を見る日次の監査スクリプトがある。各リポジトリについて、package-lock.json（pnpmならそのロックファイル）を読んでnpm audit --json --package-lock-only --omit=devを実行し、critical/highの脆弱性が無いかを確認する、という作り。GitHub側でDependabotが見ているリポジトリはスキップリストに名前を列挙して対象から外し、Dependabotの無い手元リポだけをこの監査でカバーする設計になっている。

ところがスキップリストに入れたはずの、あるリポジトリで2026-10-28〜30にかけて「Next.jsが脆弱版のまま」という誤報が出た。実際には本番側は既に修正版（next 16.4.1）へ上げ済みだったが、監査は「16.2.7のまま」と報告し続けていた。

原因

このリポジトリは、本番へのデプロイ元ブランチ（deploy/*やfeat/*から都度切って出す運用）と、日常の作業ツリーが置かれているブランチが別だった。監査スクリプトは当然「ローカルにcloneされている作業ツリーのpackage.json/package-lock.json」を読むので、見ているのは「いまローカルで作業中のブランチ」の版であって、「いま本番で動いているデプロイ」の版ではない。両者が一致していれば監査結果は正しいが、作業ブランチの更新が本番の更新より遅れていると、本番は直っていてもローカルは古いまま、という食い違いが生じる。これが10/28〜30の「next 16.4.1でも16.2.7と誤報していた」の直接の原因だった。npm audit自体は渡されたlockfileを正確に読んでいるだけで、ズレていたのは「どのlockfileを渡すか」という前提の方。

直す

このリポジトリだけ、監査対象を「作業ツリーのpackage.json」ではなく「本番に実際に乗っているデプロイのsha」に差し替える関数を追加した。

# 本番デプロイのshaのlockfileを監査する（抜粋・骨格のみ）
pj = json.loads(PROJECT_VERCEL.read_text())  # .vercel/project.json
tok = json.loads(
    (Path.home() / "Library/Application Support/com.vercel.cli/auth.json").read_text()
)["token"]
req = urllib.request.Request(
    f"https://api.vercel.com/v6/deployments?projectId={pj['projectId']}&teamId={pj['orgId']}"
    "&target=production&state=READY&limit=1",
    headers={"Authorization": f"Bearer {tok}"},
)
with urllib.request.urlopen(req, timeout=30) as r:
    d = json.load(r)["deployments"][0]
sha = d["meta"]["gitCommitSha"]

with tempfile.TemporaryDirectory() as tmp:
    for f in ("package.json", "package-lock.json"):
        (Path(tmp) / f).write_text(sh(["git", "-C", str(REPO_DIR), "show", f"{sha}:{f}"]))
    # ここで取り出したlockfileに対してnpm auditをかける
    subprocess.run(["npm", "audit", "--json", "--package-lock-only", "--omit=dev"], cwd=tmp, ...)

ホスティング側のDeployments API（VercelならGET /v6/deployments?...&target=production&state=READY&limit=1）を叩くと、いま本番に実際に乗っているデプロイのメタデータが返り、meta.gitCommitShaにそのデプロイのコミットshaが入っている。そのshaを使ってgit show <sha>:package.json / git show <sha>:package-lock.jsonを実行すれば、ローカルで今どのブランチをcheckoutしているかに関係なく「本番にデプロイされた時点のファイルの中身」をテキストとして取り出せる。これを一時ディレクトリに書き出し、そこを作業ディレクトリにしてnpm audit --json --package-lock-only --omit=devをかければ、監査対象は常に「本番の実体」になる。

変更後、このリポジトリの監査だけ「作業ツリー基準」ではなく「本番デプロイのsha基準」に切り替わった。ローカルの作業ブランチが本番よりどれだけ遅れていても、監査結果は本番で実際に動いている依存バージョンを指すようになる。

再発防止

横断監査スクリプトの元の前提は「ローカルにcloneされたリポジトリの作業ツリー＝本番で動いているもの」だった。mainブランチからそのままデプロイする運用のリポジトリでは、これは成立する。問題が起きたのは、デプロイ元ブランチと日常の作業ブランチを意図的に分けている運用のリポジトリだけで、しかもこの前提のズレは監査スクリプト側からは見えない——npm auditはエラーも警告も出さず、渡された作業ツリーの版を正確に報告するだけなので、見ている対象自体が本番とズレていることには気づけない。

複数リポジトリを同じやり方でまとめて見る横断監査のような仕組みを作るときは、個々のリポジトリの運用（デプロイ元ブランチが固定か、作業ブランチと一致する前提が本当に成立するか）を暗黙に仮定しない方がいい。本番の実体を指す基準（デプロイAPIが返すgit commit shaなど）が取れるリポジトリについては、作業ツリーではなくそちらを監査対象にする方が、ブランチ運用の都合に左右されずに済む。