保守を委託しているシステムについて、「デプロイはどうやって行われていますか」と聞いてみたことはあるでしょうか。返ってくる答えで多いのは次の2つです。
- 担当者のPCでビルドして、手作業でサーバーに上げている
- CI（自動ビルド）が組まれていて、押すと本番に反映される
どちらの場合も、その裏にはどこかに保管された認証情報があります。サーバーへの鍵、パッケージ公開用のトークン、クラウドのアクセスキー。そしてその多くは、一度発行してから一度も更新されていません。
2026年に入ってGitHubがnpmとGitHub Actionsに対して打った一連の対策は、攻撃者がまさにここを狙っているという前提に立っています。
狙われているのは、長く生き続ける認証情報
サプライチェーン攻撃と聞くと、悪意あるコードが混入したライブラリを掴まされる図を思い浮かべます。実際にはその手前があります。攻撃者はまず、正規の開発者が持つ公開権限を奪う。 奪ってしまえば、正規のパッケージとして悪意あるコードを配れます。利用者側からは見分けがつきません。
公開権限の実体は、多くの場合、CI環境に置かれた長期有効のトークンです。有効期限が長く、失効させない限り生き続け、CIのログや環境変数から抜き取れる。攻撃の起点は脆弱性ではなく、置きっぱなしの認証情報というのが実態に近い形です。
GitHubの対策も、この起点を潰す方向に揃っています（Disrupting supply chain attacks on npm and GitHub Actions — The GitHub Blog）。
トラステッドパブリッシング（trusted publishing） は、CIからレジストリへ公開する際に、長期トークンを使わず、CI実行そのものの身元をもとに公開を認可する仕組みです。2026年4月にはCircleCIも対応プロバイダに加わりました。トークンが存在しなければ、盗む対象もありません。
npm v12（2026年6月）では、インストール時スクリプトが既定で無効になりました。攻撃者が認証情報を抜き取る経路として使ってきた postinstall 等が、既定では動かなくなります。あわせて、gitや任意のURLを指定した依存関係も既定で無効化され、インストール時にコードが実行される経路が絞られました。
影響の大きいnpmアカウントには、予防的な保護が入りました。メールアドレスの変更や2要素認証の復旧といった重要な変更のあと、72時間は読み取り専用の状態になります。乗っ取り直後に一気に悪意あるバージョンを配る、という動きを止めるための時間です。
依存更新を数日待つDependabotのクールダウンも、同じ考え方の延長にあります（Dependabotに既定のクールダウンが入った件）。
「更新したらビルドが通らなくなった」側の話
ここで、保守を委託している側にも関係する変化が起きます。npm v12でインストール時スクリプトが既定で無効になったことで、それに依存していたプロジェクトはビルドが通らなくなる可能性があります。
ネイティブモジュールのコンパイル、ブラウザ本体のダウンロード、環境に応じたバイナリの取得——このあたりは、インストール時スクリプトで動いてきました。必要なものについては明示的に許可する設定を入れれば動きますが、「どれが必要か」を判断するには、そのプロジェクトの中身を知っている必要があります。
長く更新していないシステムほど、ここで止まります。そして止まったときに、「更新しなければ動き続けるので、当面このままで」という判断に流れがちです。その状態が数年続いた結果が、いま多くの会社にある「触れないシステム」です。
裏を返せば、今回の変更でビルドが通らなくなるかどうかは、そのシステムがまだ手入れできる状態にあるかの試験紙になります。 委託先に一度試してもらう価値があります。
委託先に聞く4つのこと
技術的な詳細まで踏み込む必要はありません。発注側として確認すべきなのは、次の4点です。
| 確認すること | 良い状態 | 見直しが要る状態 |
|---|---|---|
| ビルドはどこで動いているか | サーバー上のCIで、記録が残る | 特定の担当者のPCでのみ動く |
| 公開・デプロイ用の認証情報の有効期限 | 短期、またはトークンを使わない方式 | 発行時期が分からない、期限がない |
| その認証情報を知っている人数 | 必要な人だけ、一覧にできる | 「たぶん何人か」で答えが出ない |
| 委託が終わったときの失効手順 | 手順が文書化されている | 決まっていない |
いちばん重いのは1つめです。 特定の担当者のPCでしかビルドできない状態は、セキュリティの問題であると同時に、事業継続の問題でもあります。その人が辞めた時点で、システムは更新できなくなります。
4つめも実務でよく抜けます。契約が終わった後も委託先の認証情報が生きていて、誰も気づかないまま数年経つ。悪意がなくても、その委託先が侵害されれば自社まで届きます。委託先との関係が切れるときに何を止めるかは、始めるときに決めておく話です（開発会社と連絡が取れなくなった）。
今日できること
まず、自社で契約している委託先を一覧にしてください。開発だけでなく、サイト保守、EC、社内ツール、すべてです。そのうえで各社に、上の4つを聞きます。
答えが揃わなくても構いません。答えられないこと自体が現在地の情報です。「認証情報の有効期限は把握していません」と返ってきたら、そこが最初に手をつける場所になります。
そして、一覧に載らなかった委託先がないかを確認してください。数年前に作ってもらったきり連絡していないシステム、退職した担当者が個人的に頼んでいた保守。これらは一覧に載らないので、侵害されても気づけません。npm install が任意コード実行であるという前提での開発環境の設計は「npm install は任意コード実行」時代の開発環境で扱っています。
委託先を含めた保守体制の棚卸しをしたい、既存システムがどこまで更新できる状態にあるかを調べてほしい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- Disrupting supply chain attacks on npm and GitHub Actions — The GitHub Blog
- Our plan for a more secure npm supply chain — The GitHub Blog
- GitHub to Update npm to Thwart Software Supply Chain Attacks — Infosecurity Magazine
- The npm Threat Landscape: Attack Surface and Mitigations — Unit 42, Palo Alto Networks
