自4月7日發布以來，Anthropic公司的Claude Mythos預覽版一直是安全領域討論的焦點。早期通報指出，這是一款功能強大的網路安全人工智慧系統，能夠大規模識別漏洞，並引發了人們對企業如何快速驗證、確定優先順序和修復漏洞的嚴肅思考。
隨後的辯論主要集中在一些關鍵問題：這究竟是一次變革還是漸進式進步？限制對微軟、蘋果、AWS 和摩根大通的存取真的能降低風險，還是只是讓那些原本防禦能力就很強的公司更加集中防禦優勢？當對手──國家行為體、犯罪集團──也建立起類似的能力時，又會發生什麼事？
從發現到補救的差距
Mythos 的發布以及由此引發的更廣泛的 AI 安全討論，其核心在於更快地發現漏洞。這固然重要，但發現漏洞和修復漏洞是兩個截然不同的工作流程，而這兩者之間的鴻溝正是大多數安全程式悄悄失效的地方， PlexTrac的誕生正是為了彌合這一鴻溝。
試想一下，滲透測試或漏洞掃描發現關鍵問題後，通常會發生什麼：資訊會被記錄在電子表格、工單或PDF報告中，最終發送到某人的郵箱。安全團隊知道這件事，而工程團隊可能知道，也可能不知道，修復責任歸屬不明。沒有清晰的方法來追蹤補丁是否真的發布了，是否被降低了優先級，或者是否安排了重新測試。
像 Mythos 這樣的 AI 模型將大大加快這項流程的輸入端。它們能夠以人類紅隊無法企及的速度和深度發現漏洞。但是，如果用於分類、優先排序、溝通和驗證修復方案的組織架構沒有跟上步伐，那麼更快的發現速度只會導致未解決的關鍵問題積壓數量更快地增長。
而像 Mythos 這樣的模型實際上會加劇這個問題。如果你的滲透測試流程需要三週時間才能發現十個高風險漏洞，而且修復工作已經難以跟上，那麼當同樣的區域被持續掃描，並以十倍的速度產生漏洞時，會發生什麼事呢？
施奈爾的誤報問題確實存在
Bruce Schneier 在他的文章中提出了一個尖銳的問題：我們並不清楚 Mythos 在未經過濾的輸出資料上的誤報率。 Anthropic 報告稱，他們展示的檢測結果與人工評估人員的嚴重性判斷有 89% 的一致性——但這只是一個經過篩選的樣本，並非完整運行數據的分佈。能夠偵測到幾乎所有真實漏洞的 AI 系統，也往往會在已修補或修正的程式碼中產生聽起來合理的漏洞。
這在實際操作中至關重要。如果一個工具能夠大規模地產生看似可信度很高的誤報，它並不會減輕安全團隊的負擔，反而會增加他們的負擔。每一個需要分類和排除的假關鍵發現，都會佔用安全工程師處理真正漏洞的時間。只有當人工智慧輔助漏洞發現的結果能夠被高效評估、與實際業務風險進行關聯，並傳遞給合適的人員時，其價值才能真正得以體現。
基礎建設問題的真實面貌是怎麼樣的？
最能適應神話時代快速發現浪潮的團隊，是那些已經具備以下三個條件的團隊：
- 集中式漏洞發現管理。不是簡單的工單系統，也不是簡單地把 JIRA 看板和電子表格拼湊在一起。這是一個專門建構的平台，用於以標準化、可查詢的格式儲存來自多個來源（掃描器輸出、滲透測試報告、紅隊演練）的漏洞發現。如果沒有這個平台，整合 AI 產生的漏洞發現只會增加另一個資料孤島。
- 基於風險情境的優先排序。原始 CVSS 評分只是一個起點，而非最終決策。在與外部網路隔離的內部系統中發現的關鍵問題，與在面向客戶的 API 中發現的相同問題，其風險程度並不相同。如果組織只能根據嚴重性評分進行排序，那麼當 AI 發現大量問題時，他們將不堪重負；而能夠根據資產關鍵性、業務影響和暴露情境進行評分的組織，則可以進行智能化的優先排序。
透過可配置評分實現動態、基於風險的補救措施
閉環修復追蹤，這是大多數專案失敗的關鍵。未經核實已修復的問題，僅僅是一個有名字的風險而已。持續的複測、結構化的修復工作流程以及清晰的責任交接，這些看似不起眼的功能，卻決定著安全項目是會隨著時間推移不斷改進，還是只會積累記錄在案的風險。
PlexTrac是一個滲透測試報告和暴露管理平台，它一直朝著這個方向發展——集中式發現資料、情境風險優先排序和結構化補救工作流程。Mythos（以及類似的工具）能夠非常有效地偵測出房屋的結構問題。 PlexTrac 則負責營運層面，確保這些問題得到實際解決，指派合適的承包商，並在工程竣工前進行驗收，兩者都不可或缺。大多數機構投入資金進行更完善的房屋檢查，卻仍將維修追蹤系統放在共享的 Google 文件中。
施奈爾指出的存取問題也是一個工作流程問題
對「玻璃之翼計畫」（Project Glasswing）的一項批評是，將Mythos的存取權限集中在50家大型供應商手中，意味著那些最有能力根據調查結果採取行動的組織會率先獲得存取權限。正如前國家網路安全總監在《財富》雜誌上發表的文章中所指出的，財富500強企業更有能力吸收和補救；而中小企業、區域基礎設施運營商和專業工業系統則面臨最大的風險，且資源最為匱乏。
這是一個結構性的存取控制問題，需要透過政策來解決。但其中也包含工作流程問題：即使存取權限實現了民主化，許多小型組織也缺乏將人工智慧產生的安全發現轉化為可執行的修復措施所需的營運基礎設施。對於這些小型組織而言，能夠降低流程開銷的工具——例如更快的報告速度、更清晰的發現溝通以及更順暢的修復交接——其重要性或許遠高於那些已經能夠投入大量人力解決問題的大型企業。
實際應用重點
「神話時刻」是一個有用的強制機制。這並非意味著你的系統明天一定會被攻破，而是因為它揭示了一個多年來悄然擴大的差距：安全團隊發現問題的能力越來越強，而修復這些問題的組織機制卻發展得慢得多。
正確的應對方式不是驚慌失措，也不是坐等 Glasswing 的存取權限最終是否會擴展到你。而是將 Mythos 的公告視為一個契機，審視你自身的修復流程：從發現關鍵問題到最終確認修復需要多長時間？目前有多少未解決的高風險問題處於某種模糊的「正在處理」狀態？修復後你真的能重新測試嗎？還是僅僅相信工程工單已經關閉？
這些問題的答案並不需要存取 Mythos 系統。而且對大多數團隊來說，答案會比 Anthropic 那份長達 245 頁的技術文件中的任何內容都更令人不安。
資料來源：https://thehackernews.com/2026/04/mythos-changed-math-on-vulnerability.html