2026 年 4 月，Anthropic 因其新 AI 模型 Mythos 在尋找原始碼安全漏洞方面表現出人意料地出色而引起廣泛關注。據稱，Mythos 在此方面的能力如此之強，以至於 Anthropic 暫未向公眾發布該模型，而是先將其提供給少數選定的公司，讓他們能搶先一步修復最緊迫的問題，然後再向大眾開放。

這件事在全球引起了軒然大波，人們紛紛猜測這是否意味著世界的末日。無疑，這是一次極其成功的行銷策略。

作為 Glasswing 專案的一部分，Anthropic 也透過 Linux Foundation 向「開源專案」提供了其最新 AI 模型的使用權。Linux Foundation 指派其專案 Alpha Omega 負責此事，我因此收到了他們的聯繫。作為 curl 的主要開發者，我獲邀使用這個神奇的模型，並欣然接受。我確實想看看它能在 curl 中發現什麼。

我簽署了使用協議，但隨後便沒有下文。數週過去，我被告知由於某個環節出現問題，存取被延遲了。

最終，我被告知可以由另一位擁有該模型存取權的人，利用 Mythos 對 curl 進行掃描和分析，並將報告寄給我。對我而言，這個區別並不重要。反正我也沒有太多時間去探索各種提示詞或進行深入研究。只要能獲得一個初步的掃描和分析報告就已經很棒了，無論是誰做的。我高興地接受了這個提議。

（我特意省略了參與 curl 分析的個人身份，因為這不是這篇部落格文章的重點。）

在此次 Mythos 報告之前，我們已經使用過多種非常強大的 AI 工具對 curl 進行掃描（當然，我們一直以來都在運行各種「傳統」的靜態程式碼分析器，使用最嚴格的編譯器選項，並進行了多年的模糊測試等）。主要是 AISLE、Zeropath 和 OpenAI 的 Codex Security 被用於透過 AI 仔細審查程式碼。這些工具及其分析在過去 8-10 個月裡，促成了 curl 中大約兩三百個錯誤修復的合併。這些 AI 工具報告的許多發現都被證實為漏洞，並已發布為 CVE。數量可能超過十幾個。

如今，我們也使用 GitHub 的 Copilot 和 Augment 等工具來審查拉取請求（pull requests），它們的評論和建議有助於我們提交更好的程式碼並避免合併新的錯誤。當然，我們仍然會合併錯誤，但 PR 審查機器人會定期指出我們需要修復的問題：沒有它們，我們的程式碼合併會更糟。AI 審查是輔助人類審查的，它們提供幫助，但不能取代我們。

我們也看到大量高品質的安全報告湧入：安全研究人員現在廣泛且有效地利用 AI。

安全性是 curl 專案的首要任務。我們遵循所有準則，並嚴謹地進行軟體工程，以減少程式碼中的缺陷數量。掃描缺陷只是確保系統安全的多個步驟之一。要找到另一個在軟體安全性方面能與 curl 相提並論或做得更多的軟體專案，需要花費大量時間和精力。

我們滿懷期待地收到了 Mythos 生成的第一份原始碼分析報告。這是我們又一次尋找改進領域和修復錯誤的機會，以打造一個更優秀的 curl。

這次初步掃描是在 curl 的 git 儲存庫及其某個近期提交的 master 分支上進行的。它分析了 src/ 和 lib/ 子目錄中 178K 行程式碼。

分析詳細說明了它執行的搜尋方法和策略，以及它如何專注於尋找各種缺陷。報告頂部有一句有趣的說明：

curl 是現存被模糊測試和審計最嚴格的 C 程式碼庫之一（OSS-Fuzz、Coverity、CodeQL、多次付費審計）。在熱門路徑（HTTP/1、TLS、URL 解析核心）中發現問題的可能性很小。

…而且它確實沒有在這些區域發現任何問題。

目前，排除空行後，curl 共有 176,000 行 C 程式碼。原始碼包含 660,000 個單詞，比小說《戰爭與和平》的英文全本多 12%。

平均而言，curl 的每一行生產程式碼都經過了 4.14 次編寫（然後重寫）。我們對此進行了精雕細琢。

目前，git master 中現存的生產程式碼由 573 位獨立開發者編寫。總計，已有 1,465 位開發者將其建議的變更合併到 curl 的 git 儲存庫中。

