GitHub Copilot Security extension 公開預覽：警報到修補怎麼接，權限與費用一次看

修一個安全警報，常需要先讀警報內容，再回到程式裡找原因。Copilot Security extension 把這兩段工作接在同一個 App，讓開發者能從問題直接往修改走。

GitHub 在 2026 年 10 月 28 日開放這項公開預覽。團隊可以在 Copilot App 檢視既有程式碼掃描警報，請 AI 解釋問題，或協助修改本機程式。

這裡的程式碼掃描，是先由安全工具找出可疑問題，再交給團隊判讀與修補。因此，能安裝外掛，不代表已取得每個私人程式庫的掃描權限。

Fix 產生的程式修改會停留在本機工作副本，不會替你提交或推送程式。這保留了審查空間，但團隊仍得確認修補真的消除了風險，也沒有破壞正常功能。

如果團隊已有掃描警報，這次更新適合用來縮短定位與修改的往返。若還沒建立掃描與審查流程，先補好這些條件，比直接把所有警報交給 AI 更有用。

要把它接進工作，得先弄清楚既有警報和本次修改的檢查各由誰處理。

Copilot Security extension 可以處理哪些安全工作？

外掛把既有掃描警報與本機修改的安全檢查放在一起，但兩者的資料來源不同。先分清它正在顯示哪一種問題，才知道應回到哪裡確認狀態。

依 GitHub 正式公告，如果程式庫已啟用程式碼掃描，外掛可以列出尚未處理的警報，依嚴重程度排序，也能用搜尋與篩選縮小範圍。

打開警報後，使用者可以看問題細節與受影響程式。若需要更多上下文，也能回到 GitHub 網站上的完整警報頁，將 AI 的解釋與原始發現對照。

這個連接減少了手動搬運資訊的步驟。開發者不必只靠一段貼到對話裡的摘要來理解問題，也比較容易保留原始警報和修改之間的關係。

既有警報與新修改怎麼一起看？

/security-review 則用來檢查本次工作中的修改，結果會出現在既有警報旁邊。如果程式在上次審查後又有變動，外掛也會提醒需要重新檢查。

因此，舊的審查結果不能直接替後續修改背書。若代理先改一版，再依需求補上另一個行為，團隊就應確認第二次變更是否仍被檢查，而非只看第一版曾經通過。

警報也會顯示已連結的拉取請求，也就是正在交由團隊審查的程式修改提案。開發者可以先看有沒有人正在修同一個問題，避免同時做出兩份互相競爭的修補。

這些功能把問題、程式與審查連得更近，但它們各自回答不同問題。警報說明哪裡可疑，修改提案說明準備怎麼處理，最後仍要有結果證明修補有效。

看得到問題之後，下一個門檻是帳號是否有權讀取這些警報。

能安裝外掛，為什麼還需要 Code Security 與程式庫權限？

外掛可用資格、掃描是否啟用和警報存取權，是彼此獨立的條件。只確認安裝成功，還不足以判斷團隊能否用它完成既有警報的處理。

GitHub 公告說明，任何 Copilot 方案都可安裝外掛，並針對自己的本機修改執行安全審查。但要讀取既有警報，程式庫須已啟用掃描，帳號也須有查看警報的權限。

私人程式庫還需要 GitHub Code Security。這是既有的程式安全產品條件，外掛不會因為能叫模型解釋問題，就自動替公司取得掃描授權。

企業還要確認哪些設定？

使用 Copilot Business 或 Enterprise 的團隊，管理者需要啟用 Copilot App 政策。企業管理設定也能控制開發者可安裝哪些外掛，所以個人看得到安裝入口，不代表公司已允許使用。

這些限制會直接影響開始方式。如果外掛能做本機審查，卻沒有列出公司的既有警報，應先確認掃描、帳號和組織政策，不要立刻認定資料不存在或程式庫沒有風險。

