AWS 把漏洞修補送進 Pull Request，最後一個「批准」仍握在企業手裡

文／TARAISG 研究編輯整理。本文由 AI 協助研究、寫作及出版查核，未經具名真人資安專家複審；封面為 AI 原創概念插畫。治理分工與假設案例供企業規劃參考。

2026 年 11 月 2 日｜企業資安與 AI 治理專題

如果一套 AI 系統已經找出程式漏洞、證明攻擊者可能利用它，甚至把修補程式寫好，企業是否可以直接讓它修改正式系統？這個看似技術性的問題，實際上涉及權限、責任與營運風險。修得快固然重要，但誰有資格認定修補有效、誰能批准上線，以及出事後誰負責回復服務，同樣不能省略。

Amazon Web Services（AWS）於 2026 年 10 月 22 日宣布，AWS Continuum for code vulnerabilities 正式全面推出。它將程式碼掃描、漏洞驗證、風險排序與修補建議結合成一個工作流程，並能把修補結果交付到開發團隊使用的 Pull Request（程式碼合併請求）。但依 AWS 同日的正式上市說明，目前每項修補仍需人員審查並批准。AWS 提出的下一步，是讓企業在自行定義的安全限制下，逐步授權某些修補自動執行；這不能被誤讀成今天已可不經批准任意修改正式環境。

這項產品值得關注的原因，不是 AI 第一次能夠找漏洞，也不是第一次能寫程式。真正的變化，是資安工作中原本彼此分離的幾件事開始串起來：看見問題、判斷問題有多危險、提出可執行修補、把變更送回軟體開發流程。當前面的工作加快，原本不明顯的管理問題反而更清楚：企業的批准制度是否跟得上 AI 產出修補程式的速度？

修補程式已經寫好，為什麼還不能說漏洞修好了？

一家企業的購物系統發現安全問題，過去可能先由掃描工具產出報告，再交給資安人員判斷，之後建立工單，等待工程師理解程式與依賴關係、安排修改、執行測試。若系統牽涉付款、會員資料或訂單紀錄，還要決定何時部署，以及如何在出問題時回復原版。這是常見的工作模式，不代表每家公司都遵循同一套流程。

如今，AI 能完成其中更多前段工作。問題在於，人們容易把「提出修補」與「完成修復」說成同一件事。兩者至少隔著三道門：第一，補丁是否真正解決漏洞；第二，程式修改是否會破壞既有功能；第三，經過批准的版本是否已經部署到實際受影響的環境。某一關通過，不代表後面兩關也已通過。

AWS 在上市文章的實際操作示範中，展示一項已產生 Pull Request 的修補。官方特別提醒，補丁已產生，不等於問題已修復。團隊仍須查看變動並決定是否合併。這句話看似保守，卻精確界定了產品能力與企業責任。修補建議是候選解法；正式合併是版本控制決策；完成部署與再驗證則是另一個營運事實。

Pull Request 可以理解成一份要求把修改納入主程式的申請。它通常包含變更的程式碼、說明、測試結果與審查紀錄。PR 被建立後，原有的分支保護、必要審查者與持續整合測試仍可成為重要控制點。企業可以讓 AI 提交申請，但不必因此取消原本的審查制度。相反地，AI 產出速度越快，審查條件越應明確。

AWS Continuum 做的事，不只是再提供一份掃描報告

傳統漏洞掃描常以風險等級、漏洞編號、弱點型態或受影響元件提醒團隊。這些資訊必要，但不足以回答主管最關心的問題：哪些問題會真的影響公司？一個被標成高風險的漏洞，若部署位置與外部網路隔離，處理次序可能不同於另一個可以接近客戶付款資料的問題。反過來說，表面嚴重性不高的缺陷，若能與多個權限弱點連成攻擊路徑，也可能值得優先處理。