截至目前，我們已為 curl 發布了 188 個 CVE。

curl 已安裝在超過二十億個實例中。它運行在超過 110 種作業系統和 28 種 CPU 架構上。它運行在地球上每一部智慧型手機、平板電腦、汽車、電視、遊戲機和伺服器中。

報告結論是發現了五個「已確認的安全漏洞」。我認為使用「已確認」這個詞有點好笑，因為 AI 是自信地自行聲稱的。是的，AI 認為它們已確認，但 curl 安全團隊的看法略有不同。

五個問題感覺很少，因為我們預期會有一長串列表。當我和我的 curl 安全團隊成員研究了這個簡短列表數小時並深入了解細節後，我們將列表縮減，最終只剩下一個已確認的漏洞。其他四個問題中，有三個是誤報（它們指出了 API 文件中已記錄的缺陷），第四個我們認為是「僅僅是一個錯誤」。

這個單一已確認的漏洞將被歸類為低嚴重性 CVE，計劃與我們即將發布的 curl 8.21.0 版本同步在六月下旬發布。這個缺陷不會讓人驚訝得喘不過氣來。當然，在發布之前，所有關於該漏洞的細節都不會公開，所以您需要耐心等待。

Mythos 對 curl 的報告還包含了一些它認為不是漏洞的已發現錯誤，這與任何新的程式碼分析器在對數十萬行程式碼進行掃描時的情況類似。報告中的所有錯誤都在調查中，我們正在逐一修復我們認可的那些。

總體而言，大約有二十個錯誤被描述和解釋得相當好。幾乎沒有誤報，所以我推測它們對確定性的門檻設定得相當高。

得益於這份報告，curl 的品質無疑得到了提升，但從發現問題的數量來看，我們之前使用的所有 AI 工具都帶來了更多的錯誤修復。當然，這是自然的，因為我們最初使用的工具發現了更多、更容易發現的錯誤。隨著我們一路修復問題，發現新的問題變得越來越難。此外，錯誤有大小之分，所以不能總是公平地只比較數字。

然而，我的個人結論只能是，到目前為止，圍繞這個模型的巨大炒作主要是行銷。我沒有證據表明這個設置能比 Mythos 之前的其他工具以任何特別更高或更先進的程度發現問題。也許這個模型稍微好一些，但即使是這樣，其改進的程度也遠不足以對程式碼分析產生顯著影響。

這只是一個原始碼儲存庫，也許它在其他方面表現更好。我只能評論和說明它在這裡發現的內容。

但請允許我強調並重申我之前說過的話：與過去任何傳統程式碼分析器相比，AI 驅動的程式碼分析器在尋找原始碼中的安全漏洞和錯誤方面顯著更有效。所有現代 AI 模型現在都擅長此道。任何有時間和實驗精神的人現在都可以找到安全問題。高品質的混亂是真實存在的。

任何沒有使用 AI 工具掃描過其原始碼的專案，很可能會發現這一代工具能找出大量的缺陷、錯誤和潛在漏洞。Mythos 會做到，許多其他工具也會。

不使用 AI 程式碼分析器意味著您將為敵人和攻擊者提供時間和機會，去發現並利用您未能找到的缺陷。

未發現零記憶體安全漏洞。

方法論說明：本次審查是手動驅動的分析，使用 LLM 子代理進行並行檔案讀取，在主會話中透過直接原始碼檢查重新驗證每個候選發現，然後再進行記錄。CVE 與變體搜尋的對應關係是基於 curl 自帶的 vuln.json 建構的。未使用自動化 SAST 工具。

這一結果與 curl 作為最受模糊測試和審計最嚴格的 C 程式碼庫之一的地位一致。防禦性基礎設施（到處都有的受限 dynbufs、帶有每個數值解析顯式最大值的 curlx_str_number、curlx_memdup0 溢位防護、CURL_PRINTF 格式字串強制執行、每個協定的響應大小上限、pingpong 64KB 行上限）系統性地封堵了該大小程式碼庫中通常會產生問題的錯誤類別。

覆蓋範圍現已包括：所有次要協定、所有檔案解析器、所有 TLS 後端的驗證路徑、http/1/2/3、ftp 完全深度、mprintf、x509asn1、doh、所有身份驗證機制、內容編碼、連線重用、會話快取、CLI 工具、特定平台程式碼以及 CI/建構供應鏈。

