你是否曾經在準備提交程式碼時，突然想到：這段輸入驗證真的擋得住攻擊嗎？剛加入的 API 金鑰會不會被寫進記錄檔？如果現在就建立 Pull Request，才發現漏洞，修復成本可能已經比編寫功能高出許多。
這正是許多開發者搜尋「GitHub Copilot App /security-review 怎麼用」的原因。它不是完整的滲透測試工具，也不是用來取代既有安全平台的萬能掃描器，而是一個放在開發流程中段、針對目前程式碼改動進行快速檢查的入口。真正重要的問題是：你應該在什麼時候使用它、如何解讀結果，以及修復後怎樣確認沒有引入新問題。
GitHub Copilot App /security-review 是什麼，適合放在哪個環節？
GitHub Copilot App 的 /security-review 是活動 Agent 會話中的斜線指令。根據 GitHub 官方文件，它會檢查目前工作流中的程式碼改動，回傳按優先次序整理的安全發現，並附上嚴重性、置信度與建議修復方式。這項功能目前仍屬於公共預覽，能力與指令格式可能改變。(docs.github.com)
它最適合放在以下位置：
- 已完成一個功能，但尚未提交或建立 Pull Request。
- Agent 已經修改多個檔案，需要先做一次快速安全審查。
- 即將把資料庫查詢、檔案處理、驗證流程或權限邏輯交給其他人複核。
- 已經修復一項漏洞，想在同一個會話中重新檢查改動。
GitHub 公開說明提到，這類審查特別關注注入、跨網站指令碼、不安全資料處理、路徑穿越及弱加密等常見高影響問題。(github.blog)
不過，GitHub Copilot App 安全審查仍有三個容易被忽略的限制。第一，它主要看目前工作流的改動，不等於對整個儲存庫重新建立完整安全模型。第二，AI 可能因缺少執行環境、部署設定或外部服務上下文而漏判。第三，結果是風險提示，不是自動批准合併的證明。對高敏感程式碼，人工複核與規則化掃描仍不可省略。
執行前需要滿足哪些條件？
在詢問「GitHub Copilot App /security-review 怎麼用」之前，先確認以下四項，否則很容易得到空白結果，或誤以為功能失效。
第一，要有活動 Agent 會話。
/security-review 不是在任意聊天視窗中執行的通用問答指令。你需要開啟一個正在處理專案的活動會話，並讓該會話載入工作區內容。
第二，要有可辨識的本地程式碼改動。
如果工作區沒有未提交變更，或你只開啟了專案卻沒有修改任何檔案，審查可能沒有足夠的目標。執行前可先檢查版本控制差異，確認改動確實包含你想檢查的檔案。
第三，帳戶與組織政策必須允許使用。
官方資料顯示，GitHub Copilot App 已支援 Copilot Free、Pro、Business 與 Enterprise 使用者；Business 及 Enterprise 環境仍可能需要管理員啟用 Copilot CLI 政策。(github.blog)
第四，要接受公共預覽的變動性。
公共預覽功能可能調整可用模型、輸出格式或適用範圍。團隊不應把目前介面截圖或單次審查結果寫死成永久流程，最好保留人工檢查與替代工具。
第一步：開啟專案並確認改動範圍
在 GitHub Copilot App 中開啟要檢查的專案，進入與該專案對應的 Agent 會話。先不要立即輸入指令，而是確認以下內容：
- 目前分支是否為預期的功能分支。
- 是否存在尚未提交的本地程式碼改動。
- 改動是否包含測試、設定檔、資料庫查詢或權限邏輯。
- 是否有不應送入 AI 會話的秘密資料，例如真實 API 金鑰、個人資料或生產環境憑證。
GitHub Copilot App 的會話採用隔離工作區與分支概念，適合把安全審查放在一個可回滾的變更範圍內。(docs.github.com)
第二步：輸入 /security-review 並限定審查目標
在活動會話的提示欄輸入：
/security-review
如果改動較大，可以補充清晰的審查範圍，例如：
/security-review 請優先檢查本次改動中的輸入驗證、權限判斷、檔案路徑處理與秘密資料暴露風險。
這樣做的目的不是強迫 Agent 找出問題，而是提供檢查方向，減少它把注意力分散到無關檔案。GitHub 官方 CLI 指令參考將 /security-review 定義為針對活動本地程式碼改動的聚焦式安全審查，並回傳優先排序的漏洞發現與修復建議。(docs.github.com)
成功標誌通常包括：
- 回覆明確指出審查了哪些改動。
- 發現按風險優先次序排列。
- 每項發現包含嚴重性或置信度資訊。
- 建議內容能對應到具體檔案、函式或資料流。
第三步：不要只看嚴重性，還要看置信度
嚴重性回答的是「一旦成立，可能造成多大影響」；置信度回答的是「目前證據有多支持這個判斷」。兩者不能混為一談。
可以用以下方式理解：
- 高嚴重性、高置信度：優先暫停提交，先確認觸發路徑並修復。
- 高嚴重性、低置信度：不可忽略，但應先補充上下文、測試與人工驗證。
- 低嚴重性、高置信度：可排入近期修正，尤其是涉及日誌、錯誤訊息或權限邊界時。
- 低嚴重性、低置信度：不要機械式修改，先判斷是否只是風格建議或不適用情境。
例如，Agent 指出使用者輸入可能進入資料庫查詢時，真正要確認的是：輸入是否可由外部控制、是否經過參數化處理、資料庫帳戶權限是否過大，以及該路徑是否真的能被使用者觸發。單看「高風險」三個字就重寫程式，可能造成不必要的回歸。
第四步：根據觸發路徑修復，而不是直接接受建議
閱讀發現後，先要求 Agent 說明四件事：
- 哪一個外部輸入可以控制這段資料。
- 資料經過哪些函式或服務。
- 哪個邊界缺少驗證、編碼或權限檢查。
- 建議修復會不會影響既有 API、測試與相容性。
接著才套用修復。常見修復方向包括：
- 將字串拼接改為參數化查詢。
- 對輸出內容進行正確情境的編碼。
- 以允許清單限制檔案路徑或命令參數。
- 將秘密資料移出原始碼與除錯記錄。
- 降低服務帳戶權限，避免使用全域管理權限。
- 對加密、工作階段與驗證流程採用框架正式支援的方式。
這裡要特別注意敏感程式碼。身份驗證、付款、權限提升、檔案上傳與個人資料處理，不應只由 AI 建議決定。至少要由熟悉該系統威脅模型的人檢查修復是否真的封住攻擊路徑。
第五步：執行測試，再次進行安全審查
修復後不要直接建立 Pull Request。建議依序完成：
- 執行受影響模組的單元測試。
- 執行輸入驗證、權限與錯誤處理的整合測試。
- 重新檢查版本控制差異，確認沒有產生不必要檔案。
- 搜尋是否殘留金鑰、權杖、密碼或測試用秘密。
- 再次執行
/security-review。 - 對仍存在的發現逐項記錄「已修復、誤報或待人工確認」。
- 最後才提交程式碼或建立 Pull Request。
重新驗證的價值在於確認修復後的程式碼，而不是重複閱讀舊結果。例如把查詢改成參數化之後，新的問題可能轉移到錯誤訊息、權限設定或日誌輸出；第二次審查能協助你檢查改動後的整體狀態。
Copilot 本地程式碼漏洞掃描，與其他工具怎樣分工？
「Copilot 安全審查和 CodeQL 區別」的核心，不在於哪一個工具比較強，而在於檢查時間與檢查對象不同。
- GitHub Copilot App
/security-review：針對活動 Agent 會話中的本地程式碼改動，適合提交前快速檢查與修復後複查。它是按需執行，回饋集中在目前工作流。 - CodeQL：適合對儲存庫或 Pull Request 執行規則化程式碼分析，建立可追蹤的安全掃描流程。它不能被一次性的 AI 審查取代。
- Dependabot：主要處理開源相依套件的版本與已知漏洞風險，不是用來分析你剛寫的業務邏輯。
- secret scanning：專注尋找可能暴露的秘密資料，例如憑證與權杖；它與程式碼邏輯漏洞是不同問題。
因此，較穩妥的組合是：本地改動先用 /security-review，Pull Request 與主要分支使用 CodeQL，套件風險交給 Dependabot，秘密暴露則由 secret scanning 與人工檢查共同處理。GitHub 官方也明確將 /security-review 定位為補充 code scanning、Dependabot 與 secret scanning 的輕量按需檢查，而不是取代它們。(docs.github.com)
/security-review 沒有結果、誤報或漏報怎麼處理？
遇到問題時，建議按以下順序排查：
沒有結果：
先確認是否在活動 Agent 會話、工作區是否有未提交改動，以及專案是否真的載入成功。再縮小指令範圍，明確指出要檢查的檔案與安全疑點。
出現誤報：
不要直接刪除相關程式碼。先驗證輸入是否可控、是否有既有防護、實際部署是否會經過該路徑。確認為誤報後，在審查紀錄中寫明理由，方便下一位維護者理解。
疑似漏報：
補充更完整的上下文，要求 Agent 檢查特定資料流，並使用測試、CodeQL 或專業人工審查交叉驗證。AI 安全審查對環境變數、反向代理、雲端權限、執行時設定及跨服務流程可能缺少完整視野。
本站測試倉庫案例：用可回滾分支驗證流程
在本站測試倉庫進行這類演練時，建議不要直接修改主要分支，而是先建立可回滾的測試分支，加入一個可控且不涉及真實資料的安全問題，例如未經限制的檔案路徑、缺乏輸入驗證的查詢，或測試用秘密被寫入記錄檔。
實際紀錄可分成五段：
- 引入問題：記下檔案、函式、輸入來源與預期風險。
- 執行審查：在活動 Agent 會話輸入
/security-review，保存輸出內容。 - 人工複核：確認觸發條件、嚴重性與置信度是否合理。
- 套用修復：要求 Agent 先說明修改計畫，再執行變更。
- 重新驗證：執行測試、檢查差異，再執行一次安全審查。
這種案例的重點不是追求每次都得到相同結果，而是驗證團隊能否把 AI 發現轉化為可重現、可審核、可回滾的安全流程。若測試需要長時間保持 macOS 開發環境、分支與測試服務在線，可以再參考 Kvmzen 的雲端 Mac 租用環境，並依照當站即時頁面確認可用方案。
結語：把安全審查放到合併之前
如果你目前只依靠本地手動閱讀、提交後才等待 Pull Request 檢查，常見缺點是回饋太晚、修復時上下文已經分散，而且安全問題容易與功能改動混在一起。只依靠套件掃描也看不到自訂輸入處理、權限邏輯與檔案操作；只依靠 AI 則可能受限於上下文，無法覆蓋完整儲存庫與部署環境。
因此，GitHub Copilot App /security-review 比較適合成為「提交前的一道快速關卡」，而不是唯一防線。你可以在可回滾的測試分支中加入一個可控問題，完成掃描、人工複核、修復與重新驗證，再把同樣流程納入團隊的 Pull Request 習慣。若你需要持續在線的 macOS 測試環境，Kvmzen 的 Mac 租用方式通常比臨時維護本地機器更容易保持穩定的測試工作流；開始前也可先查看 Kvmzen 幫助中心 了解連線與使用安排。