週六早晨的八項資安發現

稽核會挖出東西。誠實的做法是歡迎它、修好每一項，並交付永久防護欄——這正是一個執行環境贏得企業信任的方式。

稽核報告在上週稍晚寄進了收件匣。到了週六早上，我一個螢幕開著報告，另一個螢幕開著程式庫。八項嚴重或高風險發現。那種足以定義一整個週末的收件匣內容。

這是企業盡職調查。一家潛在合作夥伴在讓律師繼續推進之前，請他們的資安團隊對公開 API 表面做了一輪檢查。這些發現具體、解釋清楚，而且完全公允。它們同時也是那種——如果你不刻意防範——代理驅動的工作流程會讓你特別容易中招的問題。

到週六結束時，每一項發現都有一個 PR 落地修復。這篇文章要講的，就是每一項是什麼。

這些類別是什麼

我要談的是類別而不是具體的利用細節，因為細節現在已經修復、對競爭者也不再有趣；類別才是其他團隊會想防範的東西。

第一：公開 REST 表面的輸入驗證。有幾個端點對輸入的信任超出了應有的程度。具體來說：字串輸入的長度界限、數值輸入的範圍界限，以及 JSON 酬載的結構驗證。缺失的驗證單獨來看都不致命。但「這裡沒有長度界限、那裡沒有速率限制、這個管理端點又沒有驗證檢查」的組合，一旦攻擊者摸清了表面，就會變成致命的疊加。

第二：設定檔中寫死的憑證。和幾個週末前的 HMAC 發現不同。這次是一個設定範本，範例版本裡提交了一個真實憑證。原意是要提供一個佔位用的範例憑證；實際交付的卻是來自某位開發者本機環境的真實值。處置：輪替憑證、從範例中移除、加入 CI 的密鑰掃描流程。

第三：不安全的加密套件協商。一個與外部服務協商 TLS 的子系統，接受了在 2026 年不應被接受的加密套件。具體來說，是數個帶有已知弱點的前 TLS 1.3 套件。修復方式是把加密套件清單限制為僅限 TLS 1.3 的集合，並保留一個有文件記載的逃生口（一個明確的旗標），供測試舊式合作夥伴系統時使用。

第四：C API 邊界的釋放後使用（use-after-free）。其中一個執行環境 DLL 的 C API 有一個函式會回傳指向內部狀態的指標，而呼叫端在對同一個控制代碼的後續呼叫已釋放該內部狀態之後，仍可繼續使用這個指標。經典的 C API 自傷武器。修復方式是把語意從「呼叫端持有指標」改為「呼叫端持有不透明控制代碼，並透過 get-by-handle 存取器取值」。存取器在呼叫期間回傳一份新的指標副本，底層記憶體不再暴露。

第五：授權層的執行緒安全漏洞。兩個執行緒可能在並行驗證呼叫期間對同一個授權狀態物件發生競態。在高負載下，一個執行緒可能看到部分更新的狀態，對授權有效性得出錯誤結論。修復方式是在狀態周圍加上正確的讀寫鎖，並針對常見情況（授權有效、不需變更狀態）最佳化驗證路徑。

第六：某個管理端點的授權繞過。其中一個管理端點有身分驗證檢查，卻沒有授權檢查。任何通過驗證的使用者都能呼叫它，包括沒有管理員角色的使用者。修復方式是加上角色檢查、撰寫同時涵蓋「以管理員身分驗證＝允許」和「已驗證但非管理員＝拒絕」兩條路徑的單元測試，並稽核其他所有管理端點是否有同樣的模式。另外三個端點有相同問題。四個現在都正確了。

第七：驗證失敗的記錄不足。當使用者嘗試驗證失敗時，執行環境記錄了這次嘗試，卻沒有記錄足夠的上下文來調查暴力破解或憑證填充的模式。修復方式是對每一次驗證失敗加上結構化記錄，包含 IP 位址、該 IP 的速率限制計數器，以及所嘗試的驗證方式。兼顧隱私（不記錄任何密碼內容），但在需要調查時有足夠的上下文可用。

第八：相依套件更新落後。執行環境引入的第三方相依套件中，有數個在清單中鎖定了已知有漏洞的版本。修復方式是把每一個更新到最新的修補版本、對更新執行測試套件，並解決更新所需的少量 API 形態變更。八個更新中有兩個需要修改我們程式碼中的轉接層；其餘六個可直接替換。Dependabot 現在已設定為自動標記這類問題。

一個資安工作週末教我的事

三件事。不令人意外。但值得說。

資安發現會成群出現。一次冒出八項發現很多。回頭看，模式是它們共享同一個根源：執行環境在代理驅動的工作流程中快速成長，代理們把每件事都「孤立地正確」實作了。像資安這樣的橫切關注點，正是逐 PR 審查會漏掉的東西。稽核抓住審查漏掉的。把稽核排進行程。

有些發現是代理驅動的失效模式。C API 中的釋放後使用，正是當提示說「把這個內部狀態暴露給呼叫端」卻沒有指定擁有權語意時，代理會寫出的東西。授權層的執行緒安全漏洞也類似。兩者抓到的是同一個模式：沒有被問到擁有權和並行性的代理，會寫出兩者都忽略的程式碼。

有些發現是速度驅動的失效模式。相依套件更新落後不是代理的問題。它是「跑得太快、又沒有人專職保持相依套件新鮮」的問題。解法是流程（Dependabot）加紀律（對 Dependabot 的警示採取行動）。解法不是「變得更聰明」。

新的防禦措施

這個週末落地的永久防護欄。

CI 中的資安掃描流程。針對輸入驗證的靜態分析、密鑰掃描、加密套件政策。每個 PR 都跑掃描。引入新發現的 PR 會被標記送審。

管理端點測試模式。API 中的每個管理端點現在都有一組配對測試，同時涵蓋管理員允許路徑和非管理員拒絕路徑。這個模式由一個 CI 檢查強制執行：它掃描 @admin_required 裝飾器，若裝飾器存在卻沒有對應的配對測試，建置就失敗。

共享狀態的執行緒安全註記。執行環境中的每個共享狀態物件現在都帶有關於其並行模型的明確註記：不可變、鎖保護、帶明確 happens-before 的無鎖，或單執行緒。註記是型別的一部分。觸碰該狀態的程式碼必須滿足註記。鎖保護與不可變的情況由編譯器強制執行；其餘交給審查。

行事曆上的每月資安稽核。不等合作夥伴開口。稽核是每月第二個週六的固定項目。第一次在四月執行。

合作夥伴與開發者該從中學到什麼

如果你正在評估一個引擎作為合作對象，並且正準備要求一次稽核，這個團隊會歡迎它。稽核會挖出東西。東西會被修好。程式庫會變好。合作關係會變好。歡迎稽核的紀律，比任何具體發現都重要。

如果你是正在讀這篇文章的企業資安專業人士，我很樂意聽取關於稽核節奏、以及你希望更多引擎團隊稽核哪些具體項目的建議。這個週末的發現是顯而易見的那些。不顯而易見的那些，是我接下來想找到的。

如果你在運行代理驅動的工作流程，而且最近沒做過資安稽核，做一次。「代理寫出孤立正確、卻漏掉橫切關注點的程式碼」這個模式，在這種工作流程形態中是普遍存在的。稽核就是你抓住橫切關注點的方法。我沒有找到其他辦法。

週末結束時的盤點。八項發現結案。六道新防禦落地。下一次稽核已排上行事曆。合作關係向前推進。

回去繼續打造。