AWS 表示，Continuum 會結合程式碼來源與 AWS 環境資訊，建立所謂的情境關聯圖（Context Graph）。這張圖不是單純列出伺服器名稱，而是試圖描述元件依賴、雲端資源、身分權限、網路可達性，以及系統之間的關係。透過這些脈絡，工具才有機會判斷漏洞所在的位置、可能到達哪些資源、與哪些重要業務系統相連。

接著，它會分析掃描結果與相關程式碼。對可以再現的問題，AWS 說明系統會在隔離的沙箱環境嘗試驗證可利用性，提供重現證據、可能攻擊路徑與影響範圍。沙箱可以理解成一個與正式營運隔開、供測試使用的環境。它的價值是讓人員不只看見「掃描器認為有漏洞」，還能查看工具如何支持這個判斷。

驗證後，Continuum 依業務影響排列處理順序，再提出程式碼修補、套件升級或設定變更等建議。對 GitHub 連接的程式碼工作流程，AWS 展示了直接建立 Pull Request，並附上風險與修補脈絡的操作方式。如此一來，資安團隊和工程師討論的不再只有一張孤立的弱點清單，還多了可以逐行檢視的候選修改。

這是一項重要的流程整合，不應被寫成萬能保證。情境圖是否完整，取決於系統能取得什麼資料；沙箱能再現的攻擊，不必然涵蓋所有真實世界條件；能修好某個程式錯誤，也不代表所有相關業務情境已安全。資訊更完整，有助於決策，卻不能替代決策。

真正需要批准的，不只是一個「合併」按鈕

企業若把「人工批准」理解成最後有人點一下同意，仍然低估了治理問題。從第一性原理看，批准其實是給系統某種行動權限。不同權限對應不同風險，也應由不同角色負責。要讓 AI 修補真正進入企業流程，至少應將四種批准分開設計。

第一種是掃描與存取的授權。AI 要分析哪些程式庫？可以讀取哪些雲端設定、權限資訊和應用程式脈絡？誰同意讓第三方服務接觸這些資料？企業需要明確規定範圍、資料分類、存取權限與使用目的。技術團隊認為掃描有幫助，並不自動代表資料擁有人、系統負責人或合規單位已批准。

第二種是修補內容的批准。當工具提出一項變更，工程師需要檢查這段程式是否符合既有架構、是否誤改其他功能、是否引入新的依賴與權限。資安團隊則要確認它對原漏洞的處理方式，以及證據與測試是否充分。即使兩種職務由同一人兼任，也應把各自的檢查目的記錄清楚。

第三種是部署變更的批准。合併到程式庫，與變更已經進入正式營運系統，是兩件事情。具有商業風險的系統需要變更時段、部署順序、服務監控與回復計畫。某些團隊採自動部署，某些需要變更委員會或值班主管簽核；關鍵不是每家公司都要增加會議，而是變更權限應符合失敗後果。

第四種是修復完成的驗收。工程師已合併程式碼，並不代表資安人員可以立即關閉事件。應確認實際部署版本、受影響環境與原漏洞的再驗證結果。若只有測試環境更新，正式環境仍未處理，就不應把整件事標記為已解決。這也解釋了為何企業需要將 PR、部署紀錄與弱點工單彼此關聯。

四種批准的先後順序、簽核人數與自動化程度可以因風險而異，但它們不應混為一談。若一家公司唯一的控制機制就是「AI 修好後交給工程師看看」，便可能把上游的資料授權問題與下游的上線責任全都忽略。

讓 AI 自動產生 PR，管理者究竟要看到什麼？

主管通常無法逐行審查所有程式，也不應被要求代替工程師執行技術審核。主管需要的是足以批准風險承擔的資訊。換句話說，他要知道改動影響哪些業務、如果不修會怎樣、現在修可能造成什麼服務中斷，以及是否有可信的回復方法。

一份適合正式決策的修補單，至少應顯示：漏洞影響的系統及環境、可利用性的證據等級、可能影響的資料或流程、提議修改的檔案與元件、執行過的測試、尚未覆蓋的情況、部署方式、回復計畫、責任人與最後核准紀錄。這些字段不必全部由人手填寫，卻必須能被追溯。

