package-security-check

パッケージセキュリティチェック

ワークフロー

1. まず、基本的な JavaScript のサプライチェーンチェックとして扱ってください。特定の CVE、ベンダー、パッケージファミリー、インシデントに合わせて結果を無理に調整しないでください。
2. インストール、パッケージマネージャーの変更コマンド、またはファイル編集を行う前に、読み取り専用の調査のみを実施し、信号機形式で問題分析を提示してください。
   • 🔴 ブロッカー：侵害の兆候、安全でないインストール経路、シークレットの露出、または未レビューのコード実行を許可するポリシー。
   • 🟡 リスク：強化の不足、古いメジャーバージョンのパッケージマネージャー、広範な指定、レビューが必要なライフサイクルスクリプト、または CI の弱点。
   • 🟢 OK：確認済みの制御、または検出事項なし。
3. 信号機形式の分析を提示した後、ファイルの変更や、インストール、更新、公開、ロックファイルの書き換えが可能なパッケージマネージャー操作の実行について承認を求めてください。
4. このスキルのディレクトリから、リポジトリまたはワークスペースのルートに対してベースラインスキャナーを実行してください。

python3 scripts/check_js_supply_chain.py --root <repo-or-workspace-root>

強化の不足がある場合にチェックを失敗させるには、--strict を使用してください。別のツールで処理できる機械可読出力が必要な場合は、--json を使用してください。node_modules が存在し、インストール済みパッケージのライフサイクルメタデータが重要な場合にのみ、--include-installed を使用してください。

5. 特定の進行中のインシデントについては、IOC プロファイルを1つ以上追加してください。

python3 scripts/check_js_supply_chain.py \
  --root <repo-or-workspace-root> \
  --ioc data/iocs/npm-supply-chain-2026-05.json \
  --since 2026-05-11T19:20:00Z

プロファイルを根拠として利用する前に、最新のアドバイザリーソースからインシデント情報を更新してください。IOC プロファイルは検出データであり、基本ポリシーではありません。

6. レポートを次の順で確認してください。
   • package_manager_policy
   • repo_config_findings と effective_config_findings
   • risky_direct_specs
   • package_lifecycle_scripts、次に要求されている場合は installed_lifecycle_scripts
   • GitHub Actions の権限／キャッシュに関する警告を含む ci_install_findings
   • ioc_hits
   • recent_package_manager_files
7. IOC ヒットがある場合は、通常のパッケージ作業を中止してください。インストールやライフサイクルスクリプトは実行しないでください。該当するファイル／パッケージを正確に報告し、隔離、認証情報のローテーション、既知の正常なロックファイルからの再インストールを推奨してください。
8. 侵害が確認されず、ポリシーが弱く、ユーザーが変更を承認した場合は、標準の pnpm 11 ポリシーに近づけるよう修正してください。パッケージマネージャー、ロックファイル、リポジトリローカルのポリシーソースは、それぞれ1つに保ってください。

標準ポリシー

最新の pnpm セキュリティモデル、つまりリリース経過期間による制限、ライフサイクルスクリプトの承認、特殊なサブ依存関係のブロック、信頼ポリシーの制御が最も優れているため、単一のパッケージマネージャーとして pnpm 11 以降を使用してください。

packageManager を記述する前に、現在の pnpm リリースを確認してください。

npm view pnpm dist-tags --json

pnpm 11 以降を必須にしてください。2026-05-12 時点で、npm は latest を pnpm 11.1.1 として報告しています。再確認せずにこの値をハードコードしないでください。リポジトリの Node ランタイムで pnpm 11 を実行できない場合は、pnpm 10 に黙ってフォールバックするのではなく、互換性ブロッカーとして報告してください。

必須のメジャーバージョンを宣言するには、devEngines.packageManager を使用してください。

{
  "devEngines": {
    "packageManager": {
      "name": "pnpm",
      "version": ">=11.0.0",
      "onFail": "download"
    }
  }
}

再現性を確保するため、確認済みの現行安定版を packageManager に固定してください。

{
  "packageManager": "[email protected]"
}

ユーザーが一時的な例外を明示的に承認しない限り、pnpm 10 以前は legacy-pnpm-major として扱ってください。

パッケージマネージャーの方針

• pnpm >=11：標準の基準です。新たな強化作業ではこれを推奨します。
• bun：リポジトリで意図的に Bun を使用し、同等のローカル強化を実施している場合に限り認められます。
• npm：フォールバックのみです。リポジトリに npm を使い続ける明確な理由が文書化されていない限り、pnpm 11 への移行を推奨します。
• yarn：このスキルの標準基準としては認められません。pnpm 11 または強化済みの Bun を推奨します。