截至 2026 年 10 月 29 日，這項外掛在 github.com 與採資料落地區域設定的 GitHub Enterprise Cloud 提供公開預覽，GitHub Enterprise Server 尚不支援。

兩種企業產品不能只因名稱相近就互相套用。採用自架 Server 的團隊，應保留原有警報處理流程，等待對應支援，而不是照雲端版教學假設所有功能都能連接。

對有權限的開發者而言，確認可見範圍也有助於解讀結果。某個警報不在清單上，可能與存取權或篩選條件有關，不能直接當成已經修好。

取得正確的警報範圍後，才適合讓模型解釋原因並準備修補。

Explain、Fix 與 Dismiss 會改動什麼？

Explain 協助理解問題，Fix 產生本機程式修改，Dismiss 則影響警報處理狀態。把三種動作分清楚，才能知道每一步要核對的是程式還是警報。

表中的 Fix 不會提交或推送程式。開發者可以先在本機看修改、再要求調整，等審查完成後才由團隊決定如何送出。

這也保留了容易被忽略的責任分工：模型可以提出修改，但是否接受它，需要知道專案原本的使用情境與測試標準。外掛列出「已修改」，不等於正式系統已套用修補。

解除警報不等於完成修補

Dismiss 適用於團隊決定不採取修補的警報，例如需要依專案情境判定是否適用的發現。解除之前仍應留下理由，讓其他人理解為何不處理。

如果組織使用委派式警報解除機制，外掛會把這項動作送交核准。因此，開發者提出解除要求，和警報最後是否獲准解除，也可能是兩個階段。

模型也能在聊天中透過外掛工具處理警報，但仍遵守工具權限設定。聊天方式較方便，不會使所有查詢或修改自動獲得額外授權。

例如，若先請模型解釋一個輸入處理問題，再要求它修改對應程式，兩段工作的交付就不同。前者應說得出問題如何形成，後者則要拿出變更與驗證，不能只把解釋重寫一遍。

動作邊界分清楚後，團隊才能把最重要的精力留給修補驗收。

修好警報之前，先保留哪些測試證據？

驗收修補要同時確認問題不再成立，以及原本的正常功能仍能使用。只看到新增一段檢查程式，還無法知道它有沒有在正確的位置發揮作用。

以下以一個輸入檢查警報為假設情境。團隊可以先保留觸發警報的原始路徑，指出哪些輸入會進入不安全的處理，再請模型說明它準備限制哪一段行為。

這樣做能把修補目標固定下來。如果修改只是換掉警報旁邊的寫法，卻沒有處理資料真正經過的位置，審查者就比較容易發現問題仍存在。

接著檢查本機差異。除了模型聲稱改好的檔案，也要看是否出現不必要的相依套件、被刪掉的檢查，或與警報無關的行為變動，避免審查範圍悄悄擴大。

正常情境也要留下來

安全修補可能擋住不當輸入，也可能誤擋原本有效的使用者操作。因此，驗證時應保留一組正常資料，確認原來允許的功能仍可通過。

如果測試因環境或缺少資料而沒有執行，就把這個缺口留給接手的人。這是本刊建議的交付方式，不能把沒有跑完的檢查寫成已完成，也不代表外掛會自動替團隊補齊測試環境。

同一項警報若已有連結提案，應把本次測試與既有修改一起看。這有助於避免新提案修了另一個版本，最後合併時又把原本的修補覆蓋掉。

嚴重程度之外，也要知道程式用在哪裡

清單能依警報嚴重程度排序，卻不能替團隊理解所有業務情境。以同一種輸入問題為例，若一處直接接收外部使用者資料，另一處只是封存的範例，安排修補時就需要不同的背景資訊。

這是團隊判讀警報的示例，不代表這兩種情境已由外掛自動分類。開發者可以先請模型指出受影響的函式、資料入口與相關呼叫，再由了解專案的人確認程式實際如何使用，避免只依一句解釋決定處理順序。

