沙箱執行

1. 3秒看懂

沙箱執行 (Sandboxed Execution) 是一種在嚴格隔離的受限環境中執行不可信或高風險程式碼（如第三方外掛、使用者上傳指令碼、AI生成程式碼）的安全技術。其核心是 “隔離”、“最小權限” 與 “可控環境” 三位一體，確保程式碼即便含惡意邏輯也無法觸碰或破壞宿主系統。

2. 3分鐘產業解釋

假設你需要在個人電腦上執行一個來路不明的程式。沙箱技術等價於在你的電腦內部搭建一座透明、全封閉的“玻璃工作室”。這個程式只能在玻璃室裡活動，只能看到房間內預置的有限檔案、虛擬網路和計算資源，對房間外真實作業系統、個人資料一律不可見。它發出的一切系統呼叫、網路請求均受監控和約束。當任務完成或發現異常，玻璃室可以被瞬間清空拆除，不留痕跡。

這種機制早已超越傳統防毒軟體的附屬功能，成為雲端運算、AI應用開發（尤其是程式碼生成與執行）、瀏覽器擴充套件、移動應用的基礎安全原語。在AI時代，當大語言模型需要生成並執行程式碼來完成使用者指令時，沙箱就是防止模型“意外越軌”或被惡意利用的最後一道關鍵控制點。

3. 技術原理

沙箱執行並非單一技術，而是一套層次化隔離技術棧，從上到下可劃為三個層次：

3.1 作業系統級隔離：容器化沙箱

利用 Linux 核心的 namespaces、cgroups、seccomp-bpf 等機制，為程序建立獨立、受限的系統視角。

• 名稱空間 (Namespaces)：在 PID、網路、掛載點、使用者、UTS、IPC、cgroup 等維度各自虛擬化。容器內程序只能看到分配給它的程序樹、網路介面和檔案系統子樹。
• 控制組 (cgroups)：對 CPU、記憶體、塊裝置 I/O、網路頻寬等實施硬限制，阻止惡意程式碼耗盡宿主資源（如挖礦）。
• 系統呼叫過濾 (seccomp-bpf)：通過伯克利包過濾規則限制程序可呼叫的系統呼叫集合。例如可禁止 mount、ptrace、reboot 等危險呼叫，從根本上壓縮攻擊面。

Linux 容器執行時常使用上述組合實現沙箱化。典型堆疊示例如下：

+-------------------------------------------------+
|              宿主作業系統                        |
|  +------------------------------------------+  |
|  |           沙箱 (容器)                     |  |
|  | +--------+ +--------+ +-------------+   |  |
|  | |程序樹  | |虛擬網絡卡| |獨立掛載名稱空間 |   |  |
|  | |(PID ns) | |(net ns)| |(mount ns)    |   |  |
|  | +--------+ +--------+ +-------------+   |  |
|  |                                           |  |
|  |      CPU/記憶體限制由 cgroup 控制           |  |
|  |      可呼叫 syscall 由 seccomp 白名單     |  |
|  +------------------------------------------+  |
+-------------------------------------------------+

3.2 程序/語言級沙箱：輕量隔離

當作業系統級隔離過重時，可通過語言執行時或二進位制格式自建邊界。

WebAssembly (Wasm) 是此類典範。Wasm 模組執行在自己的線性記憶體中，無法直接訪問宿主記憶體或進行系統呼叫；所有外部能力（檔案、網路、時鐘）必須通過宿主顯式匯入的函式實現。配合 WASI (WebAssembly System Interface) 標準化介面，Wasm 沙箱能夠跨平台提供安全、確定性的執行環境。其隔離強度介於傳統容器和程序之間，且冷啟動可達微秒級。

此外，Python RestrictedPython、Java Security Manager、.NET Code Access Security 等也曾實現語言級沙箱，但通常因細粒度策略維護複雜而逐漸式微。

3.3 硬體級/虛擬機器隔離：最強安全邊界

通過硬體虛擬化技術（Intel VT‑x / AMD‑V）建立完整虛擬機器，每個沙箱擁有獨立的客戶作業系統核心。此模式下，即便客戶核心被攻破，仍需再穿透 Hypervisor 或晶片級漏洞才能觸及宿主，攻擊鏈極長。