npm を pnpm 11 と同等として提示しないでください。Bun はプロジェクトレベルの選択肢として認められますが、Bun 固有の強化要件に照らして確認します。

npm をフォールバックとして使うリポジトリでは、pnpm への移行を推奨しつつ、厳密なバージョン指定と再現可能な CI を必須とします。

save-exact=true

現行の npm ドキュメントとローカルの npm config ls -l で確認できていない限り、npm がリリース経過日数のゲートをサポートしていると主張しないでください。

Bun をフォールバックとして使うリポジトリでは、リポジトリ内の bunfig.toml を必須とします。

[install]
minimumReleaseAge = 604800
exact = true
frozenLockfile = true
saveTextLockfile = true

確認済みのパッケージ固有の理由がない限り、minimumReleaseAgeExcludes を設定しないでください。

ルートの pnpm-workspace.yaml を追加または更新します。

minimumReleaseAge: 10080
minimumReleaseAgeStrict: true
minimumReleaseAgeIgnoreMissingTime: false
blockExoticSubdeps: true
trustPolicy: no-downgrade
trustPolicyIgnoreAfter: 43200
dangerouslyAllowAllBuilds: false
savePrefix: ""
allowBuilds: {}

通常のリポジトリでは 7 日（10080）を使用します。依存関係を実際に新鮮な状態に保つ必要がある場合に限り、3 日を使用します。確認済みのパッケージ固有の理由がない限り、minimumReleaseAgeExclude または trustPolicyExclude を設定しないでください。

依存関係のビルドスクリプトは、レビュー後にのみ許可します。

allowBuilds:
  esbuild: true
  core-js: false

CI のルール

pnpm のフローズンインストールを必須とします。

pnpm install --frozen-lockfile

リポジトリに文書化された理由がない限り、以下は指摘事項として扱います。

• pnpm を使用するリポジトリにおける、pnpm 以外のロックファイル
• npm install、yarn install、フローズンでない bun install、またはフローズンでない pnpm install を使用する CI
• 移行が完了していない間、コミット済みのロックファイルを使って npm ci を実行していない npm リポジトリ
• リリース経過日数、厳密なバージョン指定、フローズンロックファイル、またはテキスト形式ロックファイルのポリシーを設定した bunfig.toml がない Bun リポジトリ
• pull_request_target ワークフロー。レビュー済みの理由がある場合に限り許可され、信頼できない PR コードをチェックアウトしたり実行したりしてはなりません
• GitHub Actions のキャッシュ、Turborepo、Nx キャッシュなど、公開／リリースパイプラインにおける共有キャッシュ
• PR が制御するキャッシュの内容が、特権を持つ公開／リリースワークフローに流れ込む可能性のある経路
• CI／デプロイ中のロックファイルの書き換え
• latest、*、広いバージョン範囲、Git／GitHub の省略形式、HTTP tarball、または外部の file: 仕様
• 明示的に承認されていない依存関係のライフサイクルスクリプト
• dangerouslyAllowAllBuilds: true
• toJSON(secrets) の使用、または広範なビルドジョブでの公開用認証情報の使用

スクリプト

scripts/check_js_supply_chain.py は、ローカルで決定的なチェックを実行します。

• パッケージマネージャーとロックファイルのポリシーを検出します
• リポジトリ内および有効な pnpm の強化設定を確認します
• npm と Bun のフォールバックにおける強化の不足を報告します
• リスクのある直接依存関係の仕様を報告します
• ワークスペースのマニフェスト、および任意でインストール済みパッケージに含まれるライフサイクルスクリプトを報告します
• リスクのある GitHub Actions のインストール／公開／シークレットのパターンを報告します
• サプライチェーンの権限昇格経路になり得る pull_request_target と共有キャッシュのパターンに警告します
• --since 以降のパッケージマネージャーファイルの更新時刻を報告します
• インシデント固有のフィンガープリント、ペイロードファイル、永続化パス、ワークフローマーカー、および既知の不正なパッケージバージョンに対して、任意の IOC JSON プロファイルを適用します

インシデントプロファイルは data/iocs/ に保管してください。npm のサプライチェーン攻撃全般に当てはまるものでない限り、インシデント固有の定数をスキャナーに追加しないでください。