例如，假設某家企業的會員平台存在跨租戶資料存取問題：使用 A 客戶身分的請求，可能讀到 B 客戶的資訊。AI 提議修改權限檢查邏輯，並在測試環境通過一組案例。技術審查的問題是「變更是否正確限制權限，是否會影響合法使用者」；業務審查的問題是「會員服務能否接受這次調整，回復方案是否足夠」。兩個問題都沒有答案，就不宜只因 AI 給了綠色勾選而直接上線。

以上是為說明批准制度而設定的假設情境，並非 AWS Continuum 已處理某家企業的真實案例。這個區分很重要。AI 安全工具提供的示範、供應商的成效描述，以及真實客戶的可重複觀察結果，不能混寫成同一層級的證據。

AWS 提到 Learn 與 Enforce，現在究竟有多自動？

這次發布特別容易被誤讀的地方，是 AWS 同時談到了兩種操作方向。依 10 月 22 日的產品公告，Continuum 從 Learn mode 開始，先提出修補建議，讓人員批准。公告也描述企業可在信任度足夠後，透過 Enforce mode，讓系統在設定好的限制內採取自主行動。

然而，AWS 同日較詳細的上市文章說得更明確：現行流程中的每個修補都需要人員審查和合併，允許特定類型修補自動執行則屬未來規劃。獨立技術媒體 DevOps.com 在 10 月 27 日的報導，也將自動套用修補列為後續方向。因此，截至本文查核日期，最穩妥的解讀是：已正式上市的功能以產生建議、建立 PR、等待人工批准為明確可確認的操作方式。至於 Enforce 是否已在個別帳戶或特定情境可用，不能單憑概念性產品文字斷言全面開放。

即使未來可以自動執行，也不代表企業應把所有修補一視同仁。比方說，更新一個測試環境內的低風險開發依賴，與修改處理客戶付款的驗證邏輯，可能需要完全不同的控制。合理的自動化應建立在明確的適用範圍、成功測試門檻、影響上限與停用機制之上，而不是把「我們信任 AI」當成政策。

所謂 Guardrails，就是企業先劃定 AI 的行動邊界，包括可讀取哪些資料、允許修改哪些系統、每次能改動多大範圍、哪些測試必須通過，以及何種情況要交還人員處理。對修補型 Agent 而言，這些約束應能在實際工具及程式碼流程中執行，而不是只寫在內部簡報上。

AI 可能修對漏洞，卻修壞另一個功能

自動修補最直觀的好處，是縮短發現漏洞到提出修補方案之間的時間。但軟體本身存在大量隱含規則：某個欄位的空值有特殊意義、某個服務依賴過去的 API 行為、某個批次程序只在月底執行。程式碼表面上安全，仍可能破壞實際工作流程。這不是 AI 專屬缺陷，人工修補也會遇到；只是當產生變更的速度提高，未被審查的變更數量也可能跟著增加。

因此，企業不應只要求 AI 提供「漏洞已被擋住」的測試結果。比較完整的驗收至少涵蓋安全性、功能性、相容性與可回復性。安全性要檢查原先的攻擊路徑是否失效；功能性要確保正常操作不受影響；相容性要看 API、相依套件和其他系統是否仍能運作；可回復性則要確認部署出問題時能否快速復原。

測試也有邊界。單元測試通常檢查個別程式功能，整合測試則觀察元件間如何配合；這些測試若沒有覆蓋真正的業務情境，全部通過也不是零風險證明。對於高度敏感的權限、金流、醫療、營運或工控系統，企業可能需要增加人工審查、隔離環境驗證與業務負責人的批准。

另一個容易被低估的問題是錯誤的優先順序。Continuum 強調透過業務情境排序風險，這方向合理，但前提是情境資訊正確且持續更新。若工具不知道某個舊服務其實承載核心業務，或不知道某條網路連線剛剛開放，就可能低估問題。企業仍應提供系統重要性、資料敏感度、資產負責人與網路變更的可靠來源。