但傳統虛擬機器資源開銷大、啟動慢。因此業界發展出微虛擬機器 (microVM)，如 AWS Firecracker。它裁剪了不必要的裝置模型和 BIOS，只保留單程序、小記憶體、高效能 virtio 裝置，可在 125 ms 內啟動（參見 NSDI’20 論文），同時保持硬體級隔離。

隔離強度次序（從高到低）：硬體虛擬機器 ≈ 微虛擬機器 > 配置完善的容器（配合 Seccomp/Namespace） > Wasm 沙箱 > 程序/語言級沙箱。

效能開銷及啟動速度則大致反向：Wasm 極低（接近原生）、容器低、微虛擬機器低至中等、傳統虛擬機器中高。

4. 關鍵引數

評估沙箱方案需關注以下核心引數：

1. 隔離強度 / 逃逸難度：能否阻止惡意程式碼突破沙箱訪問宿主系統，是最高優先順序指標。通常以常見漏洞與暴露 (CVE) 逃逸數量、漏洞賞金金額等作為簡陋參考（詳細資訊見風險章節）。
2. 效能開銷：相對於裸機執行，CPU、記憶體、I/O、網路吞吐量的損耗百分比。對高併發無伺服器函式尤為重要。例如 AWS Firecracker 在 iperf3 網路吞吐測試中開銷約 5%–7%（2020 年資料，來源：AWS Open Source Blog 基準測試）。
3. 啟動時間 (冷啟動延遲)：從觸發建立到沙箱可接受請求的時間。微虛擬機器目標為數十至百毫秒級（Firecracker <125 ms）；容器通常秒級；Wasm 冷啟動低於毫秒級（WasmEdge 預熱後約 0.1 ms，來源：WasmEdge 2023 年效能報告）。
4. 資源佔用 / 部署密度：單個沙箱基礎記憶體佔用。Firecracker VM 最小可至 5 MB，容器（不含應用）約數 MB，Wasm 沙箱約幾十 KB 級。密度直接影響單臺物理機的函式部署數量與成本。
5. 可配置性與策略粒度：網路（出站/入站白名單）、檔案系統（只讀/只寫層、tmpfs）、可呼叫 syscall、時間限制（最長執行時間）等精細控制能力。
6. 生態相容性：支援的語言、二進位制格式、OCI 映象、Kubernetes 整合、CI/CD 工具鏈適配。

5. 技術路線

主流的沙箱執行技術路線可歸納為以下四條：

路線	隔離基礎	典型專案/產品	隔離強度	啟動時間	資源密度	適用場景
硬體虛擬機器	硬體虛擬化	KVM, VMware	極高	數十秒	低	傳統雲端運算、跨租戶強隔離
微虛擬機器	硬體虛擬化（裁減）	Firecracker, Kata Containers	高	百微秒至百毫秒	中高	無伺服器函式、容器安全增強
作業系統容器	核心 Namespace/cgroup	Docker, containerd, CRI‑O	中到高（需配合 seccomp）	秒級	高	雲端原生應用、CI/CD、web 服務
Wasm 沙箱	語言/軟體限制	Wasmtime, WasmEdge, V8	中高	≤ 毫秒級	極高	邊緣計算、AI 程式碼執行、外掛系統

路線選擇趨勢（2023‑2025）：

• 雲端廠商 FaaS 普遍採用微虛擬機器（AWS Lambda 用 Firecracker，阿里雲端函式計算用安全沙箱容器），兼顧啟動速度與隔離。
• 企業容器平台開始整合 Kata Containers 等旨在提供“虛擬機器般隔離的容器”。
• AI 程式碼執行和邊緣場景中，Wasm 因其極致輕量與安全逐漸被採納。Docker 在 2023 年已宣佈支援 Wasm 執行時，OpenAI Code Interpreter 後端亦藉助沙箱網格執行不受信任程式碼。

6. 上游生態

沙箱執行所需要依賴的基礎能力層：

• 晶片與硬體：CPU 虛擬化指令集（Intel VT‑x、AMD‑V、ARM VHE）；可信執行環境（TEE），如 Intel SGX、AMD SEV、ARM CCA，可與沙箱形成軟硬協同隔離。
• 作業系統核心：Linux 核心提供 namespace、cgroup v2、seccomp、Landlock、fscrypt 等安全原語；Windows 提供作業物件、受限令牌、AppContainer 沙箱等。
• Hypervisor 與虛擬化層：KVM、Xen、Microsoft Hyper‑V，以及 AWS Nitro System 等定製化虛擬化平台，均為微虛擬機器與虛擬機器沙箱的基礎。
• 容器執行時底層：runC、Firecracker‑containerd、Kata Runtime 等，是實現沙箱的中間層。

