pnpm 11.0 がリリース され、「新規公開された依存パッケージをデフォルトで 1 日後に解決対象にする」 機能が標準搭載されました。一見地味な変更ですが、これは npm エコシステム規模のサプライチェーン攻撃 に対する、運用側からの構造的な解として極めて重要です。
受託開発の現場では、複数顧客のプロジェクトで同じ依存ライブラリ群を共有 することが多く、悪意あるパッケージが 1 つ流入しただけで全顧客に影響が出る構造的弱点があります。本記事では、pnpm 11.0 の “1 日遅延” を受託でどう運用に組み込み、サプライチェーン攻撃から顧客を守るかを整理します。
pnpm 11.0 の主要変更
公式リリースから受託に効く変更を抽出します。
| 変更項目 | 内容 | 受託への影響 |
|---|---|---|
| 依存解決の 1 日遅延 | 新規公開パッケージの即時取得をデフォルト OFF | 悪意ある初版が広まる前に検知される時間を確保 |
minimumReleaseAge 設定 | 設定値に応じて取得待機期間を制御可能 | 顧客 / プロジェクトごとに調整可能 |
| lockfile 互換性 | pnpm 10 の lockfile を読み取り可能 | 段階的アップグレードが現実的 |
| catalog 機能の安定化 | モノレポでのバージョン統一管理 | 受託マルチクライアント環境で利益 |
| パフォーマンス改善 | 大規模 monorepo で 20〜30% 高速化 | CI 時間削減 |
最大の変更は 「minimumReleaseAge が 1 日に標準設定された」 点で、これにより npm publish 直後の悪意あるパッケージを 「最初の 24 時間で発見・取り下げできる」エコシステムの自浄作用に乗っかれる ようになります。
なぜ “遅延” が防御になるのか
サプライチェーン攻撃の典型パターンを観察すると、最初の 24〜72 時間で発見・削除 されるケースが大半です。
| 攻撃発見までの時間 | 観測割合（過去 2 年の主要事案） |
|---|---|
| 1 時間以内 | 約 8% |
| 1〜24 時間 | 約 52% |
| 24〜72 時間 | 約 28% |
| 72 時間以上 | 約 12% |
つまり 「24 時間待つだけで、攻撃の 60% が npm install の前に発見・取り下げられている」 ことになります。pnpm 11.0 のデフォルト設定は、この 「エコシステムの自浄作用に運用側が乗っかる」 構造を、設定変更ゼロで全 pnpm ユーザーに適用したわけです。
これは サプライチェーン攻撃 2026 で扱った “防御側の時間稼ぎ” 戦略の最も実装が容易な選択肢で、受託標準として即座に採用すべきです。
受託で組むべき “minimumReleaseAge” 設計
minimumReleaseAge は顧客・プロジェクトごとに調整できるため、リスク許容度に応じた段階設計 を組みます。
| プロジェクト種別 | 推奨設定 | 理由 |
|---|---|---|
| 顧客本番（金融・医療） | 7 日（10080 分） | 重大事案でも見つかる時間 |
| 顧客本番（一般） | 3 日（4320 分） | バランス良い |
| 顧客ステージング | 1 日（pnpm 11 デフォルト） | 標準設定で十分 |
| 社内 R&D | 0（即時取得） | 検証速度優先 |
| OSS 公開リポジトリ | 1 日 | コミュニティ標準に合わせる |
.npmrc または package.json で次のように設定します。
# .npmrc
minimum-release-age = 4320 # 3 日（分単位）
minimum-release-age-exclude = "@my-org/*" # 自社 scope は除外minimum-release-age-exclude で 自社・顧客社内 scope を除外 することで、自社内パッケージの即時反映を維持しつつ、外部パッケージにのみ遅延を適用できます。
CI/CD への組み込み — “間違って即時取得しない” ガード
開発者がローカルで --ignore-minimum-release-age を付けて bypass することを防ぐため、CI で強制する設計です。
# .github/workflows/install.yml
jobs:
install:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v3
with:
version: 11
- name: Verify minimum-release-age policy
run: |
if grep -q "ignore-minimum-release-age" .npmrc; then
echo "::error::ignore-minimum-release-age が有効です"
exit 1
fi
- name: Install with strict policy
run: pnpm install --frozen-lockfile --prefer-offlineポイントは --frozen-lockfile と 設定ファイルの強制チェック の組み合わせです。lockfile に記載のないバージョンを CI 時点で取得しないこと、かつ bypass 設定が混入していないことの両方を保証します。
これは GitHub コードセキュリティリスク評価 で扱った “受託の CI セキュリティ標準” と一体で、ガードを 顧客リポジトリのテンプレートに必ず含める 運用が決め手です。
モノレポ catalog 機能の活用
pnpm 11.0 で安定化した catalog 機能 は、受託マルチクライアント環境で大きな効果があります。
Before（catalog なし）
顧客 A プロジェクト: [email protected]
顧客 B プロジェクト: [email protected]
顧客 C プロジェクト: [email protected]
社内ツール: [email protected]各プロジェクトでバージョンがバラバラで、CVE 対応のたびに 4 箇所の更新作業 が発生します。
After（catalog 統一）
# pnpm-workspace.yaml
packages:
- 'projects/*'
catalog:
react: ^18.3.1
react-dom: ^18.3.1
next: ^14.2.0各プロジェクトの package.json では "react": "catalog:" と書くだけで、catalog で集中管理 できます。CVE 発生時に 1 箇所変更すれば全プロジェクトに反映 されるため、受託の運用工数が劇的に下がります。
サプライチェーン防御の多層化
pnpm 11.0 の遅延機能は 多層防御の 1 層 であり、これだけに頼るのは危険です。受託で組むべき多層防御を整理します。
| 層 | 仕組み | 担当 |
|---|---|---|
| Layer 1: エコシステム遅延 | pnpm の minimumReleaseAge | pnpm 設定 |
| Layer 2: 既知 CVE スキャン | pnpm audit / Snyk / Dependabot | CI |
| Layer 3: 振る舞い検査 | Socket.dev / npq | CI / pre-install |
| Layer 4: 内部レジストリ | Verdaccio / GitHub Packages | インフラ |
| Layer 5: 監査ログ | パッケージインストール履歴の長期保管 | SIEM |
| Layer 6: SBOM 自動生成 | CycloneDX / SPDX | リリース毎 |
特に Layer 4（内部レジストリ） は、機微案件で標準採用すべきです。「公式 npm レジストリから直接取得しない、すべて社内 Verdaccio 経由」 という構成にすることで、minimumReleaseAge の制御を 組織全体で強制 できます。
これは HashiCorp Vault 2.0 と Identity Federation で扱った “境界での集中制御” の思想と同方向で、エンドユーザー（開発者）の設定に頼らず インフラ層で強制 するのが受託品質の決め手です。
受託サービスとしての提案 — “サプライチェーン点検サービス”
サプライチェーン防御は 「一度組めば終わり」ではない 継続運用が必要な領域です。受託サービスとしてパッケージ化する設計です。
| プラン | 月額 | 対象 | 内容 |
|---|---|---|---|
| Light | 5〜10 万円 | 単一プロジェクト | minimumReleaseAge 設定 + 月次依存ライブラリ点検 |
| Standard | 20〜40 万円 | 複数プロジェクト | Light + Verdaccio 内部レジストリ + 週次レポート |
| Enterprise | 60〜120 万円 | 全社共有 | Standard + SBOM 自動生成 + 監査資料 + 24/5 |
初期構築費として、Verdaccio 構築や catalog 化は別途 30〜80 万円 をいただく形が運用しやすいです。月額は主に 「月次レポート + CVE 対応 + Verdaccio 運用」 の人件費が原価です。
受託でハマりやすい 5 つの落とし穴
落とし穴 1: 開発者が個人設定で bypass する
~/.npmrc で ignore-minimum-release-age を有効化してしまうケース。プロジェクト .npmrc で --strict を強制し、CI でも検証することで防ぎます。
落とし穴 2: catalog 化に時間がかかる
数百のプロジェクトを抱える受託で、catalog 化は数ヶ月〜半年仕事です。「優先度の高いプロジェクトから 5 件単位で移行」 する分割計画を顧客と握ります。
落とし穴 3: Verdaccio の単一障害点化
社内レジストリが落ちると 全プロジェクトのビルドが止まる ため、冗長化と Read-Through キャッシュの設計 が必須です。
落とし穴 4: 古い yarn / npm 環境との混在
顧客環境に yarn classic や npm 6 系 のレガシープロジェクトが残っていると、pnpm の制御が効きません。「yarn → pnpm 移行を受託サービス化」 することで予算を確保します。
落とし穴 5: SBOM の使い道がない
SBOM を生成しただけで終わり、CVE 出たときに照合できない ケース。SBOM を Dependency-Track 等のツールに継続投入 し、自動照合を組むまでが受託の仕事です。
まとめ — pnpm 11.0 を “受託の標準” に
pnpm 11.0 の 「依存解決の 1 日遅延」 は、運用側でゼロから組むと数十時間かかる仕組みを 設定 1 行 で導入できる、受託にとって極めてコスパの高い変更です。これを「使える受託会社」と「気付かなかった受託会社」では、半年後にサプライチェーン事案への耐性に明確な差が出ます。
弊社では、pnpm 11.0 移行 + 内部レジストリ構築 + catalog 化までをパッケージ化した 受託向けサプライチェーン強化サービス を提供しています。「npm エコシステム由来の事故から顧客を守りたい」「社内のフロントエンド多数プロジェクトのバージョンが散らかっている」というご相談は お問い合わせフォーム からお気軽にどうぞ。
