Community生產力與協作github.com

Alan-Lucena/claude-skills

Claude Code 技能市集 (技能: 修復) – 一套引導 AI 代理以安全、循序漸進的方式修復安全漏洞的工作流程。

claude-skills 是什麼?

這項技能為 Claude Code 提供一個嚴格且結構化的安全修復處理程序,特別適合「Vibecoder」這類開發者——他們可能不熟悉安全修補的影響範圍。技能的核心原則是「永不盲目刪除」:在接觸任何生產環境資源之前,必須先確認有哪些元件正在使用它。整個流程分為八個步驟:從分級分類(根據嚴重性與不可逆性排序)、處理關鍵/不可逆問題、處理身份驗證與公開合約變更,到強制性的驗證(必須重現攻擊並證明漏洞已關閉)、回歸測試、防護措施(撰寫自動化測試)、批量處理低風險項目,以及最終的結案摘要。特別值得一提的是,技能要求每一個閘道都使用 AskUserQuestion 工具,提供明確的選項而非自由輸入,讓決策過程更快速且不易出錯。此外,技能還內建一系列自動檢查,用於偵測修補是否僅是表面功夫(例如僅檢查 token 存在而未驗證所有權)、主要分支與生產環境的同步問題,以及重複的輸入驗證路徑。這套工作流程支援 Claude Code 平台,並透過嚴謹的流程確保每一次修復都是完整、可驗證且不會破壞既有功能的正確修補。

相容平台✓Claude Code~Codex CLI~Cursor
npx skills add Alan-Lucena/claude-skills

Installed? Explore more 生產力與協作 skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

修復安全漏洞

你的工作不是「一次修好全部」。而是按照正確的順序修復, 驗證每個修復,並且不破壞已經正常運作的部分。使用者通常是 Vibecoder:不要假設他理解爆炸半徑,請解釋清楚。

黃金法則

在刪除、下架或停用任何生產環境中的東西之前,絕對不能不先回答: 「今天有哪些東西在使用它?」(前端、任務、其他端點、儀表板)。先檢查再刪除。 如果有正當的元件在使用它,請停止並通知使用者,不要繼續操作。

如何在每個閘道提問

在流程因需要確認而暫停的每個點(例如提議的順序、身份驗證計畫、 套用不可逆操作之前),請使用 AskUserQuestion 工具,而非使用自由文字提問。 使用者是 Vibecoder,更喜歡從選項中選擇,而不是自行撰寫答案。

每個閘道的模式:

  • 簡短的標題(例如「第 1 級嚴重」、「身份驗證計畫」、「套用差異」)。
  • 典型選項:「核准並開始」(建議選項,列為第一個)、「先調整」、「先檢視/進一步說明」。
  • 每個實際決策只問一個問題。不要把使用者可能想分別核准的事情合併到一個問題中 (例如,啟動第 1 級和核准第 2 級計畫是兩個不同的問題)。
  • 如果決策取決於使用者尚未看到的內容(例如,差異尚未顯示),請先顯示該內容,然後再提問。

流程

1. 分級分類

根據嚴重性與不可逆性對漏洞進行排序,而不僅僅是嚴重性。 一個「高風險」但在生產環境中中斷流程的漏洞,比一個孤立的「嚴重」漏洞更棘手。 將每個漏洞分類為:

  • 孤立 + 可逆 → 可以直接修復。
  • 影響身份驗證 / 變更公開合約 → 在撰寫程式碼之前需要先制定計畫。
  • 刪除或下架生產環境中的基礎設施 → 需要在觸碰任何東西之前,確認「今天有哪些東西在使用它」+ 備份 + 回滾計畫。

呈現提議的順序並暫停。在使用者確認之前,不要繼續進行修復。

2. 先處理嚴重 / 不可逆的項目,僅限單一項目

  • 在刪除/下架之前:列出今天有哪些東西正在呼叫它。如果它確實是孤立的,請留下備份(受影響資料表的匯出)和回滾計畫。
  • 只套用一個變更。不要與其他漏洞混合。
  • 在繼續之前先進行驗證(步驟 4)。

3. 身份驗證 / 公開合約的修復

  • 首先用文字擬定計畫:你要加入什麼驗證、今天有哪些合法客戶端在呼叫、以及如何避免破壞它們。等待核准。
  • 然後才撰寫程式碼。

4. 驗證(每個修復都必須執行)

重新執行發現漏洞的相同攻擊/PoC,並顯示「之前有漏洞 / 現在已被拒絕」。 沒有重現,修復不計為已關閉。 只說「已經修好了」是不夠的。

5. 回歸測試

確認合法的流程仍然正常運作(例如,如果你在某個端點加入了身份驗證,請確認官方客戶端仍然可以運作)。說明你測試了什麼。

6. 防護措施

對於每個已確認的漏洞,加入一個能夠重現該漏洞並在漏洞再次出現時使測試失敗的測試。 如果無法測試,請留下說明原因的備註。

7. 批量處理快速修復

低風險的漏洞(標頭、輸入驗證、查詢修復)可以合併到一個提交中, 但是在套用之前,請列出每個漏洞及其差異。

8. 結案

最終摘要:哪些已修復並驗證、哪些仍待處理及其原因 (例如,主網前需要多重簽章)、以及哪些變更需要使用者手動部署。

自動檢查(不要跳過,不要等使用者要求)

使用者是 Vibecoder,可能會核准一個看似有效但實為裝飾性的修復。在 宣告漏洞已關閉之前,請自行執行這些檢查,如果任何一項適用,即使沒人要求也請說出來。

  • 身份驗證 = 身份,而非存在。 一個僅驗證 TOKEN 已送達的閘道並不能關閉 IDOR。 確認 Token/會話已綁定到身份(錢包、使用者 ID),並且你將該身份與請求的資源進行比較。 如果「所有權」(403)檢查沒有基於真正的綁定,那麼修復是虛假的。
  • 主分支 = 生產環境。 如果你從未合併的分支部署了修復,那麼生產環境運行的程式碼不在 main 上: 下一次從 main 的部署將還原這些修復。通知使用者需要合併,並將其標記為安全風險,而不是整潔性問題。
  • 審計人員也可能犯錯。 在套用修復之前,在實際程式碼中驗證漏洞的假設 (例如,「客戶端發送 Token」可能是假的)。 基於錯誤假設的修復會破壞生產環境。
  • 已接受的風險要記錄下來,而不是保持沉默。 如果某些東西沒有被修復(靜態 Token、 因破壞流程而被還原的金鑰輪換),請將其記錄為已接受的風險,而不是「已關閉」。
  • 驗證要在所有端點上進行,而不是只在一個端點。 如果某個欄位在 PATCH 上有驗證,但在 POST 上沒有(反之亦然), 漏洞仍然存在。檢查同一資料的所有輸入路徑。
  • 刪除會留下痕跡。 在下架/刪除之後,審計資料表或資源中是否有漏洞留下的資料; 不要假設還原端點就能清理已經造成的損害。

輸出風格

  • 在套用任何不可逆或部署變更之前,顯示差異。
  • 未經步驟 4 的重現,不要宣告「已解決」。
  • 如果某個漏洞在調查後被證明是誤報,請說出來,不要「修復」它。

相關技能