它會取代原有資安工具、滲透測試與資安團隊嗎？

不宜這麼推論。傳統靜態程式碼分析（SAST）主要從程式碼尋找可能的弱點；軟體成分分析（SCA）關注第三方套件與其已知風險；滲透測試則嘗試站在攻擊者角度，驗證系統是否存在可利用的漏洞。這些方法有重疊，也各有盲點。Continuum 的方向是把多種發現、情境分析、驗證與修補串成連續流程，不代表它已證明能取代所有其他技術與人工檢查。

AWS 自身也把 Continuum for code vulnerabilities 與 Continuum for penetration testing 分成不同能力。後者源於 AWS Security Agent，提供按需的滲透測試。不同服務的適用環境、計費方式與驗收工作不同。採購時若只看到 AWS Continuum 這個總名稱，便可能把原始碼修補與應用程式實測的能力混在一起。

還有一個重要差異是測試者的獨立性。若同一套 AI 產生修補方案，又由同一組測試假設判定修補成功，就要確認是否具有獨立的驗證機制。高風險系統仍可要求第二種掃描工具、不同測試團隊或獨立授權的安全審查。自動化可以讓資安團隊把時間從重複整理報告移到設計控制與處理例外，但是否真能達到這個效果，仍需由實際使用數據檢驗。

費用不是只看 AI 用了多少 Token

企業評估這類服務，也必須把價格說清楚。AWS 公布 Continuum for code vulnerabilities 採兩個計價維度：一項是依受保護程式碼行數計算的每月 Context fee，另一項是依安全分析工作量收取的 Continuum Inference Unit（CIU）費用。AWS 公布的基礎價格是前 1,000 萬行程式碼每 100 萬行每月 US$200，以及每 CIU US$10；階梯費率會隨程式碼規模調整。

AWS 官方舉例，假設一家團隊保護 100 萬行程式碼，每月處理 100 個漏洞，且每個漏洞平均消耗 1 CIU，情境費用為 US$200，推論費用為 US$1,000，合計約 US$1,200／月。這是供應商的假設算例，不是承諾每家公司都會花同樣金額，也不包含企業內部審核、測試、部署與其他間接成本。

所謂「成本節省」也要追問原本由誰執行工作。若企業本來就不會逐一驗證每個漏洞，使用 AI 後產生了更多證據與審查任務，支出可能先上升，而不是下降。這不必然表示導入失敗，因為先前被忽略的風險可能終於進入處理程序；但財務評估應分開衡量新增的安全覆蓋、人工投入變化與實際事故風險下降，而非只把工具採購費用與人力薪資相減。

這也使 ROI（投資報酬率）問題變得更具體。若 AI 每月新增 100 份修補 PR，但原有團隊只能審查 20 份，剩下 80 份仍在排隊，企業不一定得到相應的風險下降。反之，若工具先把真正危險的問題排出來，縮短查證與跨部門協調時間，即使產出的 PR 數較少，也可能帶來較高價值。採購效益不能只以「每月掃描多少漏洞」衡量。

適合主管追蹤的指標，是從發現到確認高風險漏洞所需的時間、從確認到核准修補所需的時間、從核准到實際部署的時間、修補後再驗證的成功率，以及因修補導致的回滾或服務異常。把這些時間分段，才能知道瓶頸究竟在工具、審查、測試還是上線流程。否則只是把工單產生速度當成業務成果。

台灣企業導入前，先確認資料與區域限制

AWS 10 月 22 日公告的正式可用區域為美東（維吉尼亞北部）與美西（奧勒岡）。這不等於台灣企業不能評估服務，但可能涉及帳戶部署、資料流向、程式碼處理位置、跨區操作與內部資料治理要求。尤其當原始碼包含商業秘密、權限設計或客戶資料處理邏輯時，資安與法遵團隊應先確認實際服務條款、存取路徑和組織政策。

