npmトークン漏えい時の初動対応｜失効と確認方法

冒頭要約

Gitリポジトリ、CI/CDログ、.npmrc、コンテナイメージ、成果物、チャットなどにnpmアクセストークンが露出した疑いがある場合、文字列を削除するだけでは対応完了になりません。npm側で対象トークンを失効し、権限、対象パッケージ、公開履歴、CI/CDでの利用先を同じ時系列で確認します。

最初に、発見時刻、npmアカウント・組織、トークン名とID、読み取り・書き込み権限、対象パッケージやscope、利用しているCIを記録します。書き込み権限やBypass 2FAがある場合は、意図しないバージョン公開、dist-tag変更、maintainer・組織権限の変更がないかを優先して確認します。

この記事では、開発者、OSSメンテナー、SRE、情シス、SaaS管理者、CSIRTが、最初の15分、失効、影響確認、復旧、Trusted Publishingへの移行を進める順序を解説します。漏えいトークンの動作確認や不正公開の再現は行わず、防御・記録・報告に必要な内容だけを扱います。

トークン文字列をチケットやチャットへ貼らない

調査担当者へ共有する場合も、トークンの完全な値や.npmrcの内容を貼り直さないでください。npm上のトークン名・ID、所有者、CIのSecret名、リポジトリ、発見元URL、ログIDなど、秘密値を含まない識別情報を使います。

npmアクセストークンとは：パスワードや2FAとの違い

アクセストークンは、npm CLIやAPI、CI/CDがnpmへ認証するための資格情報です。2026年8月時点のnpm公式ドキュメントでは、Granular access tokenがサポートされ、対象パッケージ・scope・組織、有効期限、送信元CIDR、読み取り専用または読み書き、Bypass 2FAを設定できます。トークンの権限は、発行したユーザーが持つ権限を超えません。

アカウントのパスワードを変更しても、別に発行したアクセストークンの失効を確認したことにはなりません。反対に、トークンを失効しても、アカウントのサインイン、回復情報、組織メンバー、CI/CDに置かれた別の資格情報が安全だと証明されるわけではありません。

Bypass 2FAがある場合の注意

npm公式は、書き込み可能なGranular access tokenでBypass 2FAを有効にすると、パッケージ公開などで2FA要求を迂回できると説明しています。2026年8月から、アカウント情報や組織ガバナンスなど一部操作には対話的な2FAが必要になりましたが、公式文書では現時点でBypass 2FAトークンによる直接公開は可能とされています。

したがって「アカウントで2FAを有効にしているから、漏えいトークンでは公開できない」とは判断できません。対象トークンの読み書き、対象パッケージ、Bypass 2FA、実際のパッケージ設定を確認します。

読者別の影響：誰が何を確認するか

読者・担当	まず確認すること	主な責任範囲
OSS・パッケージメンテナー	対象パッケージ、公開バージョン、dist-tag、maintainer	トークン失効、公開状態の確認、利用者への連絡判断
開発者	リポジトリ、`.npmrc`、ローカル設定、成果物、開発端末	露出元の修正、同時に漏れたSecretの特定、再混入防止
SRE・CI/CD管理者	Workflow、Secretの適用範囲、実行履歴、Runner	公開停止、資格情報の差し替え、実行ログと成果物の保全
npm組織オーナー	組織、team、package access、メンバー、2FA方針	影響範囲、所有権、権限変更、別トークンの棚卸し
情シス・SaaS管理者	GitHubなどの組織Secret、端末、外部共有	閲覧範囲、端末・アカウント影響、社内報告の調整
CSIRT・SOC	発見経路、露出期間、不審な公開・設定変更	優先度判断、証拠保全、拡大調査、経営・法務への接続
パッケージ利用者	利用バージョン、lockfile、取得時刻、ビルド成果物	影響版の判定、更新・隔離・再ビルドの判断

トークンがOrganization secretとして複数リポジトリへ配布されている場合、発見したリポジトリだけを直しても調査は終わりません。トークンを軸に、適用されるリポジトリ、Environment、Workflow、公開対象パッケージを確認します。

まず確認すること：最初の15分チェックリスト

1. トークンと権限範囲を識別する

発見日時、発見者、発見元URL・コミット・ログIDを記録した。
npmアカウントまたは組織、トークン名、トークンID、所有者を確認した。
読み取り専用か読み書き可能かを確認した。
対象パッケージ、scope、組織、送信元CIDR、有効期限を確認した。
Bypass 2FAが有効か、対象パッケージの公開要件は何かを確認した。
Publicパッケージの公開用か、Privateパッケージ取得用か、両方かを確認した。

トークンの完全な値を表示・共有して照合しないでください。npmのAccess Tokens画面にある管理情報、CIのSecret名、所有者台帳、Workflow設定を使って識別します。複数候補を区別できない場合は、影響し得るトークンを未確認のまま残さず、所有者と利用先を確認します。