7. 下游應用

沙箱執行嵌入到以下典型產業場景：

• 雲端無伺服器計算：AWS Lambda、Azure Functions、Google Cloud Run、阿里雲端函式計算等函式即服務平台，每次函式呼叫都在獨立沙箱（微虛擬機器或強隔離容器）中執行。
• AI Agent 與程式碼生成：OpenAI ChatGPT Code Interpreter、Anthropic Claude 工具使用、各種 LLMOps 平台的程式碼執行模組。沙箱確保模型生成的任意程式碼（包括潛在的 rm ‑rf / 或反彈 shell）不會影響真實環境。
• DevSecOps 與 CI/CD：GitHub Actions、GitLab CI/CD 中建置流水線預設在隔離容器或 Kubernetes Pod 中執行，以保護建置伺服器免遭供應鏈攻擊。
• 瀏覽器與終端安全：Chrome 將渲染程序運行於沙箱（Windows 的 UserRestricted job、macOS seatbelt）；Office 365 利用沙箱開啟可疑文件。
• 線上程式設計/教育平台：如 Replit、Codewars 等，為使用者提供安全的即時程式碼執行環境。

8. 受益公司

由於沙箱多為內嵌基礎能力，投資分析應聚焦於其“使能價值”，而非獨立營收。以下按類別梳理：

• 公有雲端廠商：Amazon (AWS) 憑藉 Firecracker 和 Lambda 在無伺服器領域維持技術與成本優勢；Microsoft Azure 利用 Hyper‑V 和門戶沙箱強化函式計算；Google Cloud 借 gVisor 與 Chrome V8 沙箱積累，推出 Cloud Run 等服務；阿里巴巴 (阿里雲端函式計算與安全沙箱容器) 在國內無伺服器市場佔據領先。
• 開源/創業公司：WasmEdge (Second State) 已捐入 CNCF 沙箱專案，專注高效能 Wasm 執行時，主打邊緣與AI場景；Kata Containers (OpenInfra 基金會) 提供 VM 級容器隔離；Sysdig、Aqua Security 等容器安全廠商將沙箱作為執行時防護的一環；Fermyon 等 Wasm 雲端平台提供基於 Wasm 沙箱的無伺服器服務。
• AI 應用平台：OpenAI、Anthropic、Cohere、Replit 等均依賴沙箱執行生成程式碼，沙箱技術直接影響其產品功能邊界與安全口碑。 注意：以上均為業務相關性闡述，不構成任何投資建議。

9. 市場規模

沙箱執行技術通常不單獨形成統計市場，其商業價值體現於雲端基礎設施、容器安全、無伺服器計算和AI程式碼執行等賽道。以下為相關市場資料及趨勢：

• 無伺服器計算市場：據 Mordor Intelligence 2024 年報告，全球無伺服器計算市場規模預計 2024 年約 165.8 億美元，到 2029 年將達 384.7 億美元，年複合增長率 18.34%。（口徑：包括 FaaS 和後端即服務 BaaS；來源：Mordor Intelligence, 2024 年 1 月釋出）。沙箱執行構成無伺服器函式執行的安全基座，市場增長直接拉動沙箱需求。
• 容器安全市場：MarketsandMarkets 2023 年《Container Security Market》報告估計，全球容器安全市場規模 2023 年為 16.2 億美元，預計 2028 年增至 38.7 億美元，年複合增長率 19.0%。（口徑：容器安全解決方案及服務；來源：MarketsandMarkets，2023 年 9 月釋出）。沙箱（包括容器隔離、微虛擬機器）是容器安全的重要組成部分。
• AI 程式碼執行細分：截至 2025 年初，尚無獨立評估 AI 程式碼執行沙箱市場規模的第三方報告。但以 OpenAI Code Interpreter 為代表的 AI 功能已內建到約數億級使用者產品中，其背後的沙箱基礎設施需求呈高速增長趨勢。

10. 玩家對比

主流的沙箱執行技術方案及廠商對比如下：

