在 AWS 控制台中，一個漏洞的修復狀態已經顯示為「交付給 GitHub」，代碼庫中也出現了一項修改四個文件的拉取請求。但這個漏洞還不能被認為已經修好。10月22日正式可用的 AWS Continuum、for、code、vulnerabilities，將查找、驗證和生成補丁的流程連在一起，卻將最後的審核與合併工作留給了團隊。這個停頓，正是理解這款 AI 安全服務的關鍵所在。

官方演示中的補丁增加了50行代碼，刪除了24行代碼，這些變更涉及購物車服務。審核者看到的不僅是一段修改建議，還包括攻擊者是否能夠接觸該服務、是否需要身份驗證、以及這些變更會影響哪些數據等內容；此外還有對相關源代碼的分析，以幫助進行判斷。這些修復內容會被直接傳送給開發者他們日常工作的環境中，因此安全團隊無需再將控制臺中的結論重新轉換成開發工作單了。

產品所面臨的摩擦也由此變得清晰起來：雖然有許多警報，但並不代表每一條警報都值得立即動用工程師處理。AWS 以一個例子來說明，一個只在開發環境中使用的工具，與接近支付數據庫的服務，單憑通用的嚴重性分數可能無法區分它們的實際處理順序。該服務試圖增加的是業務位置和攻擊路徑，而非再提供一張更長的掃描列表。

同一段代碼，放在不同的環境中會得到不同的優先級。

接入從建立環境開始。團隊可以連接到 GitHub，或使用 Amazon S3 中的代碼作為來源，再選擇掃描頻率。採用 S3 時，儲存桶必須位於啟用服務的同一賬戶和區域內，並通過 IAM 角色授予訪問權限。軟件能讀到什麼，首先取決於組織願意提供什麼。

團隊還可以在代碼運行的 AWS 賬戶和區域中部署采集器，授權環境使用雲資源信息。采集器收集資源及網絡配置，幫助服務判斷漏洞是否能從網絡觸達，以及攻擊者從該位置還能夠達到哪裡。官方稱，它據此構建關聯代碼與環境的上下文圖，識別服務依賴、負責人和所接觸的數據。

這裡有一個會改變初步理解的細節：產品同時保留了原始的發現以及經過驗證、排序後的問題。Findings 標簽顯示的是掃描器提供的基礎資料，而 Issues 標簽所顯示的才是團隊根據優先級處理的結果。減少工作量的方法，是將發現轉變成可解釋的問題，而非讓開發者一條條地接受機器發出的警報。

證據也有層次。演示中的一個問題被標為靜態分析證明，系統對能夠複現的問題則在隔離沙箱中運行利用過程，並附上概念驗證代碼和複現步驟。不能將「每條都有證據」擴寫為「每條都已在真實生產環境中成功攻擊」。證據層次本身，正是審核者決定信任程度所需的資訊。

補丁完成，責任才進入開發流程

修復方法可以は、コードパッチの適用、依存関係のアップグレード、または設定の調整などです。リクエストを送信する際には、リスク分析、修復の概要、およびその根拠を添付します。これにより、コードのレビュアーは GitHub から離れることなく、なぜ修正が必要なのかを理解することができます。また、システムは既存の防御策が検証済みのパスを防ぐことができるかどうかも評価し、パッチが運用環境から切り離されて単独で機能することがないようにします。

但正式發布說明給出了明確的時間邊界：目前每一項修復都從人類批准開始；讓系統在指定的範圍內自動執行某些修復，屬於未來的能力。不能以之前預覽階段更寬泛的自動化願景，來替代這次正式可用產品的權限說明。

對於企業採購者而言，這將會改變試用時所面臨的問題。與僅比較模型發現了多少漏洞相比，更為有用的做法是檢查環境信息是否充足、證據是否可以重現、補丁的影響範圍是否明確，以及審核人員是否具備承擔合併決定的條件。這些判斷來自於官方展示的流程；公告中並未提供可獨立驗證的客戶平均修復時間或誤報下降幅度。

可用區域目前為美國東部的北維吉尼亞和美國西部的奧瑞岡。掃描記錄、來源設定、收集器以及是否生成修復補丁，都可以在環境中進行管理。組織可以調整頻率和輸入，不必將所有代碼與基礎設施一次性接入。

從控制台到拉取請求，Continuum 增加了一項由機器完成的證據整理與修復交付環節。開發團隊接手的起點變得更加明確：攻擊路徑、業務影響以及待選的修改內容一併提供給他們。上線權仍由負責審查代碼的人員掌握，自動生成補丁的速度並未因這一組織決定而受到影響。