2. 露出経路と閲覧範囲を確認する

Publicリポジトリ、Privateリポジトリ、CIログ、成果物、コンテナイメージ、チャットのどこで露出したか確認した。
露出開始時刻と、最後に安全を確認できた時刻を記録した。
リポジトリのfork、mirror、clone、ログ転送、成果物のダウンロード範囲を確認した。
同じファイルやログに、GitHub・クラウド・署名鍵など別のSecretが含まれていないか確認した。
削除・上書き前に、秘密値を複製しない形でURL、コミット、Workflow run、成果物IDを保全した。

Git履歴から値を削除しても、すでに取得されたトークンは無効になりません。露出元を非公開化する作業と、npm側でトークンを失効する作業を分けて管理します。

3. CI/CDと利用先を確認する

トークンを使うRepository、Environment、Organization secretを確認した。
package publish、Private package install、metadata操作のどれに使うか確認した。
対象Workflow、Job、Runner、再利用Workflow、Release処理を確認した。
self-hosted runner、キャッシュ、成果物、コンテナレイヤーへ値が残っていないか確認した。
トークン失効で停止する公開・ビルド・デプロイと、業務上の猶予を確認した。

緊急時に新しい長期トークンを急いで広く配布すると、露出範囲を増やします。まず不要な公開Workflowを止め、必要な業務とSecretの適用範囲を確認してから復旧経路を決めます。

4. npm側で失効する

npmのAccess Tokens画面で対象トークンを削除した。
同じ用途、同じ所有者、同じ露出場所にある別トークンを確認した。
失効実施時刻、実施者、承認者、対象IDを記録した。
CIのSecret値を削除・差し替え、旧トークンを参照するWorkflowを止めた。
公開履歴とCIログの監視を継続し、失効確認を完了条件として追跡した。

npm公式ドキュメントは、トークンの失効に最大1時間の遅延が生じる場合があると説明しています。画面上で削除できたことだけを即時の無効化証明にせず、可能な遅延を前提に公開処理を停止し、パッケージ状態とCI実行を監視します。漏えい値を使った接続テストは行いません。

初動対応：やること、やらないこと、記録すること

やること

インシデント責任者、npmアカウント所有者、対象パッケージ、トークンIDを特定する。
npm側で漏えいトークンを失効し、CI/CD側の参照を停止する。
公開バージョン、公開時刻、dist-tag、maintainer、組織・team・package accessを確認する。
GitHub Actionsなどの実行履歴、承認、commit、Release、成果物をパッケージ公開履歴と突き合わせる。
Private packageの読み取り権限があった場合は、取得可能だったパッケージと露出期間を確認する。
不審な変更がある場合は、証拠を保全し、npm Support、CSIRT、パッケージ所有者と公開停止・告知・復旧を判断する。
復旧後、従来トークンを最小権限化するか、対応するCIではTrusted Publishingへ移行する。

やってはいけないこと

漏えいしたトークンを使い、権限や有効性を試さない。
リポジトリやCIログだけを修正し、npm側のトークンを有効なまま残さない。
トークン文字列をチケット、チャット、表計算、個人メモへ貼り付けない。
公開履歴や利用者影響を確認せず、すべてのバージョンを一律にunpublish・deprecateしない。
証拠保全前にWorkflow run、Release、成果物、アカウント、ログを削除しない。
原因を確認せず、新しいトークンを同じSecret名・同じ広い権限・同じ露出経路へ戻さない。
provenanceがあることだけを、公開物に問題がない証明にしない。

記録テンプレート

事案ID:
発見日時・発見者:
npmアカウント / 組織 / パッケージ:
トークン名 / ID / 所有者（値は記録しない）:
権限（read-only / read-write / Bypass 2FA）:
対象package / scope / organization / CIDR / 有効期限:
露出場所・閲覧範囲・推定期間:
利用Repository / Environment / Workflow / Runner:
失効日時・実施者・確認状態:
確認したversion / dist-tag / maintainer / 権限変更:
確認したCI実行・commit・Release・成果物:
Private package・下流利用者への影響:
未確認事項・次回確認期限:
エスカレーション先・判断者:

秘密値そのものは記録テンプレートへ入れません。必要な証跡はアクセス制御された保存先で、収集元、収集時刻、担当者、改変防止手順など組織の証拠保全方針に従って管理します。

npmパッケージの確認方法：公開と権限を分けて調べる

公開状態

露出期間中に追加されたバージョンと公開時刻。
latest、nextなどdist-tagの変更と、通常のリリース計画との差。
パッケージの公開・非公開、deprecate、unpublishなど状態変更。
npm上の公開物と、承認済みcommit・Release・CI成果物の対応。
provenanceがある場合は、示されるソースリポジトリとビルド経路。

