VS Code「ワークスペース信頼（Workspace Trust）」の全貌：サプライチェーン攻撃を無効化するDevOps的リスク管理と完全自動化の極意
数々の巨大モノレポ、無数のサードパーティ製依存関係、そして日々刻々と変化するCI/CDパイプライン。現代の開発現場において、我々エンジニアが最も警戒すべきはコードのバグではない。「信頼できないコードによって実行される暗黙のプロセス」、すなわちRCE（リモートコード実行）を狙った高度なサプライチェーン攻撃だ。
VS Codeは、単なるテキストエディタの枠を超え、拡張機能（Extension）という名の独立したプロセス群をバックグラウンドで縦横無尽に走らせる「ミニ・オペレーティングシステム」と化している。未知のリポジトリをクローンし、深く考えずに `code .` を叩いた瞬間、ワークスペース内に仕込まれた悪意ある `settings.json` や、脆弱性・バックドアを内包した拡張機能がホストマシンの権限を奪う――これはSFではなく、現在のセキュリティ脅威のスタンダードである。
本稿では、VS Codeの「ワークスペース信頼（Workspace Trust）」機能の内部アーキテクチャを解剖し、CI/CDやDocker環境と完全に統合したゼロ・トラストな開発環境の構築手法を、一切の妥協を排して解説する。
—
1. ワークスペース信頼の内部アーキテクチャと脅威モデル
拡張機能ホスト（Extension Host）の二重構造
VS Codeのセキュリティモデルの核心は、拡張機能が動作するプロセスサンドボックスにある。Workspace Trustが無効（Restricted Mode）な状態でプロジェクトを開いた場合、VS Codeは内部で厳格な制限モードを発動する。
- APIの制限: ワークスペースの設定（`settings.json`）による自動タスク実行、デバッグ構成の定義、および一部の危険なAPIを呼び出す拡張機能の機能が強制的に無効化される。
- 拡張機能の隔離: すべての拡張機能が無効化されるわけではない。VS Codeのコアチームが「信頼性を検証済み（`untrustedWorkspace` に対応）」とマークした拡張機能のみが動作し、それ以外の拡張機能は起動プロセスから完全に切り離される。
[VS Code メインプロセス (Electron/Node.js)]
│
├─► [制限付き拡張機能ホスト] ─── (安全な拡張機能のみロード)
│
└─► [ワークスペースファイル監視] ── (悪意ある設定ファイルの自動ロードを阻止)
このアーキテクチャにより、リポジトリ内の `.vscode/settings.json` に仕込まれた `terminal.integrated.automationProfile.` などの設定キーを用いた、ターミナル乗っ取り攻撃を根絶することができる。
—
2. エンタープライズ開発における「Workspace Trust」の宣言的制御
GUIのダイアログでポチポチと「信頼する」をクリックする運用は、セキュリティ統制の観点から論外である。何百ものマイクロサービスを扱う組織では、グローバルおよびプロジェクト単位の設定ファイルによって、信頼状態を宣言的（Declarative）に管理しなければならない。
グローバルセキュリティポリシーの強制
開発者のマシーン全体で、未知のワークスペースをデフォルトで「制限モード（Restricted）」に強制し、勝手な昇格を防ぐためのユーザー設定 (`settings.json`) の極限設定を示す。
{
// 未知のワークスペースを開いた際のデフォルト動作を「制限」に固定
“security.workspace.trust.untrustedFiles”: “prompt”,
// 信頼されていないワークスペースでのタスク自動検出を完全に無効化
“task.allowAutomaticTasks”: “off”,
// 信頼されていない環境でのデバッグ構成の自動ロードを禁止
“debug.allowBreakpointsEverywhere”: false,
// 明示的に信頼されたパスのホワイトリスト（社内標準リポジトリ置き場など）
“security.workspace.trust.trustedFolders”: [
“/home/dev/projects/internal-core-repo”,
“/home/dev/projects/sandbox”
]
}
なぜこの設定が不可欠なのか？
`security.workspace.trust.untrustedFiles` を `prompt` または `openInRestrictedMode` に設定することで、外部から持ち込まれた悪意あるPoC（概念実証）コードや、GitHubから直接クローンしたばかりの検証用リポジトリが、エディタを開いた瞬間にバックグラウンドスクリプトを走らせるリスクを物理的に遮断できる。
—
3. Docker・Dev Containers環境における完全自動構成
DevOpsの現場では、ローカルホストを汚染しないためにDockerコンテナ（Dev Containers）を常用する。しかし、コンテナ内にマウントされたボリュームに対してもVS CodeのWorkspace Trustは厳格に適用されるため、コンテナを起動するたびに「Trustしますか？」というダイアログが出て開発体験が阻害されることがある。
これを完全に自動化し、CI/CDパイプラインやコンテナビルド時に「信頼済み」の状態を担保するための構成手法を解説する。
`.devcontainer/devcontainer.json` での信頼状態の事前定義
Dev Containersの仕様を利用し、コンテナ起動と同時にそのワークスペースを自動的に「信頼済み」としてVS Codeに認識させる設定を埋め込む。
{
“name”: “Secure Hardened DevEnvironment”,
“image”: “mcr.microsoft.com/devcontainers/base:ubuntu”,
// コンテナ内で実行されるカスタムカスタマイズ
“customizations”: {
“vscode”: {
// コンテナ内部で強制適用する拡張機能
“extensions”: [
golang.go,
ms-azuretools.vscode-docker,
esbenp.prettier-vscode
],
// ワークスペース信頼を自動的にバイパス（信頼状態に設定）するための設定
// ※注意: このコンテナ自体が信頼できるDockerfileからビルドされていることが前提
“settings”: {
“security.workspace.trust.startupPrompt”: “never”,
“security.workspace.trust.enabled”: true
}
}
},
// コンテナ起動後に実行するライフサイクルフック
“postCreateCommand”: “echo ‘Workspace secured and trusted via DevContainer spec.'”
}
コンテナ環境におけるセキュリティの要諦
コンテナ内で開発を行う場合、ホスト側のWorkspace Trust設定がコンテナ内のVS Code Serverに伝搬しない場合がある。そのため、上記の `devcontainer.json` による明示的な設定の流し込みが、チーム全体のオンボーディングスピードを劇的に加速させる鍵となる。
—
4. CLIおよびAPIを活用した自動化スクリプト
新規プロジェクトのジェネレーターや、セキュリティスキャンを行うCLIツールと連携し、リポジトリの初期化時にVS Codeの信頼設定を自動生成・検証するスクリプトを構築する。
以下は、指定したディレクトリをVS Codeの信頼リストに安全に追加するための、Bashによる自動化スクリプトの傑作である。
!/usr/bin/env bash
set -euo pipefail
==============================================================================
スクリプト名: trust-workspace.sh
概要: 指定されたプロジェクトパスをVS Codeのグローバル信頼設定に安全に追加する
==============================================================================
TARGET_DIR=”${1:-$(pwd)}”
絶対パスに変換
ABS_TARGET_DIR=$(realpath “$TARGET_DIR”)
OSに応じたVS Codeの設定ファイルのパスを特定
if [[ “$OSTYPE” == “darwin” ]]; then
VSCODE_CONFIG_DIR=”$HOME/Library/Application Support/Code/User”
elif [[ “$OSTYPE” == “linux-gnu” ]]; then
VSCODE_CONFIG_DIR=”$HOME/.config/Code/User”
else
echo “[ERROR] Unsupported OS: $OSTYPE” >&2
exit 1
fi
SETTINGS_FILE=”$VSCODE_CONFIG_DIR/settings.json”
echo “==> Target Workspace: $ABS_TARGET_DIR”
echo “==> Configuring VS Code Trust Settings…”
設定ファイルが存在しない場合は初期化
if [ ! -f “$SETTINGS_FILE” ]; then
mkdir -p “$VSCODE_CONFIG_DIR”
echo “{}” > “$SETTINGS_FILE”
fi
jqコマンドを使用して、安全にJSON配列（security.workspace.trust.trustedFolders）にパスを追加
既存の配列に重複して追加されないよう、uniq処理を挟む
TEMP_FILE=$(mktemp)
jq –arg path “$ABS_TARGET_DIR” \
‘.[“security.workspace.trust.trustedFolders”] = ((.[“security.workspace.trust.trustedFolders”] // []) + [$path] | unique)’ \
“$SETTINGS_FILE” > “$TEMP_FILE” && mv “$TEMP_FILE” “$SETTINGS_FILE”
echo “SUCCESS: $ABS_TARGET_DIR has been successfully trusted in VS Code.”
このスクリプトがもたらす現場の利益
社内テンプレートジェネレーターや、新規リポジトリのクローン・セットアップスクリプト（`make init` や `bootstrap.sh`）の末尾にこのスクリプトを組み込むことで、開発者は「エディタを開いた瞬間に作業が制限モードになり、ビルドスクリプトが動かなくてイライラする」という無駄なコンテキストスイッチから完全に解放される。
—
5. 高度なトラブルシューティングとパフォーマンスハック
1. 大規模モノレポにおけるメモリ消費と信頼スキャンの競合
数万ファイルのコードベースを持つ大規模モノレポにおいて、VS Codeが起動時に全ファイルの整合性とWorkspace Trustの評価を同時に行うと、ファイルウォッチャー（`inotify` の上限枯渇など）が暴走し、CPU使用率が100%に張り付く現象が発生する。
対策: 信頼された親フォルダの下にモノレポを配置し、除外設定を徹底する。
{
“security.workspace.trust.enabled”: true,
// 巨大なビルド成果物やサードパーティのキャッシュディレクトリを監視対象外にし、信頼スキャンの負荷を軽減
“files.watcherExclude”: {
“/.git/objects/“: true,
“/node_modules/“: true,
“/target/“: true,
“/dist/“: true,
“/.venv/“: true
}
}
2. 拡張機能の「未検証」警告をバイパスするための監査フロー
社内で独自に開発したプライベート拡張機能（VSIX）を導入する際、Workspace Trustによってブロックされるケースがある。これを安全に回避するには、組織の証明書基盤や署名パイプラインと連携させる必要があるが、開発者個人のマシンで一時的に強制許可するためのオーバーライド設定が存在する。
{
// 特定の拡張機能IDについては、ワークスペースの信頼状態に関わらず常時実行を許可する
“extensions.ignoreTrust”: [
“my-company.internal-security-scanner”
]
}
※注意: この設定はセキュリティ上の例外を設けるものであるため、CI/CDによるポリシーチェック（Linter）によって、許可されていない拡張機能が勝手に登録されていないか定期的に監査すべきである。
—
結び：DevOps文化への昇華
VS Codeの「ワークスペース信頼」は、単なる「ポップアップを消すための設定」ではない。それは、「すべてのコードは性悪説に基づき、検証されるまで危険である」という現代のセキュリティパラダイム（Zero Trust）を、開発者の最も身近なインターフェースであるエディタのレイヤーまで貫徹するための重要な防壁である。
インフラストラクチャのコード化（IaC）と同様に、エディタのセキュリティ設定さえもコードとしてリポジトリに内包し、自動化パイプラインに組み込むこと。それこそが、真にモダンでセキュアな開発環境アーキテクチャの到達点なのである。