方案/產品	提供商	隔離機制	啟動時間	典型記憶體佔用	開源	適用場景
Firecracker	AWS	微虛擬機器 (KVM)	≤125 ms	≥5 MB	是 (Apache 2.0)	Lambda, Fargate
gVisor	Google	使用者態核心 (sentry)	秒級	數十 MB	是 (Apache 2.0)	Cloud Run, App Engine
Kata Containers	OpenInfra 基金會	輕量虛擬機器 (KVM)	數百 ms	約 30–50 MB	是	強隔離容器、金融業
Docker (runC)	Docker/Moby	容器 namespace+cgroup	約 1–5 s	≤10 MB	是	通用容器部署
WasmEdge	CNCF/第二狀態	Wasm 執行時	<0.1 ms	約 50 KB	是 (Apache 2.0)	邊緣、外掛、AI程式碼
Chrome V8 沙箱	Google	程序隔離+seccomp	即時（程序存在）	約 10 MB	是	瀏覽器、Deno
Azure Sandbox	Microsoft	虛擬化+受限令牌	數十秒	依配置	否	Azure Functions、文件隔離

對比維度說明：

• 啟動時間資料來源自各專案官方文件及公開基準測試（Firecracker 參考 NSDI’20 論文，WasmEdge 參考 2023 年 WasmEdge 效能報告，其他為典型觀察到值）。
• 記憶體佔用為僅包含執行時基礎環境，不含應用程式碼。
• “開源”列指專案原始碼是否公開，並不代表完全開放治理。

11. 風險與挑戰

• 沙箱逃逸漏洞：歷史上曾出現多次嚴重逃逸，如 Docker 容器逃逸 CVE‑2019‑5736（2019 年揭露），通過覆蓋 runC 二進位制突破隔離；Firecracker 等微虛擬機器亦曾被發現 virtio 驅動漏洞。每個逃逸 CVE 都可能嚴重衝擊雲端服務信任。
• 側通道攻擊：在同一物理主機上的不同沙箱間，可能通過 CPU 快取、記憶體匯流排等共享資源洩露資訊（如 Spectre/Meltdown 類攻擊）。傳統 OS 隔離難以完全防禦此類攻擊，通常需要額外硬體緩解。
• 效能與安全權衡：提升隔離強度會引入額外開銷。例如，將 AI 程式碼執行從容器切換至微虛擬機器可能增加冷啟動延遲，影響使用者體驗；選擇 Seccomp 嚴格配置又可能阻斷正常系統呼叫，導致應用相容性問題。
• 技術碎片化：使用者面臨 VM、MicroVM、容器、Wasm 等眾多選擇，缺乏統一標準，整合與運維負擔大。
• 合規風險：部分合規架構要求資料不允許離開特定地理區域或某個 Trust Zone，沙箱若設計不當可能造成資料越界。

12. 誤讀糾偏

• 誤讀一：“沙箱 = 虛擬機器，又慢又重。” 糾偏：現代輕量沙箱譜系豐富。容器和微虛擬機器（如 Firecracker）提供接近原生的 CPU、I/O 效能，啟動僅需數十至數百毫秒，早已是雲端原生主流。Wasm 沙箱更以微秒級啟動、極低記憶體腳印成為邊緣和AI程式碼執行的優選。虛擬機器是沙箱最重的一員，但遠非全部。
• 誤讀二：“沙箱是萬能的，能100%防止所有攻擊。” 糾偏：沙箱安全受設計、實現及配置影響。攻擊者可能利用宿主機核心、Hypervisor 或共享元件漏洞實施逃逸；側通道攻擊可繞過部分沙箱機制；內部合法行為的資料洩露沙箱也難完全阻止。安全實質為縱深防禦體系，沙箱是其中重要一環，但需與網路分段、訪問控制、審計等結合。
• 誤讀三：“Wasm 只適用於瀏覽器。” 糾偏：隨著 WASI 標準化，Wasm 已成功進軍伺服器端。Node.js、Docker、Kubernetes 均支援 Wasm 執行時，使其成為跨平台、輕量級、高密度沙箱的理想選擇，尤其適合無伺服器和 AI 生成程式碼執行場景。
• 誤讀四：“容器隔離已經足夠，無需額外沙箱。” 糾偏：預設 Docker 容器共享核心，其隔離強度弱於虛擬機器。多租戶環境或處理高風險程式碼（如使用者提交的 AI 生成程式碼）時，應採用微虛擬機器、Kata Containers 或加固容器配置（User Namespace、Seccomp、只讀根檔案系統），形成強化邊界。