應該指出的是，AI 工具發現的是我們已經知道的常見和既有類型的錯誤。它們只是發現了新的實例。

到目前為止，我們還沒有看到任何 AI 報告過新穎或完全不同的漏洞。它們不會以這種方式重新發明該領域，但它們確實比以往任何工具都挖掘出更多問題。

這絕對不是最後要發現或報告的錯誤。就在我撰寫這篇部落格文章草稿的同時，我們又收到了安全研究人員關於疑似問題的更多報告。AI 工具將進一步改進，研究人員可以找到新的、不同的方法來提示現有的 AI，讓它們發現更多。

我們還沒有結束。

我希望我們能繼續讓 Mythos 和其他 AI 對 curl 進行更多掃描，一遍又一遍，直到它們真正停止發現新問題為止。

感謝 Anthropic 和 Alpha Omega 提供模型、工具並為我們進行掃描。也感謝進行掃描的個人。非常感激！

感謝搭乘 curl 航班。旅途從不枯燥。

這是我們收到的完整報告。

這是一篇有趣的閱讀，感謝 Daniel 的撰寫。

「它「知道」curl 實現的協定細節，並能質疑程式碼中似乎違反或與協定規格「不符」的細節。」這句話有一個小錯字，我猜應該是「不符」（contradict）而不是「合約」（contract）。

我認為 nghttp2、ngtcp2 和 nghttp3 會是不錯的下一個目標。這三者似乎都由一人維護，並且都被 libcurl 使用。我懷疑它們沒有得到與 curl 同樣多的關注。

其他相關函式庫包括 OpenSSL、c-ares 和 libidn2。

curl 被「高品質報告垃圾郵件」淹沒真是太瘋狂了。

確實如此！這感覺是第一次對 Mythos 及其真實能力進行誠實的評估。

寫得太好了。我不擔心 Mythos，我擔心明年的情況！新的奇特安全發現，看到超級智慧能找到什麼將會非常酷。

我還記得你被低品質的 AI 輔助漏洞垃圾郵件淹沒的日子。那些日子似乎很絕望！我們是否已經走出了那段絕望的隧道？

非常有用的報告，感謝分享，Daniel！

感覺這是一次對所有 FUD 的良好現實檢驗，並且充分證明了良好的衛生習慣和安全的開發實踐的重要性。

我很想知道，你能分享找到這五個「已確認」漏洞所花費的 token 成本嗎？與 Codex Security 相比如何？

@Karl：感謝友善捐助者的慷慨，我們獲得了這一切。我不知道具體的支出，也不知道實際成本。

感謝這篇富有見地的文章，Daniel。執行掃描和分析的團隊是否有關於 token 使用量的粗略估計？我在我的圈子裡聽說了不同的說法。

@Jakob：沒有，我也沒問，說實話也不關心。這次存取和所有需要的 token 都是作為禮物提供的。

你有沒有選項在舊的程式碼庫上運行，看看它會發現什麼，以便與你使用其他 AI 問題檢查器時進行比較？

@Tom：我會把這類比較留給別人。我主要關心的是改進 curl。

Daniel–為你運行掃描的個人，他們只是進行靜態程式碼分析還是動態模糊測試？沒有發現任何關鍵漏洞非常能說明 curl 的情況，儘管這可能是一個例外。

我認為僅憑對 curl 的安全掃描來評判 Mythos 的能力可能不完全公平。儘管如此，它確實發現了一些可以修復的東西，這很好。也許 Anthropic/Mythos 只是炒作或行銷——我個人不這麼認為，至少從其他報告來看是這樣。我更傾向於認為（再次強調，這只是我個人的觀點）curl 是少數幾個真正能體現深度專業知識、奉獻精神和長期承諾的開源專案之一。

隨意將 Daniel（curl）與 Linus（Linux）進行比較。

聽起來 Mythos 只被提示一次對 curl 運行掃描和分析，然後生成報告？如果是這樣，Mythos 是否可能透過更多或更好的提示找到更多漏洞？

天真地說，我的一個假設是，其他工具可能比 Mythos 使用得更好和/或更多次（如果 Mythos 確實只被提示一次進行掃描並生成報告），這可能是 Mythos 發現的錯誤比其他工具少的原因：

> 從發現問題的數量來看，我們之前使用的所有 AI 工具都帶來了更多的錯誤修復

