摘要： Cloudflare 於 2026 年 9 月 3 日發布 Vulnerability Discovery and Remediation 早期存取服務，隸屬 Managed Defense 並採邀請制。服務以 OpenAI Daybreak 模型進行偵察、狩獵與驗證，並結合路由流量、安全事件與 WAF 狀態來排定優先順序。系統只提出修補或 WAF 規則建議，最終是否部署仍由客戶決定。
掃描工具丟出 4,000 個新漏洞，其中 78 個屬嚴重等級，你會從哪一個開始修？傳統掃描器能指出問題發生在什麼位置，卻沒辦法說明這個問題是否真的落在攻擊面上。Cloudflare 在 2026 年 9 月 3 日發布的 Vulnerability Discovery and Remediation（漏洞發現與修復）早期存取服務，就是要拿自家的網路流量資料，把這道缺口補起來。
這項服務隸屬 Cloudflare Managed Defense，採邀請制。它把 OpenAI Daybreak 模型（包含 GPT-5.6 Cyber）用在偵察、狩獵與驗證上；不過它的著眼點並非「挖出更多漏洞」，而是「協助你判斷哪個漏洞該優先處理」。
為什麼脈絡比數量更重要
大型語言模型只要幾分鐘就能掃過整個程式碼庫，挑出裡面的潛在弱點，發現的數量因此不斷往上堆。真正的壓力其實來自速度：攻擊者同樣能用 AI 加快漏洞發現與利用，安全團隊和開發者被迫在更短的時間內判斷什麼重要、接下來該怎麼行動。
掃描結果往往缺少生產環境的佐證。舉例來說，掃描器會指出某個 handler 帶有漏洞，卻不會說明那段程式碼是否已經部署、是否有任何人真的存取那條路由、周圍出現過哪些安全活動、以及你手上已經有哪些防護。少了這些脈絡，排優先順序只能憑感覺。
Cloudflare 的優勢在於它握有全球網路，能看清哪些路由是活的、各自承載多少流量、又連帶出現哪些安全事件。客戶啟用這項服務並搭配 Web Application Firewall（WAF）之後，系統還能得知哪些規則已經生效、正在攔下哪些攻擊。如此一來，原本空泛的一筆發現就變成明確的優先事項：漏洞位於已上線的程式碼、坐落在流量高的路由、近期有攻擊活動、而且目前毫無防護。
從內部工具到客戶服務
這套服務並不是無中生有。Cloudflare 先前在「Build your own vulnerability harness」一文中，說明過他們掃描自家艦隊所用的模型無關管線：每一筆發現都經過對抗性驗證，模型的原始輸出則被轉換成工程師敢信任的修補。那個內部系統如今成為這項服務的支柱之一。
實際流程分成幾個階段。開頭先從 Web Assets 與 WAF 取得流量與安全資料快照，藉此看出哪些路由活躍、流量多寡、近期有無安全事件。接著對原始碼做弱點分析，但分析本身不會指出哪些路由會碰到它。Cloudflare 把高流量的路由稱為「熱路徑」，落在這些路由上的原始碼會受到更嚴格的安全剖析。
以 Workers 為例，系統會先取得最新版本的 Worker 原始碼與其設定的路由，再透過 Workers Observability 將路由與請求中繼資料對照起來，讓正在審查的原始碼與它在生產環境所處理的端點連上線。這份網路脈絡在整段調查期間都保持在手邊，供代理程式隨時取用。
狩獵、驗證與防護建議
調查展開時，Reconnaissance（偵察）代理程式負責把請求路徑對應到處理它們的程式碼區段；接著 Hunter（狩獵）代理程式被派進客戶授權的特定程式碼區段尋找漏洞，需要時再拉進相關的網路脈絡。然而脈絡本身不足以證明漏洞存在——每一筆發現都必須有原始碼中的證據撐著。
Hunter 回報之後，驗證階段會審視建議的緩解措施，並依原始碼給出初步風險評級。若網路證據顯示受影響的端點流量可觀，或出現主動探測的跡象，評級就能往上調。
最後交付的是一份排序清單，每一筆發現都附上建議的程式碼修補；當證據足以支持時，再附一條 Cloudflare WAF Custom rule，讓程式碼修補進入審查的期間風險得以降低。這條規則會保守地鎖定在能觸及漏洞程式碼的方法、路徑與其他請求細節。若路由模式只由變數與萬用字元組成，系統就不會建議規則——它寧可漏掉可能的關聯，也不願宣稱證據撐不起來的東西。
模型在哪裡執行，界線在哪裡
一旦你授權調查，Vulnerability Discovery and Remediation 會在 Cloudflare 上執行 harness，並經由 Cloudflare AI Gateway 把模型提示送往 OpenAI 伺服器上的 Daybreak 模型。偵察、狩獵與驗證由 GPT-5.6 Cyber 負責，回應回到 harness 後工作流程繼續往下走。模型推論不在 Cloudflare 邊緣執行，模型也沒有能力自行套用任何修補或規則。
每次調查都被限制在客戶授權的原始碼與證據範圍內。在脈絡送往模型之前，系統會剔除調查不需要的部分，並套用針對該參與設定的編輯控制。對 harness 來說，原始碼、日誌與請求中繼資料是「要檢查的證據」，而不是「要遵循的指令」。
工具存取同樣守著這條界線：每一次呼叫都會留下紀錄，並在執行前比對調查的存取政策。任何修補或規則提案都必須通過在模型之外實作的檢查；檢查一旦失敗，工作流程會在提案送到客戶審查之前停下。
早期存取與實際限制
這項服務目前只開放受邀客戶，需透過 Managed Defense 團隊參與。每次參與都從一個應用程式起頭，由客戶授權 Cloudflare 調查其程式碼庫。系統以授權的讀取權限存取 Web Assets 操作清單、相關 WAF 控制，以及 Workers Trace Events Logpush（若可用）。調查屬於半自動化——每一項結果都要經你審查，才決定是否測試或部署變更。
有一點值得留意：這套服務的價值與 Cloudflare 的網路能見度綁得很緊。應用程式若不在 Cloudflare 代理範圍內，或沒有啟用 WAF，脈絡就會稀薄許多。另外，模型只能在授權範圍內活動，無法自行決定修補——最終決策權依然握在工程師手中。
若你有興趣，可以聯繫你的 Cloudflare 客戶團隊。不過在那之前，不妨先問自己：掃描工具回報的漏洞清單裡，究竟有多少是真正暴露在生產環境的？