上個月在公司 staging 環境踩到一個讓我很不舒服的坑，記錄一下。

事情的起點很普通。我在 ClawHub 上找到一個看起來很方便的 skill，功能說明寫的是「自動清理 /var/log 底下超過 30 天的 log 檔」。我們環境裡幾台機器 disk 很容易滿，這種工具剛好。在 staging 上跑了兩天，沒出問題，準備推 production。

Push 之前我習慣跑一次 openclaw skill inspect，順手看一下 SKILL.md 跟主要的 shell 腳本。然後我就看到一段奇怪的東西。

那個 skill 在清 log 的同時，還有一條 curl 呼叫在背後跑。目標是一個我完全不認識的 endpoint，帶著 hostname 和一些 system metadata。說是「usage telemetry」，但這段完全沒出現在功能說明裡。

我把那個 endpoint domain 丟去查，是一個三個月前才註冊的空殼站，whois 資訊全遮掉。

當下就把那個 skill 從 staging 全部移掉，然後花了兩個小時把那段期間 staging 機器的 outbound traffic log 翻了一遍。幸好 staging 的 egress firewall 規則比較嚴，那個 curl 其實都沒出去。但如果是在 production，我們的出站規則比較鬆，就真的送出去了。

---

這件事讓我重新想了一下 skill 的 threat model。

傳統上我們擔心的是「惡意程式」，也就是會直接破壞系統或加密檔案那種。但 skill 的風險不太一樣。一個 skill 本來就需要執行 shell 指令、讀寫檔案、可能還有網路呼叫。這些能力是功能所需，不是異常。所以一個 skill 表面上在做 A，同時在做 B，傳統的靜態惡意程式掃描很難抓到，因為它沒有「惡意程式的特徵」，只是「有一段不明顯的 side effect」。

換句話說，blast radius 不是「這個 skill 會不會把我機器炸掉」，而是「這個 skill 有沒有在做它沒說要做的事、有沒有取用比它工作需要更多的能力和資源」。

---

從那次之後，我在 staging 部署任何新 skill 之前，現在會做以下幾件事：

第一，手動讀 SKILL.md 和主要腳本。這個很土，但有用。特別注意有沒有網路呼叫、有沒有把系統資訊往外傳。

第二，跑 skill 的時候，在那台機器上同步開著 tcpdump -n -i any 'not port 22'，看有沒有預期外的 outbound 連線。staging 環境的 egress 規則本來就應該比 production 嚴，這個確認是最後一道。

第三，看 skill 申請的 permissions 跟它的功能是否匹配。一個只是「整理 log」的 skill，為什麼需要 network:outbound？能力宣告跟實際功能不匹配，本身就是紅燈。

第四，如果是 ClawHub 上有 verification badge 的 skill，我會優先選這些。自動掃描不是萬能，但總比什麼都沒有好。

---

說起來，這件事最讓我不安的不是那個 skill 本身，而是我之前的習慣。在這件事之前，我大概只要 ClawHub 上的 skill 評分不差、下載量高，就直接裝了。我以為「社群篩選」等於安全。

實測結果是：不等於。

評分和下載量反映的是「功能是否好用」，跟「有沒有額外行為」完全是兩件事。一個 skill 可以同時是好用的和有問題的。

現在的工作流程是：staging 先跑一週，有 tcpdump 做旁觀，確認 outbound 行為符合預期，才推 production。多一道程序，但在 40 台機器的環境裡，一個走漏的 skill 能造成的傷害不是開玩笑的。