深入了解執行 Mythos 掃描和生成此報告的個人所做的工作，以及這是否接近 Mythos 的窮盡使用以改進 curl，將會很有幫助。

> 五個問題感覺很少，因為我們預期會有一長串列表。

假設：你的預期並沒有錯；Mythos 工具只是沒有像潛在的那樣被有效或窮盡地使用。對這個假設有何看法？

正如文章所述，一位與 Linux Foundation 有關的人員進行了分析。在沒有進一步了解的情況下，我會假設：首先，這個人很可能也是一位受過良好教育的軟體開發者或安全研究員。其次，這個人可能已經為多個 FOSS 專案做過此事，至少比 Stenberg 多（他也只對 curl 使用過一次，這也是一個假設）。

雖然「curl 是現存被模糊測試和審計最嚴格的 C 程式碼庫之一」聽起來像是報告開頭的藉口，但 curl 無疑是現存被模糊測試和審計最嚴格的程式碼庫之一，你不會期望在那裡發現很多錯誤。

我們在使用基於 AI 的工具在 haproxy 中發現了一些錯誤和幾個漏洞，這很棒，但說實話，在閱讀這篇文章時，我對 Mythos 僅僅是行銷炒作的疑慮越來越大。好吧，它可能比其他模型更強大，但我認為如果沒有先在本地運行其他模型來捕捉所有更明顯的鬆懈，運行如此龐大的東西就沒有意義了。只有當你習慣了只看到誤報或低重要性的東西時，才可能嘗試像 Mythos 這樣的大型模型，看看它們是否能發現不同的東西。

這是一篇很棒的文章，謝謝 Daniel。

很棒的內容 Daniel – 感謝分享。你和其他在這裡的人可能會對我上週發表的關於「Mythos 效應」的文章感興趣：https://mathiasprzybylowicz.substack.com/p/claude-mythos-software-security 文章本身是一個執行摘要，還有一個 57 頁（是的，我知道，這太瘋狂了 :D）的可下載專著，可能會補充你的觀點。

你能再試試 GPT 5.5 Cyber 嗎？

https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities

令人失望的是，資金雄厚的 AlphaOmega 組織首先承諾向開源開發者提供存取權，然後又反悔。

我們不知道 Anthropic 是否會發出指令，只在發現問題時才聯繫專案，以避免 Mythos 在特定專案中一無所獲的情況。這可能是禁運的原因之一。

如果 AlphaOmega 收到的資金中只有一小部分用於開源作者，那麼也許就不需要外部審計了。

令我不安的是，Anthropic/AlphaOmega 在發現少量問題時獲得了所有的榮耀、金錢和宣傳，而真正的開源作者卻幾乎一無所獲。

如果 curl 作者發現並悄悄修復了問題，就不會有紐約時報的文章。

總體而言，這是一篇很棒的文章，在這篇文章的許多評論中，對我來說最重要的一點是：

「應該指出的是，AI 工具發現的是我們已經知道的常見和既有類型的錯誤。它們只是發現了新的實例。」

出於好奇，你認為這是因為生成式 AI 的依賴性/流行度，以至於我們在達到下一個創意 AI 階段之前不會看到新穎的錯誤/漏洞/等等，還是僅僅因為這個領域和基礎還很新？

很棒的閱讀！謝謝。用 AI 掃描傳奇開源專案不是個壞主意。但他們的意圖讓我質疑：如果你發現了什麼，就創建一個問題，不要用它來做虛假的行銷材料。

很棒的文章，感謝你的坦誠。

從數據科學的角度來看，我想知道 Anthropic 的較小語言模型（Sonnet）是否存在某種提示，能夠發現相同的漏洞。

Mythos 掃描了整個儲存庫並發現了錯誤；這是其關鍵的行銷賣點。其他 AI 呢？它們能做到同樣的事情並重現錯誤嗎？

本週最棒的閱讀。真正值得關注的是 AI 以人類團隊無法審計的規模編寫有缺陷的程式碼。

關於 Mythos AI 模型，這是一個有趣的觀點。 AI 能在尋找安全漏洞方面做得太好，這真是令人難以置信。行銷角度也說得通。

有趣的寫作。我喜歡這裡的平衡觀點：AI 程式碼分析器顯然很有用，但炒作仍需與實際發現進行權衡。

用 Go 重寫 Curl，你就再也不需要 AI 了。使用 Go Linter。