provenanceは、パッケージとソース・ビルドの関係を確認する有用な証跡です。ただし、ソースやビルド結果に悪意ある変更が含まれないことまで保証するものではありません。承認済みのcommit、レビュー、CI実行、成果物、公開時刻と合わせて判断します。

所有権と設定

package maintainer、組織メンバー、team、package accessの追加・削除。
パッケージの2FA要件と、従来トークンを許可する設定。
Trusted Publisherの追加・変更と、対象Repository・Workflow・Environment。
トークン所有者のアカウント状態、2FA、回復情報、組織ロール。
同じ所有者が発行した他のトークンと、同じCIへ保存された別のSecret。

2026年8月時点のnpm公式仕様では、Bypass 2FAトークンによるaccount-identityやorganization governanceの一部操作は対話的2FAなしに実行できません。一方、直接公開は別に確認が必要です。想定だけで影響範囲を狭めず、トークン権限とパッケージ状態を実際の管理画面で確認します。

Private packageの読み取り

読み取り専用トークンでも、許可されたPrivate packageの取得に使われる可能性があります。不審な公開バージョンがないことだけで影響なしとは判断できません。対象package・scope、露出期間、監査可能なCI実行、成果物やキャッシュの配布範囲を確認し、知的財産や契約上の影響を担当部門へ接続します。

判断基準：危険度とエスカレーション条件

優先度	条件	推奨する判断
緊急	読み書き可能かつ公開対象が広い、またはBypass 2FAが有効	即時失効、公開停止、全対象パッケージとCIの確認、CSIRT招集
緊急	意図しないversion、dist-tag、maintainer、権限変更がある	サプライチェーンインシデントとして証拠保全、影響版特定、利用者対応を判断
高	Publicリポジトリ、公開ログ、配布成果物へ露出した	利用の証拠を待たず失効し、複製先と同時露出Secretを拡大確認
高	Organization secretや複数パッケージに適用されていた	対象リポジトリ、Workflow、package、teamを横断して確認
高	Private packageの広い読み取り権限がある	取得可能な資産、契約・知財影響、成果物・キャッシュを確認
中	閲覧範囲が限定され、最小権限で、不審な変更が確認されていない	失効、履歴確認、露出元修正、再発防止を完了し根拠を記録
低	ダミーまたは失効済みで、実環境へ権限がないと確認できた	確認根拠を残し、誤配置と検知ルールを改善

次のいずれかに該当する場合は、メンテナー個人や開発チームだけで閉じずにエスカレーションします。

不審な公開、dist-tag、maintainer、組織権限、Trusted Publisherの変更がある。
多数の利用者が取得するPublic package、または機密性の高いPrivate packageが対象である。
トークンの権限、対象パッケージ、露出期間、閲覧者、失効完了を説明できない。
同じCIやリポジトリで、署名鍵、GitHub token、クラウド資格情報も露出した可能性がある。
失効後も公開処理やAPI利用が続く、またはログや成果物に不整合がある。
パッケージ利用者への通知、公開停止、法務・契約判断が必要になる可能性がある。

復旧の順序：公開を戻す前に確認すること

トークン失効、公開Workflow停止、関係者の権限確保を完了する。
npm上のversion、dist-tag、maintainer、組織設定と、承認済みのリリース記録を照合する。
不審な公開物がある場合は、利用者影響と証拠を保全し、npm Supportと対応方針を調整する。
露出経路を修正し、CIログ、成果物、キャッシュ、コンテナへSecretが再出力されないことを確認する。
新しい認証方式を最小のRepository・Environment・packageへ限定して設定する。
レビュー・承認済みのcommitからビルドし、公開前後の記録を残す。
影響を受ける利用者、社内システム、顧客向けに、確認できた事実と対応版を伝える。

不審なバージョンがある場合、削除すれば終わりとは限りません。すでにlockfile、キャッシュ、コンテナ、配布物へ取り込まれた可能性を確認し、該当する利用者には安全なバージョン、再ビルド範囲、確認方法を案内します。被害規模や攻撃主体は、公式に確認できない限り断定しません。

再発防止：長期の公開用トークンを減らす

Trusted PublishingとOIDC

npmのTrusted Publishingは、対応するCI/CDがOIDCで短期の認証を取得し、長期のnpm公開トークンを保存せずにパッケージを公開する仕組みです。2026年8月時点のnpm公式ドキュメントでは、GitHub Actions、GitLab CI/CD、CircleCI cloudが案内され、self-hosted runnerは対象外です。導入前に、利用中のCI、Repository、Workflow、Environmentが公式の対応条件を満たすか確認します。

