要安全審核 GitHub Copilot 建議，先給它一項範圍清晰的小工作，並把每條行內建議視為不可信的草稿。先弄清預期行為，只接受你理解的程式碼行，其餘拒絕或 dismiss；核對程式庫規則和公開程式碼引用，執行必需的測試和掃描，檢查最終 diff，並取得人手程式碼審查。

這是通用使用 AI 方法在編程情境中的應用。它涵蓋 Copilot 建議出現的一刻，以及建議成為你改動一部分之前要通過的關卡。它不能取代更完整的 AI 產生程式碼首次執行前審核，後者還會檢查依賴、權限、外部副作用、數據遷移、生產設定和還原方案。

關鍵要點

只讓 Copilot 處理一項範圍清晰的小工作。

無法逐行解釋的程式碼一律不接受。

編輯器支援時，接受有用部分，拒絕其餘部分。

公開程式碼引用只是調查線索，不是放行結論。

執行程式庫的測試、lint、保安和知識產權關卡。

審閱完整 diff，因為不安全的改動可能不在可見建議之內。

哪些工作適合在不接受不安全程式碼的前提下使用 Copilot？

選擇契約範圍窄、又能快速可靠驗證的工作：補完純函數、加入測試個案、轉換已知數據結構、編寫重複的序列化程式碼，或按程式庫既有的本地模式調整程式碼。先界定輸入、預期輸出、失敗行為和容許修改的檔案。

不要由驗證身份、授權、密碼學、依賴變更、數據遷移、CI/CD、生產設定、機密處理、破壞性操作或敏感數據開始。這些工作並非因為涉及 AI 就被禁止，但執行前必須走完整審核流程，並經相關負責人批准。

在註解或私人筆記中寫下工作範圍：

工作：為一個有文件說明的 enum 值加入解析。
容許檔案：解析器及其單元測試。
必需行為：未知值傳回現有的類型化錯誤。
禁止：新依賴、網絡存取、記錄 payload、退回為成功。
驗證：針對性單元測試、全部解析器測試、lint、最終 diff 審閱。

刪除不應留在生產程式碼的臨時提示註解。絕不可為了改善建議，把機密、權杖、客戶私人資料或機密漏洞細節寫進提示或原始碼註解。

應給 Copilot 甚麼脈絡？

只提供遵循本地契約所需的最少安全脈絡：附近類型、相關介面、預期錯誤模式、一個代表性測試，以及程式庫的命名或風格規則。脈絡太少會誘發捏造；太多則可能洩露數據並分散焦點。

GitHub 的最佳做法指引建議提供有用的脈絡、保持提示清晰、核實輸出，並把 Copilot 當作輔助工具，而不是專業能力的替代品。［2］脈絡可提高相關性，但不會令建議變得正確或安全。

評估補完內容前，先回答：

這段程式碼要加入或保留甚麼行為？
輸入跨越哪條信任邊界？
輸入無效、缺失、空白或過大時應如何處理？
程式庫的做法是失敗即關閉，還是退回預設？
容許哪些副作用？
哪些測試和靜態檢查構成本地關卡？

如果答不出這些問題，先研究程式庫才接受程式碼。不要讓 Copilot 憑函數名稱臆造契約。

如何安全審核 GitHub Copilot 建議中的行內程式碼？

GitHub 文件說明了接受整條行內建議、只接受其中一部分（partial acceptance）或 dismiss 的控制方式。［1］確切的快速鍵和介面因編輯器而異，請以現行文件和可見控制為準。

按下接受前先讀建議。追蹤每個條件、分支、傳回值、狀態改動、記憶體配置、錯誤和外部呼叫，並與工作範圍對照。只在適用於該組件時，才考慮零值、最大規模、格式錯誤輸入、重複呼叫、部分失敗、取消、並行和重試的情況。

檢查那些看似方便、實則削弱安全的模式：

吞掉錯誤並傳回預設成功；
過寬的例外處理掩蓋了原本的成因；
在日誌中記錄機密、權杖、個人資料或完整 payload；
未作必要驗證就以字串拼湊 SQL、shell 指令、路徑、URL 或範本；
停用憑證、主機名稱、簽署、權限或授權檢查；
不安全的隨機數、自製密碼學或可預測的識別碼；
沒有上限的迴圈、記憶體配置、遞迴、查詢或重試；
新增網絡、檔案系統、程序或數據庫副作用；
使用鎖定檔或程式庫慣例中沒有的依賴或 API。