技術上的第一步，是決定哪些程式庫適合連線。AWS 的官方操作說明提到 GitHub 與 Amazon S3 等程式碼來源，並利用 AWS 環境資訊輔助判斷風險。對使用其他原始碼平台、封閉網路、地端部署或多雲架構的企業，不能只憑產品宣傳就假定能同樣無縫運作；應先用一個有限的測試範圍驗證所需權限、資料流與結果品質。

第二步是避免把所有權限交給一個共用帳號。掃描權限、產生 PR 的權限、合併主分支的權限，以及部署正式系統的權限，應盡可能分離。即使某個團隊規模不大，也能透過儲存庫分支保護、審查規則、CI 測試與操作紀錄建立基本控制，不必等到成立大型資安部門才開始。

第三步是處理例外情況。假設修補必須跨越相依的三個微服務，或修改會導致既有客戶 API 失效，系統不應因「AI 有信心」就自動放行。企業應定義何時改採人工決策、誰有權承擔業務中斷風險，以及何時必須退回原版本。這些不是技術團隊故意拖慢速度，而是讓速度可以長期維持的條件。

企業今天可以建立的批准權矩陣

導入這類工具最有用的第一份文件，不是採購規格，而是誰能批准哪種變更的矩陣。一種務實的分工方式是：系統擁有人核定可掃描與可修改的範圍；資安人員確認漏洞證據與風險等級；程式碼負責人審查修補內容；測試負責人確認功能及安全測試；服務或變更負責人批准正式部署；稽核或治理窗口保留可追溯紀錄。這是建議的管理設計，不是 AWS 強制規定的組織架構。

同樣一個補丁，在開發測試環境與在正式交易環境，批准流程未必相同。企業可按資產重要性、資料敏感程度、變更可逆性與影響範圍分類。能快速回復、影響有限、測試充分的低風險修改，較有條件縮短審查；涉及身分驗證、授權、資料隔離或重大金流的修改，則需要更嚴格的權限與證據。

比起一開始就追求無人值守，先完成一個小型、可驗收的試點更有價值。例如，挑選非核心程式庫，確保 AI 只能讀取指定範圍並提交 PR，不能自行合併或部署。接著觀察兩週內的漏洞驗證品質、PR 可採納率、審查耗時與測試退回原因。若這些結果可靠，再討論擴大使用範圍。任何擴權都應有可撤銷機制與明確的事故通報程序。

技術團隊可能更關心誤報與漏報，主管則重視服務可靠度與成本，法遵人員則重視存取與留存。好的導入制度不是要求所有人採用同一個績效指標，而是把各自的關切放進同一個可驗證流程。如此一來，「AI 修補成功」才能從一句軟體供應商口號，變成企業能查核的事實。

下一階段競爭的重點，是修補後的證據鏈

以往資安自動化常停留在「發現」：掃描工具列出風險，人工再接手處理。AWS Continuum 代表的新方向，是把發現、驗證、排序與修補提案接到開發工作流。從管理角度看，下一步的競爭焦點可能是證據鏈的完整性：一個漏洞如何被發現、為何被排在前面、修補方案如何產生、由誰批准、在哪個版本上線，以及上線後是否再次驗證。

這條證據鏈越完整，企業越有機會把安全管理從「有多少待處理警告」轉向「真正危險的暴露已下降多少」。但它也讓責任更無法模糊。AI 可以協助形成判斷，供應商可以交付工具，真正握有程式碼、正式環境和客戶承諾的企業，仍須決定自己願意授予系統多少權限。

若未來 Enforce 類型的自主修補更加成熟，批准不一定永遠表現為每次由某個人按下合併鍵。它可能轉移為預先批准一套政策，由系統在政策內執行，並在超出界線時自動停止、回報與升級處理。但授權可以預先設計，責任不能因為自動化而消失。誰制定這套政策、誰驗證政策有效、誰有權停止自動化，才是 AI Agent 真正進入企業正式營運後必須回答的問題。