Trusted Publishingを有効にした後も、既存トークンが残っていれば別経路として利用され得ます。npm公式が案内する従来トークンの制限、パッケージ公開の2FA設定、不要トークンの削除まで含めて移行します。

トークンを残す場合

Private package取得用は読み取り専用にし、公開権限と分ける。
package・scope・organizationを必要最小限に限定する。
短い有効期限と所有者を設定し、更新日・失効日を管理する。
利用環境が固定できる場合はCIDR制限を検討する。
Bypass 2FAは通常の選択肢にせず、必要性と代替策をレビューする。
GitHubのOrganization secretは利用できるRepositoryを明示的に制限する。
CIでSecretを出力しないことをレビューし、ログ・成果物・コンテナも検査する。

公開プロセスを分離する

通常のbuild・testと、package publishの権限を分ける。
Environmentの承認や保護ルールを使い、公開担当とレビューを明確にする。
npmのstaged publishingが要件に合う場合は、公開前レビューと承認を設計する。
Secret ScanningとPush Protectionを有効にし、commit前後の検知を組み合わせる。
最小権限と監査ログを定期的に確認する。

よくある誤解

「Git履歴から消したので対応完了」

履歴修正は再露出を減らす作業であり、取得済みトークンの無効化ではありません。npm側で失効し、複製先とパッケージ状態を確認します。

「2FAを有効にしているのでトークンでは公開できない」

Bypass 2FAを持つ書き込みトークンや、パッケージ側の設定によって判断が変わります。2026年8月の仕様変更も、直接公開の確認を不要にするものではありません。

「CIのSecretを差し替えれば旧トークンも無効になる」

CI側の値を削除・変更しても、npm側で発行済みのトークンが自動的に失効したとは限りません。両方の状態を確認します。

「provenanceがあるパッケージは安全」

provenanceはソースとビルド経路の検証材料ですが、ソースの内容や承認過程まで自動的に安全と判定するものではありません。commit、レビュー、CI、公開履歴と合わせて使います。

「新しいバージョンがないので影響はない」

読み取り権限があればPrivate packageへアクセスできる可能性があり、公開権限がなくても機密性への影響を確認する必要があります。公開履歴だけでなく、トークンの対象範囲と用途を確認します。

次に確認すること	CyberLensのページ
トークンとSecret管理を理解する	アクセストークン、Secrets Management、最小権限
漏えい対応を作業化する	GitHub secret leak対応チェックリスト、漏えい疑い初動テンプレート、GitHubトークン漏えい対応テンプレート
開発基盤を横断確認する	開発ツール・OSSサプライチェーン確認チェックリスト、パッケージマネージャー緊急更新チェックリスト
関連インシデントを読む	Axiosのnpmサプライチェーン事案、pnpm複数アドバイザリの初動対応、Nx・TanStack関連サプライチェーン脆弱性
仕組みと判断軸を学ぶ	サプライチェーン攻撃、SBOMとOSVで学ぶ依存関係確認、認証と認可の違い
検知と来歴を理解する	Secret Scanning、Push Protection、SLSA、Sigstore
知識を確認する	トークン・Secret管理の5問クイズ

公式情報・参考情報

npm Docs: About access tokens - Granular access tokenの権限、対象範囲、有効期限、CIDR、Bypass 2FAと2026年8月時点の制約。
npm Docs: Revoking access tokens - 漏えい・不要トークンの失効方法と、反映が遅延する場合の注意。
npm Docs: Trusted publishing for npm packages - OIDCで長期トークンを減らす仕組み、対応CI、設定条件、従来トークンの制限。
npm Docs: Requiring 2FA for package publishing and settings modification - パッケージ公開と設定変更に対する2FA要件。
npm Docs: Generating provenance statements - 公開パッケージとソース・ビルドの来歴を確認する仕組み。
GitHub Docs: Using secrets in GitHub Actions - Repository・Environment・Organization secretsの管理とOIDCへの移行。
NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - インシデント対応を組織のリスク管理へ組み込む公式指針。

まとめ

npmアクセストークンの漏えいを疑ったら、発見元、トークンID、所有者、権限、対象パッケージ、CI/CDの利用先を記録し、npm側で失効します。失効反映に遅延する場合を考慮し、公開Workflowを止めたうえでversion、dist-tag、maintainer、組織権限、CI実行、Private packageの影響を確認してください。

復旧では、新しい資格情報を同じ広い権限と露出経路へ戻さないことが重要です。対応するCIではTrusted PublishingとOIDCへ移行し、読み取り用と公開用の権限分離、短い有効期限、Secret Scanning、公開承認、監査ログを組み合わせます。確認できた事実と未確認事項を分け、利用者影響や所有権変更があればCSIRTとnpm Supportへ早めに接続してください。

npmアクセストークン漏えい時の初動対応：失効・公開履歴・CI確認

冒頭要約