交接時也可以把警報與提案的關係寫清楚，說明本次準備處理哪些發現、哪些另有負責人。這讓後續審查知道修改的邊界，不必看到多個相近警報，就猜測一份修補是否已經涵蓋全部情況。

當審查後再修改程式，則可利用外掛對變更的提醒，重新檢查受影響部分。審查的有效範圍應跟著實際版本走，而非沿用某次對話中的完成敘述。

這套做法把驗收留在原始警報、程式差異與可重跑的測試上。當結果有依據，團隊才看得出外掛減少了哪一段定位和修正工作。

哪些操作會消耗 AI 額度，團隊怎麼開始？

瀏覽和解除警報不使用 AI，請模型解釋、修補或執行安全審查則會消耗 AI 額度。這項差別影響的，是團隊如何安排日常分流與深入處理。

依公告，Explain、Fix 與 /security-review 使用 App 中選定的模型，計費方式和其他提示一樣。若反覆要求不同解法，這些呼叫也應納入完整處理成本。

因此，團隊可以先看警報的嚴重程度、負責人和既有提案，再決定哪些需要模型協助。讓模型讀取所有警報，並不會自動替團隊建立合理的修補優先順序。

如果只是要查看一項警報有沒有其他人在處理，原有清單和連結資訊可能已足夠。把模型用在理解複雜原因或準備修改，才比較容易衡量它帶來的價值。

官方設定文件提供外掛安裝與警報處理方式。使用者可在 App 的 Customize 搜尋 github-security，安裝後從程式庫工作階段開啟 Security 畫布。

對企業而言，開始前還應讓管理者確認政策與方案。若安裝或讀取受限，先找到對應的管理條件，會比不斷換提示詞更接近問題的原因。

先用一個有負責人的警報試走完整流程，從解釋到本機修改、測試與提案審查，都留下對應結果。這樣就能比較花費和人工接手時間，而非只看模型回覆得多快。

代理的操作核准和安全警報修補是不同機制，了解前者有助於安排本機工具的使用範圍。

延伸閱讀：GitHub Copilot Assisted Permissions 正式開放：AI 代理的操作何時自動通過？

若團隊也讓多個代理平行修改，則要先掌握工作副本如何隔離，才不會讓審查對到錯誤版本。

延伸閱讀：GitHub Copilot App 平行 Agent 教學：Worktree 是什麼？怎麼同時跑多個開發任務

Copilot Security extension 常見問題

私人程式庫可直接查看既有警報嗎？

私人程式庫需要 GitHub Code Security，也須啟用掃描，使用者還要有查看警報的權限。能安裝外掛與能讀取既有警報，是不同的條件。

Fix 會自動推送或合併嗎？

公告明確說明，Fix 只修改本機工作副本，不會提交或推送。團隊仍需審查差異、確認測試，並依原本流程決定是否送出與合併。

GitHub Enterprise Server 支援嗎？

這次公開預覽支援 github.com 與採資料落地區域設定的 Enterprise Cloud。公告不支援 Enterprise Server，自架環境應保留既有流程。

安裝外掛就等於程式安全嗎？

外掛提供警報解釋、修改與檢查的入口，沒有替完整專案做安全保證。實際採用仍須核對掃描範圍、修補影響與正式系統使用情境。

讓警報、修改與證據接在一起，才算縮短修補流程

對已經使用程式碼掃描的團隊，這項外掛值得從一個警報開始驗證。它能讓資訊與本機修改靠近，但最後是否完成修補，仍應由程式差異和測試證明。

先把讀取權限、模型花費與審查責任安排好，再擴大處理範圍，較容易留下可接手的成果。免費訂閱 AI 郵報，持續掌握開發工具的更新與使用條件。

資料來源

• GitHub：Security extension 發布公告。
• GitHub Docs：檢視與修補安全警報。