Perplexity 在 ２０２６ 年 ５ 月 ２２ 日開源 Bumblebee，定位是開發者本機端點的供應鏈掃描工具。它要解決的不是傳統 repo 掃描問題，而是 AI agent 時代更麻煩的一層：風險常常藏在開發者電腦上的套件、MCP 設定、IDE 擴充與瀏覽器擴充裡。
當 AI coding agent、瀏覽器 agent 和 MCP server 變多，安全團隊不能只看 GitHub repo 或 CI artifact。真正能被 agent 呼叫的工具、設定和擴充，很多都在本機。
Bumblebee 是什麼？
Bumblebee 是 Perplexity 開源的 Go 專案，目前面向 macOS 和 Linux 開發者端點。它的用途是幫安全團隊回答一個很急的問題：
某個供應鏈漏洞或惡意版本出現時，哪些開發者電腦已經暴露？
官方說明中，Bumblebee 檢查四類表面：
- Language package managers。
- AI agent configs。
- Editor extensions。
- Browser extensions。
這些剛好都是 AI 開發者工作站最常被忽略的攻擊面。
它會掃哪些東西？
官方列出的支援範圍包括：
| 類別 | 例子 |
|---|---|
| 套件管理器 | npm、pnpm、Yarn、Bun、PyPI、Go modules、RubyGems、Composer |
| AI agent 設定 | MCP |
| 編輯器擴充 | VS Code、Cursor、Windsurf、VSCodium |
| 瀏覽器擴充 | Chrome、Comet、Edge、Brave、Arc、Firefox |
這個範圍很值得注意，因為它把 AI agent 的風險視為「開發者端點問題」，而不是只把它當成應用程式原始碼問題。
為什麼 AI agent 讓本機掃描變重要？
以前供應鏈安全常圍繞：
- lockfile。
- SBOM。
- CI build。
- container image。
- production dependency。
但 AI agent 讓開發者本機變成更敏感的環境。
原因很簡單：agent 可能讀本機檔案、呼叫 MCP server、操作瀏覽器、使用 IDE 擴充，甚至在多個工具之間移動資料。如果某個擴充或 MCP 設定被污染，風險不一定會出現在 repo 裡。
這也是 Bumblebee 的切入點。它不是取代 SBOM 或 vulnerability scanner，而是補上「開發者電腦現在有哪些可被 agent 觸及的元件」。
Read-only 設計為什麼重要？
Bumblebee 的一個關鍵設計是 read-only。官方強調它不執行 package manager，也不跑 install scripts 或 lifecycle hooks。
這很重要，因為近期多數供應鏈攻擊都可能透過安裝或執行腳本擴散。如果掃描工具為了檢查風險而呼叫 npm install、pnpm、bun 或 pip，掃描本身反而可能觸發惡意程式。
Bumblebee 避免：
- 執行程式碼。
- 呼叫套件管理器。
- 讀取應用程式原始碼。
- 做 process 或 network monitoring。
它讀的是 metadata，例如 lockfiles、manifests、已安裝套件 metadata 和擴充清單。這讓它更適合在事件反應時大量部署掃描。
適合哪些情境？
Bumblebee 適合用在：
- npm 惡意套件事件。
- PyPI typosquatting 事件。
- MCP server 設定盤點。
- Cursor、Windsurf、VS Code 擴充盤點。
- 瀏覽器擴充風險確認。
- 開發者端點暴露範圍調查。
- 安全團隊需要快速產生受影響清單。
不適合期待它做：
- EDR。
- 即時網路監控。
- 原始碼弱點掃描。
- production runtime 防護。
- 自動修補。
Bumblebee 比較像事件發生後的端點盤點與暴露確認工具。
和 SBOM、SCA 工具有什麼差？
| 工具類型 | 看什麼 | 缺口 |
|---|---|---|
| SBOM | 專案與 build artifact 的元件清單 | 不一定知道開發者本機安裝了什麼 |
| SCA | repo dependency 與弱點 | 不一定涵蓋 MCP、IDE、瀏覽器擴充 |
| EDR | endpoint 行為與威脅偵測 | 不一定理解開發工具供應鏈語境 |
| Bumblebee | 開發者本機 metadata | 不做 runtime 阻擋或程式碼分析 |
比較合理的用法，是把 Bumblebee 當成安全團隊的端點盤點補強，和既有 SBOM、SCA、EDR 並用。
企業可以怎麼導入？
可採用的流程：
- 安全團隊維護一份惡意套件、版本、擴充或 MCP 設定清單。
- 在開發者 macOS 或 Linux 端點執行 Bumblebee。
- 收集掃描結果到 SIEM、ticket system 或內部 asset inventory。
- 依嚴重程度要求開發者移除或更新。
- 把事件結果回填到供應鏈風險規則。
掃描結果不應只停在「有沒有中」。比較成熟的團隊會記錄版本、路徑、來源、使用者、機器、時間，才能做後續追蹤。
重點整理
Bumblebee 的價值，不是它多會修漏洞，而是它抓準了一個新問題：AI agent 的安全邊界已經延伸到開發者本機。
當 MCP、IDE agent、瀏覽器 agent 和多種套件管理器一起存在，安全團隊需要知道 agent 能碰到什麼。Bumblebee 用 read-only metadata 掃描補上這一層，對供應鏈事件反應很實用。