strictKnownMarketplaces

変更前

管理者が strictKnownMarketplaces で特定の信頼された Git ホストのみにプラグインの取得元を制限していても、SCP スタイルの接続文字列を偽装することで、制限をバイパスして意図しないホストからプラグインを導入できてしまう抜け穴がありました。

変更後

SCP 形式の Git URL に対しても厳密なホストチェックが入り、接続先が管理ポリシーで許可されたマーケットプレイスに正確に合致するかどうか、ネットワーク通信の前に厳密に強制検証されます。

ユーザーへの恩恵

組織内の開発者が、管理者の意図しない非公式の外部サーバーから悪意あるプラグインを誤って取り込んでしまうセキュリティリスクについて不安を抱く必要がなくなります。

変更前

プラグインマーケットプレイスを追加・制限するための設定項目名が複雑で長く、開発者やシステム管理者が直感的に覚えにくい状態でした。

変更後

直感的なエイリアスである additionalMarketplaces（追加用）と allowedMarketplaces（許可リスト用）がサポートされ、以前のキーと同様に解釈されます。

ユーザーへの恩恵

設定ファイルやポリシー定義を作成する際に、複雑な設定キーの綴りをドキュメントで毎回確認して記述する手間がなくなります。

変更前

特定の GitHub 組織（Organization）配下にある複数のマーケットプレイスリポジトリに対して許可やブロックを制御する際、リポジトリを1つずつ個別に管理設定ファイルへ追加する必要があり、組織全体の統制を手間なく行うことが困難でした。

変更後

管理設定で "owner/*" という形式のワイルドカードを使用できるようになり、特定の GitHub 組織が所有するすべてのマーケットプレイスリポジトリを一括で許可またはブロック対象に指定できます。

ユーザーへの恩恵

組織内の開発環境におけるプラグインマーケットプレイスの利用制限を、リポジトリごとに個別登録することなく、組織単位でまとめて安全に管理できるようになります。

変更前

一部のプラグイン操作において、管理者によって制限された未承認のマーケットプレイスからの取得が完全に防げない可能性がありました。

変更後

インストールから自動更新に至るすべてのライフサイクルにおいて、承認済みのソースのみが許可されるよう厳格にチェックされます。

ユーザーへの恩恵

企業環境などにおいて、セキュリティポリシーに基づいた安全なプラグインのみが利用されることを保証します。

変更前

GitHub リポジトリなどを追加する際、一般的な慣習である @ を使ったバージョン指定が認識されず、設定ミスによるエラーに繋がることがありました。

変更後

@ と # の両方がリファレンス区切りとして正しくサポートされ、柔軟な指定が可能になりました。

ユーザーへの恩恵

特定のバージョンやブランチのプラグインを導入する際の手順が分かりやすくなり、導入時のトラブルが減少します。

変更前

ローカルディレクトリからプラグインを読み込む際、許可された特定のディレクトリ以外からの読み込みを厳格に制限することができませんでした。

変更後

ネットワーク経由のホスト制限だけでなく、ファイルシステム上のパスに基づいた読み込み制限が可能になりました。

ユーザーへの恩恵

管理者側で、社内の標準ディレクトリ以外からのプラグインインストールを禁止するなど、より強力なセキュリティ制御が可能になります。

変更前

組織で管理設定(Managed Settings)を導入している場合、特定のディレクトリにあるプラグインのみを許可するといった、ファイルパスに基づいた厳格な制限をかけることができませんでした。

変更後

正規表現によるパスのパターンマッチングが可能になったため、社内の承認済みディレクトリからのみプラグインのインストールを許可するといった運用が可能になりました。

ユーザーへの恩恵

企業利用におけるセキュリティガバナンスが強化され、信頼できない場所からの意図しないコード実行を未然に防ぐことができます。