AWS 這次宣布的意義，因此不只是多一個會寫修補程式的 AI。它迫使企業重新分配三種工作：把重複查找與整理交給機器，把需要專業判斷的審查留給適當人員，再用可追溯的制度連接兩者。企業下一次收到「AI 已完成漏洞修補」的報告時，最值得追問的不是它寫了多少行程式，而是：誰批准、哪個版本已上線、怎麼證明問題真的解決？

常見問題

AWS Continuum 能夠自動找出並修補所有漏洞嗎？

不能如此保證。它能協助掃描、驗證、排序與產生修補建議，但是否涵蓋所有技術堆疊、是否能再現每種漏洞，以及能否正確修補特定業務邏輯，仍須依實際環境驗證。它不是對任何程式或資安風險的全面保證。

AI 寫好的補丁，是由 AWS 還是企業批准？

依 2026 年 10 月 22 日 AWS 正式上市文章，現行流程須由企業人員審查與合併 Pull Request。企業還應自行確立掃描授權、程式碼審查、部署與修復驗收的權責。供應商的修補建議不等於企業已批准正式上線。

什麼是 Pull Request？

Pull Request 是開發者請求將程式碼修改合併到目標分支的工作機制。它可讓團隊查看變更差異、測試結果、審查意見與核准紀錄；建立 PR 本身不代表修補已部署。

Learn mode 與 Enforce mode 有何不同？

Learn 指由系統提出修補建議、由人核准的模式；Enforce 則是 AWS 描述的、在企業設定限制下增加自主行動能力的方向。官方同日詳細上市文章仍明示每項修補需要人工核准，因此企業應以實際帳戶功能及 AWS 最新文件確認可用範圍，不可預設已全面自動上線。

企業要如何衡量 AI 漏洞修補的投資報酬率？

應把修補建議數量與真正完成修復的成果區分。建議追蹤高風險漏洞的確認時間、人工審查等待時間、部署完成時間、再驗證成功率、回滾事件，以及服務總成本。若只看掃描數或產生的 PR 數，可能高估效益。

台灣企業可以直接在台灣 AWS 區域使用嗎？

AWS 2026 年 10 月 22 日公布的 Continuum for code vulnerabilities 正式可用區域是美東維吉尼亞北部與美西奧勒岡，未列出台灣區域。企業應先確認最新區域資訊、帳戶資格、資料治理及跨區要求，再決定如何試行。

延伸閱讀

企業管理者延伸閱讀：AI 治理是什麼？企業從風險分級到落地的完整指南。這篇文章進一步整理 AI Agent 的授權、人工覆核與可追溯責任，適合搭配本篇建立內部審查制度。

主要參考資料

1. AWS News Blog，〈AWS Continuum for code vulnerabilities is now generally available〉，2026 年 10 月 22 日。https://aws.amazon.com/blogs/aws/aws-continuum-for-code-vulnerabilities-is-now-generally-available/
2. AWS，〈AWS Continuum for code vulnerabilities is now generally available〉，2026 年 10 月 22 日。https://aws.amazon.com/about-aws/whats-new/2026/10/aws-continuum-for-code-vulnerabilities-is-now-generally-available/
3. AWS，〈AWS Continuum Features〉。https://aws.amazon.com/continuum/features/
4. AWS，〈AWS Continuum Pricing〉。https://aws.amazon.com/continuum/pricing/
5. AWS Documentation，〈What is AWS Continuum?〉。https://docs.aws.amazon.com/continuum/latest/userguide/what-is-continuum.html
6. DevOps.com，Mike Vizard，〈AWS Delivers AI Service to Discover Vulnerabilities and Generate Patches〉，2026 年 10 月 27 日。https://devops.com/aws-delivers-ai-service-to-discover-vulnerabilities-and-generate-patches
7. AWS Documentation，〈AWS Continuum for Code Vulnerabilities API Reference〉。https://docs.aws.amazon.com/continuum/latest/APIReference/Welcome.html

資料查核截至 2026 年 11 月 2 日。本文將廠商公告、獨立報導與企業治理建議分別呈現；具體部署、價格及服務區域仍應以實際採用時的最新官方文件為準。