13. 最新事件（截至2025年初）

• Wasm 沙箱加速進入生產環境：2024 年下半年，Docker 在其桌面版和 CLI 工具中預設整合 Wasm 執行時支援，使用者可直接 docker run Wasm 包。WasmEdge 被 CNCF 接納為沙箱專案後，釋出 0.13 版，新增 AI 推論外掛和基於 WASI‑NN 的 GPU 介面，沙箱可直接安全呼叫本地 AI 加速器。
• OpenAI 強化 Code Interpreter 隔離：2024 年，OpenAI 升級 Code Interpreter 沙箱，採用基於微虛擬機器的多層級隔離，阻斷檔案系統、網路等真實訪問，併為每次會話生成一次性、不可追溯的環境，會話結束後立即銷燬所有資料。
• AI Agent 場景的沙箱應用爆發：Anthropic 於 2024 年末推出 Computer Use 功能，其程式碼執行和操作動作均在託管沙箱中執行，並通過使用者確認控制敏感操作。多家 AI 初創公司（如 CodeGen、E2B）推出專為 LLM Agent 設計的沙箱 API 服務，提供按毫秒計費的程式碼執行環境。
• 容器逃逸漏洞引發產業警惕：2024 年一些容器執行時和 Linux 核心漏洞 (如 CVE‑2024‑21626 影響 runC) 被曝光，多個雲端服務商緊急修補，再次凸顯沙箱執行中持續安全監控與快速響應的重要性。
• 混合沙箱架構出現：部分雲端廠商開始提供“容器 + 微虛擬機器 + Wasm”統一排程平台，允許使用者根據敏感等級動態選擇隔離級別，在成本與安全間取得平衡。

14. 追蹤指標

投資者和產業觀察者可重點關注以下指標以追蹤沙箱執行技術演進與市場熱度：

1. CNCF 專案與沙箱生態：containerd、Kata Containers、gVisor、WasmEdge 等專案的 Star 數、貢獻者數量、釋出節奏，以及 CNCF TOC 接受的新沙箱專案。
2. WASI 標準更新：WASI Preview 2 及後續版本的功能落地，包括網路套接字、HTTP、檔案系統等介面標準化進展。
3. 無伺服器與 AI 計算服務呼叫量：AWS Lambda、Azure Functions 呼叫次數增長，以及 OpenAI、Anthropic 等揭露的程式碼執行會話數（若有公開資料）。
4. 漏洞與賞金規模：主流容器/沙箱平台 (Docker, runC, Firecracker, gVisor) 每半年公佈的逃逸類 CVE 數量，以及廠商的漏洞賞金計劃獎金上限，側面反映安全投入。
5. AI 程式碼執行商業化：提供沙箱即服務 (Sandbox‑as‑a‑Service) 的創業公司融資額和新產品釋出，顯示資本對“AI 安全執行”賽道的認可。
6. 行業會議議題：Black Hat、DEF CON、USENIX Security、KubeCon 等峰會中有關沙箱逃逸、新型隔離技術、Wasm 安全的演講數量與影響力。

15. 信源與延伸閱讀

本頁內容基於公開資料、開源專案文件及行業報告綜合梳理，關鍵信源包括：

• 學術論文：Firecracker: Lightweight Virtualization for Serverless Applications (NSDI’20)
• 開源專案官方文件：Linux Kernel (namespaces, cgroups, seccomp); Docker; containerd; gVisor; Firecracker‑containerd; Kata Containers; Wasmtime; WasmEdge; WASI 提案庫
• 行業報告：Mordor Intelligence, “Serverless Computing Market Size & Share Analysis – Growth Trends & Forecasts (2024 – 2029)”, 2024; MarketsandMarkets, “Container Security Market – Global Forecast to 2028”, 2023
• 雲端廠商技術部落格：AWS Open Source Blog (Firecracker 效能基準測試); Google Cloud Blog (gVisor 架構與實踐); Microsoft Azure 文件 (Azure Sandbox)
• 安全事件：CVE 資料庫 (CVE‑2019‑5736, CVE‑2024‑21626); GitHub Security Lab 及廠商安全公告
• 其他：CNCF 專案列表與年度調查; Black Hat, USENIX 等學術/安全會議公開議題; WASI.dev 標準程序

宣告：市場資料和預測均引自前述公開報告，具體數字基於各機構在特定年份的口徑與假設，本頁不構成任何投資建議。