技能就是程式碼，程式碼需要檢查點

技能就是程式碼，程式碼需要檢查點

NVIDIA 本週開源了一套名為 SkillSpector 的工具。它的職責很窄，而且早該有人做了：在代理載入技能之前，掃描其中的安全問題。這套專案內建了對 64 種弱點模式的偵測，這個數字值得停下來想想，因為它意味著有人真的坐下來，把技能可能出錯的方式逐一列了出來。

與此同時，Cloudflare 發布了一個安全稽核技能，能對程式碼庫執行多階段稽核並輸出機器可讀的發現結果；GitHub 則詳述了一個具備情境感知能力的密鑰偵測分類器，它把真實發現結果的加權採納率提升了 11.5%，同時把掃描中位耗時降低了 86%。三個不同的團隊，三個不同的角度，結論一致：代理取得指令的這一層已經成為基礎設施，而基礎設施就要接受稽核。

技能到底是什麼

「技能」這個詞讓整件事聽起來比實際溫和。技能不是一個設定項。它是一組指令，而且往往還包含指令碼、範本和工具定義，代理會讀取它們，並以自己被授予的權限照著執行。

最後半句話就是整個安全模型的一句話總結。技能不需要漏洞利用，因為它不是「闖進來」的。它是被請進來、拿到鑰匙、被請求幫忙的。如果它的指令是惡意的，或者只是寫得隨便，代理都會把它們當作你自己的意圖去執行，因為在它看來，它們就是。

這正是套件管理器在幾十年前遇到的問題，而解法也一樣：假定供應鏈是敵對的，並在其中設置檢查點。代理生態在這條路上還處於早期，所以像 SkillSpector 這樣的專案，其重要性遠超它的 star 數所暗示的程度。

為什麼 64 種模式是最有意思的數字

一張包含 64 種弱點模式的清單就是一套分類法，而分類法正是一個領域走向成熟的標誌。在沒有它之前，每次事故都是意外；有了它之後，事故就變成已知類別中的一個實例，這意味著它們可以被測試、被追蹤，最終被設計規避。

其中一些類別在一般軟體裡早已熟悉：不安全的 shell 指令、未經驗證的輸入、被寫進本不該保存密鑰的檔案裡的憑證。另一些則專屬於這個新層。例如悄悄擴大代理權限範圍的指令；把不可信內容拉進來並當作命令對待的提示詞；對工具功能描述不實，導致代理因為錯誤的原因去呼叫它；以及把多個技能串成一條沒人預料到的呼叫鏈。

最後一類正是難點所在。一個技能有多危險，恰恰與它的觸達範圍成正比，而現代代理能觸達的東西很多：檔案系統、網路、其他代理，以及其他技能註冊的工具。一個壞技能的影響半徑不是這個技能本身，而是代理能碰到的一切，而這取決於先載入了哪些其他技能，是個不斷變動的目標。

情境被投毒的問題

代理安全裡最讓人不舒服的一點是，資料與指令之間的邊界不受任何機制強制約束。模型讀的是文字，它天生無法分辨哪些句子是供它參考的事實，哪些是必須服從的命令。

所以，一個會抓取網頁、讀取 issue 追蹤器、或者摘要郵件的技能，都在把代理暴露給可能含有指令的文字。如果模型照做了，從任何傳統意義上講都不存在漏洞利用。有的只是一個系統，按某個它本不該信任的東西所說的去做了。

這就是為什麼掃描必須在載入時進行，而不是在出事之後。一旦技能已經在擁有廣泛權限的代理裡執行起來，那個關鍵問題早就已經被糟糕地回答了。檢查點必須前置，而且必須自動，因為對註冊表裡每一個技能都做人工審查，規模上根本行不通，將來也不行。

稽核正在變成一個產品

Cloudflare 的這次發布指向第二個趨勢。它的稽核技能輸出的是機器可讀的發現結果，而不是一份需要人去讀的清單。這個措辭是有實質意義的。需要人讀的發現結果，人只會掃一眼；而流水線能消費的發現結果，可以被自動轉成工單、被阻擋的合併，或被拒絕的部署，不需要任何人記得去看。

GitHub 的密鑰偵測工作符合同一個模式。密鑰外洩的規模與程式碼產出量成正比，而程式碼產出量已大幅上升。應對方式不是「多招幾個審查員」，而是一個具備情境感知的分類器，用來削減雜訊，讓人真正看到的告警更可能是真的。在安全工具裡，精確率決定了到第三個月還有沒有人願意看告警。

這兩者都是在不同層面上做的同一件事：與其要求人更警覺，不如讓自動檢查足夠好，使人的注意力只花在真正重要之處。這是唯一能扛住海量規模的策略。

底層的治理問題

這裡還有一層政策面的變化，其速度比大多數團隊意識到的更快。版本控制系統開始攜帶來源溯源中繼資料。套件註冊表開始加入認證聲明。標準組織正在研究如何替合成內容標記、如何識別一個代理。趨勢指向這樣一個世界：製品的來源與完整性必須可證明，而不是靠假設。

技能在這個世界裡處於尷尬位置，因為同一個技能可能因情境不同而既有用又危險。一個能修改檔案的技能對程式碼代理不可或缺，但對一個同時會讀取不可信郵件的代理卻是災難。信任決策不是技能本身的屬性，而是技能加上環境、再加上它能觸達的其他技能共同決定的屬性。

這也意味著掃描器最終要做的將不只是模式比對。這套工具真正困難的版本，會檢查一組被提議組合使用的技能是否授予了沒人要求過的能力，並在上線前而不是上線後發出警告。

團隊現在該做什麼，而不是反應過度

恐慌不是正確的反應，把它當作別人的問題同樣不對。

實際做法並不光鮮。把第三方技能當作不可信依賴來對待，因為它們確實就是。固定版本，並在它們變化時審查差異。在影響半徑受限的環境裡執行代理，這樣一個壞技能不會僅僅因為圖方便就構到網路或生產資料庫。記錄載入了哪些技能、它們做了什麼，因為任何事故之後第一個難回答的問題就是：當時到底允許了什麼在執行。

這個產業以前走過這條路。套件生態曾經不安全，後來被弄得攻擊起來很麻煩，而這種「麻煩」正是關鍵。代理技能正在走向同樣的平衡點，而本週發布的這些專案，是第一批認真嘗試搭建檢查點的努力。在事故之前做到，代價比事故之後更低，而要提早做到，唯一需要的就是甘於做枯燥之事的意願。