看懂文字解釋並不足夠；Copilot 的解釋來自同一輔助渠道，不是獨立核實。

何時局部接受或全部拒絕 Copilot 程式碼建議？

當一段連續內容明顯符合契約，而其餘部分多餘、帶推測或不安全時，就使用 partial acceptance。例如：保留形狀正確的配對分支，但拒絕捏造的退回邏輯；保留測試的準備部分，但自行編寫保安斷言。

局部接受後，重新閱讀最終程式碼。在原建議中有效的片段，拒絕前後幾行後可能變得不完整。檢查匯入、變數、分支覆蓋、資源清理和錯誤傳遞。

遇到以下情況，應 dismiss 或拒絕整條建議：

不問工具就無法解釋它做了甚麼；
修改的檔案或職責超出工作容許範圍；
未經審核就引入新依賴或副作用；
違反程式庫規則或獲批模式；
削弱了驗證或保安邊界；
較小的手寫改動更清晰、更易驗證。

拒絕很正常：它把沒有依據的程式碼擋在 diff 外，也讓你有乾淨的起點重述工作。

如何檢查 Copilot 公開程式碼引用及授權條款？

GitHub 把程式碼引用（code referencing）描述為一項可能顯示建議與公開程式碼相符之處的功能，並在可行時附上程式庫和授權資料。［3］應把這種 public-code reference 當作來源和授權審查的線索。開啟被引用的資料，確認實際的授權條款和脈絡，評估是否與項目相容，並依照機構的署名和法律程序處理。

沒有顯示引用，並不證明程式碼沒有來源或授權風險。比對系統有門檻和涵蓋範圍限制，簡短或常見的模式可能缺乏辨識度。亦要檢查看似源自外部資料的異常註解、識別碼、演算法、檔頭或長段程式碼。

記錄處理結果：

沒有顯示引用；仍需一般審閱；
顯示引用，建議已拒絕；
已調查引用，並按項目程序批准使用；
引用未解決，改動受阻；
如政策容許，程式碼已獨立重寫並重新審閱。

不要以刪除署名或掩飾來源令相符提示消失。

應執行哪些程式庫關卡？

先執行能證明目標行為的最小測試，再執行程式庫規定的較大範圍檢查。這些可能包括格式化、lint、類型檢查、單元及整合測試、依賴審查、secret scanning、code scanning、授權或 IP scanning，以及特定政策腳本。

NIST 安全軟件開發框架（SSDF）把安全開發實務分為四組：機構準備、保護軟件、產出具良好保安的軟件，以及回應漏洞。［4］Copilot 並不改變這些責任。產生的程式碼與手寫程式碼進入同一個開發生命周期。

測試應涵蓋契約和有意義的失敗模式，不只是跑通正常路徑。亦要審閱 Copilot 建議的測試：產生的斷言可能固化實作錯誤、以 mock 抹去風險，或遺漏負面個案。AI 輔助產生測試的流程可協助擴充個案，但判斷預期結果的應是審閱人。

必需關卡無法執行時，記錄缺口，不要把改動描述為已核實。本機單元測試通過，不等於完整程式庫關卡、CI、特定平台測試或生產驗證已通過。

如何審閱最終 diff？

檢查完整的實際 diff，不只是被標示的 Copilot 文字。接受建議可能觸發匯入、格式化、附近編輯、產生的檔案、鎖定檔變動或人手後續修改。確認 diff 只包含預期的檔案和行為。

按以下次序審閱：

重述工作內容和預期的保安特性；
檢查改動的介面、數據流和副作用；
檢查錯誤和清理路徑；
對照程式庫規則和附近的獲批模式；
檢查測試，確認它們會因正確原因失敗；
以指令和結束狀態核實掃描及測試結果；
刪除臨時提示、除錯日誌、佔位符和未使用的程式碼；
取得具相關領域權限人士的程式碼審閱。

重要的補完內容應使用建議紀錄：

