2026-05-22，Perplexity 把一個叫 Bumblebee 的內部工具丟上 GitHub。它是一個唯讀的端點掃描器，只跑在 macOS 和 Linux 上，用 Go 寫的，零非標準庫依賴。功能聽起來樸素到不像 2026 年的 AI 公司會做的事：檢查開發者筆電上有沒有裝到有問題的套件、編輯器擴充功能、AI 工具設定檔。
但這個工具發布的時機本身就是重點。就在 11 天前的 2026-05-11，TeamPCP 用 TanStack 的 GitHub Actions CI 當入口，6 分鐘內發了 84 個惡意套件，當天結束時統計到 169 個 npm 套件被污染、373 個惡意版本。再過幾天，Nx Console 那個有 220 萬安裝量的 VS Code 擴充功能被攻陷，同期 GitHub 自己也被偷走約 3,800 個內部 repo。這篇文章不是要介紹一個工具，是要說：為什麼你需要這種等級的偏執，而且是現在。
一個關鍵設計：它什麼都不執行
說實話，傳統的套件掃描工具有個荒謬的問題——它們會跑 npm ls、pip show 這類指令來盤點環境。問題在於 npm 套件可以帶 postinstall 腳本，這就是最近幾波蠕蟲傳播的主要管道。一個為了偵測攻擊而呼叫 npm 的掃描器，等於是自己觸發了它本來要找的攻擊。
Bumblebee 走極端的反方向。Perplexity 官方部落格列了它不會做的事情：
- 不執行任何安裝腳本或生命週期 hook
- 不呼叫 npm、pnpm、bun、pip
- 不讀應用程式源碼
- 不監控進程或網路流量（它不是 EDR）
那它怎麼掃？只讀 lockfile 跟已安裝的套件 metadata。具體就是 package-lock.json、pnpm-lock.yaml、go.sum、.dist-info/METADATA 這些檔案。一個冷知識：Bun 的二進位 lockfile（bun.lockb）在 v0.1 版本還不支援，只讀文字版 bun.lock。
覆蓋範圍蠻廣：npm、pnpm、Yarn、Bun、PyPI、Go modules、RubyGems、Composer 全都吃，加上編輯器擴充功能、瀏覽器擴充功能、還有 MCP host config。MCP 設定檔這塊特別有意思——這些檔案的 env 區塊常常存著 API key 跟憑證，Bumblebee 會解析這些設定檔來盤點伺服器，但不會把那些秘密寫進輸出記錄。
三種掃描模式
工具設計了三種 profile，對應不同情境：
- baseline：掃常見的全域、使用者套件路徑、語言工具鏈、編輯器擴充功能、瀏覽器擴充功能、MCP 設定。適合外部排程跑的輕量盤點。
- project：掃指定的開發目錄，像
/code、/src、~/work。適合定期掃已知的專案資料夾。 - deep：跑 operator 指定的 root 路徑，包含整個 home 目錄。設計給正在處理資安事件時用的——通常會搭配 ecosystem、exposure-catalog、findings-only 一起跑。
值得一提的設計細節：baseline 和 project 模式會拒絕直接掃 home 目錄，只有 deep 模式能掃整個使用者目錄。這是為了避免人沒事就拿 baseline 掃整顆硬碟、然後當作每天都在做安全檢查的錯覺。
為什麼 Perplexity 自己會需要這個
Perplexity 在部落格裡講得很白：保護 Perplexity 產品的安全，要從保護我們用來開發它的開發者系統開始。這句話對任何認真做產品的公司都成立，但放在 Perplexity 身上特別微妙——因為它自己的 Comet 瀏覽器才剛被研究員爆出零點擊 prompt injection 漏洞。
Zenity Labs 在 2026 年初公開了 PerplexedComet 漏洞鏈：一張惡意的行事曆邀請就能讓 Comet agent 自動跑去翻使用者本機檔案、然後把內容傳到攻擊者的網站，從頭到尾不需要使用者點任何東西。LayerX 的研究數據更狠——Comet 對網路釣魚的脆弱度比 Chrome 高 85%。
把這兩件事放在一起看，Bumblebee 的策略意涵就浮現了：Perplexity 一邊在做最激進的 agentic 瀏覽器（最大的攻擊面），一邊在補開發端的防禦工事。對外開源 Bumblebee 是公關正面性的部分，但對內它就是一個必需品——因為他們的整套產品線都建立在「agent 可以代你行動」的前提上，這個前提一旦失守，反作用力會直接打回開發機。
跟 SBOM 和 EDR 的差別
說白了，這個工具填了一個現有市場的縫隙：
- SBOM（軟體物料清單）和漏洞掃描器：盯 build artifact 和 repo，不看開發者筆電
- EDR（端點偵測與回應）：看跑了什麼進程、碰了什麼網路，不看磁碟上的 lockfile 和擴充功能 metadata
- Bumblebee：唯讀盤點本機開發狀態——lockfile、套件 metadata、擴充功能、AI 工具設定
最後這塊「AI 工具設定」尤其值得注意。2026 年的攻擊已經開始用 MCP 設定當載體，攻擊者污染你的 VS Code 設定或 Claude Desktop 的 MCP 設定後，每次 IDE 開啟就會觸發 payload，完全不需要你跑 npm install。這是傳統 SCA 工具完全看不到的層。
寫程式的人現在該做什麼
如果你是個人開發者，這個工具的價值是「在下一波蠕蟲爆發時，5 分鐘內知道自己有沒有中招」。具體流程很簡單：每次看到資安研究員公告新一波套件污染清單（例如 Socket、StepSecurity、ReversingLabs 這些單位的速報），把 affected version 餵給 Bumblebee 的 exposure catalog，跑一次 deep scan 就能知道。
如果你是團隊負責人，比工具本身更重要的是建立流程。Bumblebee 自己定位是 security team 既有 workflow 的其中一個元件，輸出是結構化的 JSON 記錄，方便餵進你公司既有的 SIEM 或響應流程。
工作環境本身也是攻擊面的一部分。如果你連桌面工作環境都還沒整理好——還在用筆電的小鍵盤、HDMI 直插螢幕沒 USB-C Hub、書架擋住光線——可以先看蝦皮桌面 4 件套這類基本盤組合，把硬體環境先處理好。資安偏執也要從一個能讓你專心的物理環境開始。
真正的訊號
Bumblebee 開源這件事，比工具本身更值得注意的是它揭露的兩個現實：
第一，2026 年的供應鏈攻擊已經把目標從 production 系統往前推到 developer endpoint。當你 clone 一個 repo，光是用 VS Code 打開它就可能被攻擊——因為 .vscode 裡的 settings.json 可能塞了惡意的 MCP server 設定。傳統「build pipeline 加 SAST」的防禦線已經太後面了。
第二，連 Perplexity 這種拿了一堆錢的 AI 公司，都得自己寫 Go 工具來保護自家工程師的筆電。這代表市場上沒有現成的好東西可以買——或者說，能買的都不夠 paranoid。當你的競爭護城河是「我們的 agent 能代你行動」，你的攻擊面就是所有開發者筆電的總和。
值得問自己一句：你今天用的工具裡，有多少能告訴你「上週這個套件是不是中過招」？如果答案是零，Bumblebee 至少給了你一個起點。