代表の小竹（aka tkmru）です。
今回は、ソフトウェアに関するサプライチェーン攻撃への対策として、VS CodeとCursorの拡張機能にクールダウンを設定する方法を紹介します。 あわせて、両エディタでクールダウンが適用される範囲の違いを整理します。
Cursorの公式ドキュメントには、GUIやCLIからの手動アップデート、Anysphere社がマーケットプレイスで配布する拡張機能、マーケットプレイスを経由しない拡張機能ファイルに対するクールダウンの適用可否は記載されていません。 本記事では、これらの挙動を2026年8月16日にCursor 3.16.17で検証した結果も紹介します。
サプライチェーン攻撃とクールダウン
（ソフトウェア）サプライチェーン攻撃とは、利用者の端末を直接攻撃する代わりに、ソフトウェアの開発や配布に関わるアカウント、依存パッケージ、更新経路などを侵害する攻撃です。 攻撃者が正規の配布経路へ悪意のあるコードを混入させるため、利用者は正規の更新として取り込んでしまいます。
VS CodeやCursorといったエディタでは、正規のPublisherのアカウントが侵害され、既存の拡張機能に悪意のあるバージョンが公開されるケースが想定されます。
たとえば、利用中の foo.bar という拡張機能のPublisherが侵害され、悪意のあるコードを含むバージョン1.5.1が公開されたとします。
クールダウンという仕組みがなければ、このバージョンが自動更新によって短時間のうちに開発者の端末へ展開される可能性があります。
クールダウンは、公開直後のバージョンを取り込まず、一定期間が経過してからインストールや更新を行う仕組みです。 1週間のクールダウン期間を設定していれば、その間にマーケットプレイスの運営やセキュリティベンダが問題を発見するための時間を確保できます。 クールダウン自体が悪意のあるコードを検知するわけではありません。
以前、VS CodeやCursorの仕様を確認した際には、このようなクールダウン期間を標準機能だけで実現するのは難しい状況でした。 そのため、拡張機能を許可リスト（allow list）で制限することや、自動更新の停止を検討していました。 しかし、改めて現在の仕様を調べたところ、VS CodeとCursorの双方にクールダウン機能が実装されていました。
VS Codeでは extensions.autoUpdateDelay によって拡張機能の自動更新を遅延させることができ、Cursorでは Marketplace Install Cooldown によって新規インストールや更新に対して公開後の待機時間を設定できます。
ただし、VS Codeは主に自動更新を対象とするのに対し、Cursorはマーケットプレイスからの新規インストールも対象とするなど、クールダウンが適用される操作は異なります。
適切なクールダウン期間はどれくらいか
本記事では、サプライチェーン攻撃対策とアップデート速度のバランスを取りつつ、安全側に余裕を持たせる期間として1週間（168時間）を採用します。
VS CodeやCursorが1週間を推奨しているわけではありません。
VS Codeの extensions.autoUpdateDelay のデフォルト値は2時間です。
Cursorの Marketplace Install Cooldown はデフォルトでは無効となっているため、実際のクールダウン期間はユーザ側で決める必要があります。
近年はソフトウェアサプライチェーン攻撃への注目が高まり、公開されたパッケージを監視する仕組みも増えています。 AIを用いて、パッケージレジストリを継続的に監視し、公開直後のコードを検査するといった仕組みです。 Nxの侵害事例では、AIを使ったスキャナが悪意のあるバージョンを公開直後に検出しました。 Cursorでは、サードパーティ製の拡張機能にOpen VSXレジストリを利用し、インストール候補として表示する前に、マーケットプレイスプロキシでマルウェアとサプライチェーンの自動解析を実施しています。 このように、自動解析による仕組みや短時間で検出された事例もありますが、すべての攻撃が同じ速度で発見されるとは限りません。
1週間という期間の根拠として参考になるのが、過去のサプライチェーン攻撃を対象としたWilliam Woodruff氏の分析です。 この分析では、10件中8件で悪意のあるリリースが利用可能だった期間が1週間未満でした。7日間のクールダウンによって、10件中8件で取り込みを回避できた可能性があります。 同じ前提で待機期間を14日間に延ばすと、該当する事例は10件中9件でした。 ただし、分析対象は10件に限られ、事例当時と現在では検出環境も異なるため、この割合を将来の攻撃へそのまま当てはめることはできません。
14日間のクールダウンでも取り込みを回避できなかった代表的な事例として、xz-utilsの件が挙げられます。 xz-utilsは短期間だけ悪意のあるバージョンを公開する攻撃ではなく、長期間にわたって信頼を獲得しながらバックドアを仕込んだ高度な攻撃でした。 このように長期間潜伏する攻撃は、クールダウンを単純に延ばしても防げない場合があります。
1週間という期間は、主要なパッケージ管理ツールの公式ドキュメントでも設定例として使われています。
Yarnの公式リファレンスは 1w、uvの公式リファレンスは 1 week をクールダウンの設定例として掲載しています。
クールダウンを長くするほど正常な機能更新や脆弱性修正の適用も遅れます。 一方、検出が早くなっているからといって、クールダウン期間を想定される検出時間のギリギリまで短くする必要はありません。 期間を短くすれば通常の更新を数日早く適用できますが、検出が遅れた攻撃に対する余裕は小さくなります。 以上から、1週間はクールダウン期間の実務的な基準になると私は考えています。 重大な脆弱性の修正など、クールダウン期間を待たずに更新しないといけないケースに備え、緊急アップデートするための手順も用意しておく必要があります。
VS Codeのクールダウン機能
VS Codeでは、拡張機能の自動更新にクールダウンを設定できます。 ここでは設定方法に加え、Trusted Publisherや手動アップデートなど、クールダウンの対象外となる操作を説明します。
クールダウンを設定する
VS Codeでは、extensions.autoUpdateDelayを利用して、拡張機能がマーケットプレイスへ公開されてから自動更新されるまでの時間を指定できます。
1週間の場合は168時間を設定します。
{ "extensions.autoUpdate": "on", "extensions.autoUpdateDelay": 168 }
extensions.autoUpdateDelay はVS Code 1.125で追加されたため、これを利用するには1.125以降のVS Codeが必要です。
VS Codeでは、1.123で拡張機能の自動更新をデフォルトで公開から2時間遅延させる仕組みが導入され、その後1.125で extensions.autoUpdateDelay が追加されて任意の時間を指定できるようになりました。
また、1.125では extensions.autoUpdate の設定値が on / off に簡素化されています。
VS Codeを1.125へ更新すると、ユーザ設定に残っている従来の true、false、onlyEnabledExtensions、delayed といった値は新しい形式へ自動変換されるため、利用者が設定ファイルを書き換える必要はありません。
移行後は、on で自動更新が有効になり、off で無効になります。
自動更新が有効な場合、無効化されている拡張機能は自動更新されません。
再び有効化した際に更新されます。
extensions.autoUpdate と extensions.autoUpdateDelay はEnterprise Policyにも対応しています。
組織で設定を統一する場合は、ユーザごとに手作業で設定させるのではなく、Group PolicyやMDMなどの端末管理の仕組みを利用して、管理対象の端末へ設定を強制できます。
クールダウンの対象外となる更新
VS Codeの自動更新では、通常の拡張機能にクールダウンを設定できる一方、Trusted Publisherによる拡張機能は対象外です。 VS Code 1.123のリリースノートでは、Microsoft、GitHub、OpenAIなどのTrusted Publisherによる拡張機能にはクールダウンが適用されず、引き続き自動で更新されることが明記されています。
extensions.autoUpdateDelay はクールダウン期間を指定する設定であり、Trusted Publisherの除外を変更する設定は公式ドキュメントに記載されていません。
Trusted Publisherの除外リストを管理者が変更できるようにするFeature Request #321151も提出されていますが、2026年8月時点ではBacklogとなっています。
extensions.autoUpdateDelay は自動更新だけを対象とします。
ユーザがExtensions画面から Update を実行した場合は、設定した遅延時間を待たずに更新できます。
VS Codeの公式ドキュメントにも、Updateボタンではクールダウン期間を待たずに更新できると明記されています。
更新以外の操作にも注意が必要です。
新しい拡張機能を初めてインストールする場合にはクールダウンが適用されません。
この点については、新規インストールにもMinimum Release Ageを適用するFeature Request #321136が現在も存在しています。
手動と自動のインストールへMinimum Release Ageを適用し、Enterprise Policyで強制する提案は、#317830でも確認できます。
#317830は現在、重複のIssueだとしてクローズされています。
2026年8月時点のクールダウンが適用される範囲は次のとおりです。
VSIXは、VS CodeやCursorの拡張機能を一つにまとめたパッケージファイル（.vsix）を指します。
表中の「VSIXからのインストール」とは、マーケットプレイスを経由しない、野良リポジトリなどから入手したVSIXのインストールを含みます。
| 操作 | VS Code |
|---|---|
| 通常の自動更新 | クールダウン対象 |
| Trusted Publisherの自動更新 | 対象外 |
| 手動アップデート | 対象外 |
| マーケットプレイスからの新規インストール | 対象外 |
| VSIXからのインストール | 対象外 |
そのため、extensions.autoUpdateDelay: 168 を設定しても、すべての拡張機能に対しクールダウンを強制できるわけではありません。
Trusted Publisherによる拡張機能もクールダウンの対象にしたい組織では、現状のVS Code標準機能だけでは要件を満たせません。
VSIXによるインストール機能
VS CodeではVSIXからのインストールがサポートされています。
VSIXからのインストールは extensions.autoUpdateDelay の対象ではないため、マーケットプレイスを経由しない導入方法として認識する必要があります。
ただし、公式ドキュメントに記載された AllowedExtensions ポリシーはVSIXにも適用されるため、許可リストを作成した場合は、許可リストにないExtension IDやバージョンのインストールは拒否できます。
VSIXからのインストール自体を無効にするポリシーは確認できませんでした。
許可リストとインベントリ
クールダウンが主に対象とするのは、すでに信頼して利用している拡張機能に、後から悪意のあるバージョンが追加されるケースです。 最初から悪意のある拡張機能が公開され、クールダウン期間より長く存在していた場合は防げません。
VS Codeでは、公式ドキュメントに記載された extensions.allowed を使い、許可するPublisher、Extension ID、バージョンを指定できます。
許可していない拡張機能の新規インストールを防ぐほか、許可するバージョンまで指定すれば、手動アップデートによる未承認バージョンの導入も防げます。
ただし、バージョンを制限する場合は更新のたびに許可リストを管理する必要があるため、運用負荷を踏まえてどこまで統制をかけるか考える必要があります。
組織で利用する場合は、各端末へインストールされている拡張機能とバージョンも把握しておく必要があります。 VS Codeでは次のコマンドでインストール済みの拡張機能とバージョンを取得できます。
$ code --list-extensions --show-versions
この情報をMDMなどで定期的に収集すれば、未承認の拡張機能や想定外のバージョンが残っていないかを確認できます。
公式ドキュメントによると、悪性と確認された拡張機能はマーケットプレイスから削除され、ブロックリストへ追加されたうえで自動でアンインストールされます。 一方、単にマーケットプレイスから公開停止または削除された拡張機能には、VS Code 1.101以降で警告が表示されます。
Cursorのクールダウン
Cursorでは、マーケットプレイスからの新規インストールとアップデートの双方にクールダウンを設定できます。 ここでは、個人設定とチーム設定による設定方法、および公式ドキュメントと実機での検証で確認した適用範囲を説明します。
クールダウンを設定する
Cursorでは、Marketplace Install Cooldownが用意されています。
Teamsプランを利用している場合は、チーム設定の Security & automation にある Marketplace Install Cooldown (hours) に 168 を設定します。
管理者が設定すると、その値はチーム全体へ適用され、ユーザ個人の extensions.installCooldownHours より優先されるため、開発者が自分だけ即時更新へ戻すことはできません。
個人設定としては次の値を利用できます。
{ "extensions.installCooldownHours": 168 }
個人設定はユーザ自身が変更できるため、組織の設定として値を強制するにはチーム設定で設定する必要があります。
クールダウンの対象
Cursorでは、VS Codeと異なり、マーケットプレイスからの新規インストールとアップデートの双方にクールダウンを適用できます。 ただし、公式ドキュメントには各操作に対し、クールダウンが適用される範囲まで記載されていません。 次の表にある「手動アップデート」、Cursorの開発元である「Anysphere社がマーケットプレイスで配布する拡張機能」、「VSIXからのインストール」の結果は、実機で検証し確認したものです。
| 操作 | Cursor |
|---|---|
| マーケットプレイスからの新規インストール | クールダウン対象 |
| マーケットプレイスからの自動アップデート | クールダウン対象 |
| GUIでの手動アップデート | クールダウン対象 |
| CLIでの手動アップデート | クールダウン対象 |
| Anysphere社がマーケットプレイスで配布する拡張機能 | クールダウン対象 |
| VSIXからのインストール | 対象外 |
検証では、Cursorのプロファイルへクールダウンを設定して、クールダウンが適用される範囲を確認しました。
CLIからマーケットプレイスへ明示的に更新を要求しても、新しいバージョンは選択されませんでした。
GUIでは、Prettier 12.3.0をインストールした状態で Extensions: Check for Updates を実行しました。
更新可能な12.4.0が存在するにもかかわらず All extensions are up to date. と表示され、更新されませんでした。
この結果から、GUIから手動で更新する場合にもクールダウンが適用されることを確認できました。
Anysphere社がマーケットプレイスで配布する拡張機能もクールダウン対象であることを確認できています。 なお、検証に使用したのは個人設定であり、チーム設定からの設定強制そのものは検証していません。
VSIXによるインストール
CursorにもVSIXから拡張機能をインストールできます。 検証では、クールダウンを設定した状態でも、ローカルのVSIXをインストールできました。 VSIXからのインストールはマーケットプレイスのバージョン選択を経由しないため、クールダウンは適用されません。 また、VSIXからのインストール自体を無効にするポリシーは確認できませんでした。
Cursorの公式ドキュメントは AllowedExtensions ポリシーによるインストール制限を説明しています。
これがローカルのVSIXにも適用されることを確認しました。
検証では、extensions.allowed を {"*": false} に設定したCursorで、ローカルのVSIXが許可リストにないことを理由にインストールを拒否されました。
{"*": false} はすべての拡張機能を拒否するため、実際の運用ではそのまま使うことはできません。
実際に許可リストを運用する場合は、組織で利用を認めるPublisher、Extension ID、バージョンを指定します。
この時、許可リストに含まれるExtension IDやバージョンのVSIXはインストールされます。
許可リストと署名検証
より強い統制が必要な場合は、Allowed Extensionsによる制限や、チーム設定の Require Extension Signature Verification による署名検証も選択できます。
AllowedExtensions はチームダッシュボードから設定できるほか、MDMから管理対象の端末へ配布できます。
MDMで配布したポリシーは、チームダッシュボードの設定とユーザ個人の extensions.allowed より優先されます。
Cursorの公式ドキュメントでは、同じ publisher.extension でも、Open VSXとMicrosoft Marketplaceで異なるPublisherやコードを指す場合があるため、信頼できるPublisherからインストールするよう注意を促しています。
まとめ
VS CodeとCursorは、いずれも拡張機能にクールダウンを設定できますが、適用される範囲と設定方法が異なります。 VS CodeではEnterprise Policyで自動更新にクールダウンを強制できる一方、新規インストールは対象外です。 Cursorではマーケットプレイスからの新規インストールも対象にできますが、組織として強制するにはTeamsプラン以上のプランが必要です。
VS CodeではTrusted Publisher、手動更新、新規インストールはクールダウンの対象外です。 マーケットプレイスを経由せず、手元のVSIXファイルから拡張機能を直接インストールする場合にも、VS Codeのクールダウンは適用されません。
Cursorの公式ドキュメントには、手動アップデート、Anysphere社がマーケットプレイスで配布する拡張機能、ローカルのVSIXについて、クールダウンの適用可否が個別に記載されていませんが、検証したところ、GUIとCLIからの手動アップデートおよびAnysphere社がマーケットプレイスで配布する拡張機能もクールダウンの対象となりました。また、ローカルのVSIXからのインストールはクールダウンの対象外となりました。
一方、AllowedExtensions ポリシーを設定した場合は、許可リストにないローカルのVSIXが拒否されました。
VS CodeとCursorのどちらでも、マーケットプレイス以外から入手したVSIXのインストールを無効にする専用ポリシーは確認できません。
AllowedExtensions ポリシーで許可リストにないVSIXを拒否するには、許可するExtension IDやバージョンを定め、許可リストを継続的に管理する必要があります。
クールダウン機能のみを使い、未承認のVSIXがインストールされるリスクを許容するか、許可リストも運用するか、組織内で方針を定める必要があります。
今回紹介したようなセキュリティ施策の設計や運用、調査を内製で進めることが難しい場合は、弊社のセキュリティチーム代行サービスをご検討ください🙏
日々のセキュリティに関するお悩み相談、施策の優先順位付け、ポリシーの策定や改訂、脆弱性管理ツールの運用など、組織の体制や課題に合わせて支援内容をご提案します。