Suggestion ID	Task	Affected lines/files	Understood behavior	Public-code reference	License action	Tests	Security checks	Decision	Reviewer
C-01	解析 enum 值	解析器 + 測試	已知值正確對應；未知值失敗即關閉	沒有顯示／有引用	已調查／不適用	指令及結果	掃描及結果	接受／拒絕／修訂	姓名

紀錄應指向證據，不是照抄模型的自我評估。

哪些情況必須升級完整審核？

驗證身份、授權、密碼學、依賴、數據遷移、CI/CD、生產設定、機密、個人或受規管數據、破壞性操作，以及外部可見的協議變更，都要升級處理。當建議跨越信任邊界、改變持久化儲存、削弱預設設定，或無法在本機環境安全測試時，也要升級。

完整的 AI 產生程式碼執行前審核，會在執行修補前檢查依賴、權限、網絡和檔案系統影響、數據遷移、還原及營運後果。這裏的行內接受流程只是那道更大關卡的其中一項輸入，不能取而代之。

應避免哪些常見錯誤？

只因首幾行看似正確，就接受一大段建議。
要求 Copilot 解釋程式碼，並把解釋當作核實。
保留有用片段，卻不檢查局部接受有沒有破壞脈絡。
以為沒有公開程式碼引用就沒有授權風險。［3］
信任重複同一錯誤假設的自動產生測試。
只執行正常路徑測試，或忽視失敗的必需關卡。
把範圍擴大藏在格式化、匯入、依賴或設定之中。
在敏感程式碼中批量接受建議。

總結

給 Copilot 一項小工作和最少的安全脈絡。
審慎地閱讀、局部接受、拒絕或關閉建議。
調查公開程式碼引用，但不把沒有引用當作放行。
執行程式庫要求的測試、掃描和政策關卡。
檢查完整 diff，並要求合資格的人手審閱。

常見問題

Copilot 建議能編譯，就可以放心接受嗎？

不可以。能編譯並不證明授權、驗證、錯誤處理、並行、授權條款、保安或運作行為是正確的。

可以只接受行內建議的一部分嗎？

GitHub 文件說明，受支援的編輯器可以局部接受。接受後要重讀最終程式碼，因為拒絕前後幾行可能令已接受的片段變得不完整。

看不懂的建議應該拒絕嗎？

應該。拒絕它，弄清本地契約，然後提出較小的要求，或自行寫一個可驗證的較簡單改動。

沒有顯示 public-code reference，便代表建議是原創嗎？

不是。沒有顯示相符之處，不能證明來源清白。仍須照常進行授權條款、署名和程式碼審閱。

Copilot 能核實自己寫的程式碼嗎？

不能。它的解釋和產生的測試可能重複同一個錯誤。應依靠獨立規格、程式庫測試、掃描工具、證據和人手審閱。

哪些建議需要額外審核？

凡涉及驗證身份、密碼學、依賴、數據遷移、CI/CD、生產設定、機密、敏感數據、破壞性影響或信任邊界的建議，都要走完整審核流程。

必需的測試或掃描工具無法使用怎麼辦？

記錄未核實的關卡，不要聲稱改動安全或已完成。把它轉交能完成欠缺驗證的環境或審閱人。

誰作最終接受決定？

由對程式庫和受影響領域負責的開發人員及獲授權審閱人決定。Copilot 提供的是建議，不是批准。AethoVPN 可以是開發人員網絡環境的一部分，但它不能審查 Copilot 建議中的不安全程式碼，也不能批准程式庫變更。

來源

Sources checked 2026 年 8 月 31 日。

GitHub Docs, “Responsible use of GitHub Copilot inline suggestions” — https://docs.github.com/en/copilot/responsible-use/inline-suggestions
GitHub Docs, “Best practices for using GitHub Copilot” — https://docs.github.com/en/enterprise-cloud@latest/copilot/get-started/best-practices
GitHub Docs, “Code referencing in GitHub Copilot” — https://docs.github.com/en/copilot/concepts/completions/code-referencing
NIST, “Secure Software Development Framework” — https://csrc.nist.gov/projects/ssdf

如何安全審核 GitHub Copilot 建議，避免接受不安全程式碼