一句話總結

我該專注於寫書，還是去追逐漏洞獎勵？

重點整理

• 我在專注寫書與投入資安漏洞獎勵之間陷入兩難。
• 我正在考慮開設一門課程，分享我運用 AI 尋找資安漏洞的所學。

目標成績

每個月月初，我會宣告想完成的事。以下是本月目標的達成情況：

完成《重構英文》撰寫

• 結果：還有大約 1 到 2 週的寫作要完成
• 評分：C

我總覺得快要完成了，卻又在漏洞獎勵上花了比預期更多的時間。

《重構英文》數據指標

由於自 3 月以來都沒有做任何行銷，本書的收入下滑了。相反地，我一直被漏洞獎勵狩獵分心。雖然靠著過去的努力還能勉強支撐，但我看得出來，如果繼續忽略行銷，數字會一路往零邁進。

三個月的漏洞獎勵計畫

過去三個月，我花了很多時間運用 AI 尋找資安漏洞。我一直沒有公開談論這件事，因為我不想為數量有限的漏洞獎勵計畫引來競爭。我不確定其他人是否已經意識到 AI 在資安研究上有多有效，但我想這個祕密已經藏不住了。

如果你沒有持續關注 AI 與資安研究的進展，Firefox 就是一個驚人的案例。在 2025 年一整年（當時 AI 在資安研究上還派不上用場），Mozilla 與外部研究人員每個月總共在 Firefox 中找到 10 至 20 個資安漏洞。

2026 年 2 月，Anthropic 使用 Claude Opus找到了 22 個 Firefox 漏洞。換句話說，僅在那一個月，Anthropic 一家找到的漏洞數量，就超過了以往任何一個月所有其他人加起來的總和。兩個月後，Anthropic 又使用 Claude Mythos 在 Firefox 中找到了高達271 個漏洞。

我算是很早就察覺到這個趨勢，但判斷有一點偏差。早在 1 月，我就認為 AI 或許能徹底改變資安研究，但我以為價值在於打造資安工具。當時我用 AI 撰寫 fuzz testing(模糊測試)工具，對於用它來執行 fuzz testing 的速度比我手動操作快上許多，感到非常驚艷。

儘管我寫 fuzzer 的速度快了 10 到 20 倍，事後證明，我的策略其實遠比必要的工作量更繁重。與其要求 AI 打造一個 fuzz testing 工具再去評估輸出結果，你其實可以直接問 AI：「嘿，看看原始碼，告訴我所有的漏洞。」

在見識到 AI 直接審查原始碼的能力有多強之後，我就不再做 fuzz testing，轉而專注於原始碼審查。到目前為止，我已經向五個不同的漏洞獎勵計畫通報了超過 50 個漏洞，並獲得了約 1 萬美元的獎金。

漏洞愈來愈好找，但獎勵計畫愈來愈難搞

雖然我已經成功運用 AI 找到資安漏洞，但在找到願意為這些發現付費的公司方面，就沒那麼順利了。

以下是目前為止的成果：

• 廠商 1：Meta
  • 我提交了八份報告，其中包含一個遠端程式碼執行漏洞。
  • 好幾週都沒有收到回應。
  • 我找到了曾參與該產品的開發者電子郵件並主動聯繫，他們幫我將報告往上呈報、通過了初步篩選，但之後就沒有任何進展（至今已超過兩週）。
• 廠商 2
  • 我提交了一份報告。
  • 廠商在一個工作天內完成了初步篩選，但表示需要數週時間才能徹底調查。
  • 我已經超過 30 天沒有收到任何消息。
• 廠商 3：
  • 我提交了一份報告。
  • 廠商聲稱這是重複通報，因此沒有獎金。
• 廠商 4
  • 我提交了約 40 份報告。
  • 其中八份在兩週後獲得付款，總計 9,700 美元。
  • 有兩份被以重複為由退件。
  • 其餘的都在等待初步篩選，不過最有價值的幾份都已在最早獲得付款的八份之中。
• 廠商 5：Firedancer（加密專案）
  • 發現了幾個中度嚴重性的問題。
  • 當我開始進行獎勵通報流程時，才發現他們要求研究人員將護照上傳到一個我從未聽過的服務，因此我就此打住。
  • 他們的計畫規則也很可疑，似乎與其所使用之獎勵平台的規則相互矛盾。

因此，來自廠商 4 的 1 萬美元，只花了我兩週的兼職時間。如果不是還在那些毫無報酬的獎勵計畫上多花了 6 週以上的時間，這原本會是很棒的投資報酬。如果能找到更多像廠商 4 這樣的廠商當然很好，但我不知道該怎麼做。

我該專注於寫書，還是漏洞獎勵？

我現在對於該如何在寫書與漏洞獎勵之間分配時間感到猶豫。以下是我的想法：

• 專注於寫書
  • 優點：這本書已經快要完成，所以如果我專心收尾，它會比一本半成品更有價值。
  • 優點：這本書是只有我能創造的東西，而漏洞獎勵則有很多人可以參與。
  • 優點：我交付這本書的時間已經落後，所以完成它能讓我對讓讀者久等這件事少一些愧疚感。
  • 優點：我可以公開談論我的書，這不僅有助於我釐清想法，也能幫助新讀者發現這本書。
  • 缺點：至少在短期內，這本書的預期價值感覺比追逐漏洞獎勵還低。理論上，我下週就可能找到一個價值 10 萬美元的漏洞，而下週要靠任何方法創造 10 萬美元的圖書銷售額則不太可能。
• 專注於漏洞獎勵
  • 優點：我在兩週內靠漏洞獎勵賺到的錢，比 2025 年一整年靠這本書賺到的還多。
  • 優點：仍有大量尚未被發現、且可用 AI 工具找到的付費漏洞。
  • 優點：如果我暫停幾個月，剩下漏洞的價值將會大幅降低，因為許多其他研究人員會已經搶走了那些容易找到的漏洞。
  • 缺點：參與漏洞獎勵令人沮喪，因為你沒有任何籌碼。廠商可以完全壓低價格或賴帳，而你除非把漏洞賣給想用於不法用途的買家，否則沒有任何追索或談判的空間。
  • 缺點：漏洞獎勵狩獵就像賭博一樣令人上癮，因為存在著不定期出現的變動獎勵。
  • 缺點：漏洞獎勵讓我重回不良的 AI 使用習慣。如果我在背景讓 AI 代理程式搜尋漏洞，我就會一直想查看它的進度，並根據早期結果不斷調整方向。
  • 缺點：我在公開分享工作成果方面受到更多限制，一方面是因為獎勵計畫通常有所要求，另一方面也是因為我不想為自己正在投入的地方引來競爭。

理性上，我很難為自己為何還要繼續追逐漏洞獎勵找到正當理由，但我還是想稍微持續下去，或許以 70/30 的比例在寫書與漏洞獎勵之間分配時間。

或許我該教大家如何用 AI 提升軟體安全性

第三種可能性是，與其追逐漏洞獎勵，不如把我過去幾個月學到關於運用 AI 尋找資安漏洞的知識教給大家。

我正在考慮開設一門小型的 cohort-based(同梯共學制)課程，一起在開源專案中尋找漏洞。我們會挑選沒有附帶漏洞獎勵的專案，讓學員可以在內部分享發現，而不必擔心有人搶走獎勵。課程形式將是現場或預錄的螢幕錄影加上 2 到 4 週的私人社群群組的某種組合。

這門課的重點不會是如何透過漏洞獎勵賺錢。或許我會稍微提到，但那不會是主軸，因為那不是我過去三個月學到最多的部分。

這門課將聚焦於如何運用 AI 在大型程式碼庫中找出資安漏洞。我會展示我學到的技巧，教你如何讓 AI 工具聚焦於最可能出現漏洞的區域，避免在錯誤的線索上浪費時間與 token。你可以將這些經驗應用在自家的封閉原始碼上，或是你想協助鞏固的開源專案上。

如果你有興趣，請在下方登記加入意願名單：

• 意願登記 - 運用 AI 尋找資安漏洞

推薦

Timelinize 讓你從社群媒體取回自己的資料

幾週前，我在 Reddit 上看到有人提問，想刪除自己的 Facebook 帳號，但又想以可用的格式保存資料備份。這讓我想起曾在 Hacker News 上看過、但從未深入研究過的一個專案，叫做 Timelinize。

Timelinize 讓你匯入從 Facebook、Google、Twitter 等服務匯出的資料，並建立一個統一的時間軸來瀏覽你的資料。創作者是 Matt Holt（麥特・霍特），他同時也是熱門反向網頁代理伺服器 Caddy 的作者。

Timelinize 目前用起來還是相當早期測試階段，我得加上許多本地修補才能正常使用，但我喜歡它的發展方向。隨著我使用得愈多，我計畫將更多修補提交回上游。

每當我為原本需要雲端服務的事物找到本地、離線的解決方案時，總會感到一種莫名的清新感。當我從串流服務轉換到 Jellyfin 時，我很驚訝僅僅是單純地觀看想看的內容，而沒有一家公司在背後盯著我想辦法榨錢，感覺竟是如此不同。

奇怪的是，當我看 Netflix 或 HBO 時，從未有意識地想過：「糟了！我被監視了。」但當我開始完全在本地觀看影視內容時，就好像我在辦公室隔間裡待了太久，以至於忘了外面世界的存在。然後，我走到了戶外，享受新鮮空氣和陽光。我指的是比喻上的意思。實際上，我還是坐在室內用電腦看電視。但速度更快、也自由多了！

我在使用 Timelinize 時也有類似「呼吸到新鮮空氣」的體驗。Timelinize 的介面是以使用者為中心，這讓我意識到雲端平台的介面是多麼不友善。Facebook 和 Twitter 不希望你只是捲動瀏覽舊訊息，因為那無法為他們賺錢。為了阻止你閱讀舊訊息，他們讓體驗變得微妙地不舒服：把對話擠進小小的方框，每隔幾秒就強迫你停下來等待新訊息載入，還不斷顯示分散注意力的通知，把你拉回他們可以變現的新內容上。

而使用 Timelinize 時，閱讀體驗是為了讓我單純地閱讀自己的封存資料。沒有任何東西試圖竊取我的注意力、誘使我去查看最新動態，因為 Timelinize 呈現的是歷史快照。我覺得跳到 10 年前的某個日期、閱讀當時的對話內容很有趣。

React2Shell 的故事與 Next.js 後續發展

我當時沒有關注 React2Shell，但這是一個存在於 React.js 中的重大漏洞，能讓攻擊者在許多 React.js 與 Next.js 應用程式上取得程式碼執行權限。

上週，發現 React2Shell 的兩位研究人員撰文分享了背後的經過：

• 〈The React2Shell Story〉由負責尋找此漏洞的首席研究員 Lachlan Davidson（拉克蘭・戴維森）撰寫。
• 〈The React2Shell Story and What Happened Next.js〉由協助拉克蘭・戴維森探索漏洞、通知廠商並找出願意為此漏洞支付獎勵之漏洞獎勵計畫的 Sylvie Mayer（席薇・梅爾）撰寫。

拉克蘭・戴維森的文章獲得了更多關注，但我覺得席薇・梅爾的文章更有意思，尤其考慮到她當時還是一位 20 歲的大學生。

拉克蘭・戴維森與席薇・梅爾都意識到，他們發現了一顆影響數百甚至數千個主要網站的「核彈」。在向 Meta（React 的維護者）與 Vercel（Next.js 的維護者）通報漏洞後，他們想找出其他願意為這個重大漏洞支付獎勵的漏洞獎勵計畫。

在 Meta 公開發布安全性公告之前，研究人員無法向其他廠商揭露這個漏洞。問題在於，一旦 React2Shell 公開，拉克蘭・戴維森與席薇・梅爾就會在眾人搶著申報同一批獎勵的競爭中失去優勢。

為了搶得先機，席薇・梅爾在漏洞封鎖期間就先行探勘漏洞獎勵計畫，並檢查那些廠商的網站是否容易受到 React2Shell 攻擊。如此一來，一旦 Meta 公布漏洞，席薇・梅爾與拉克蘭・戴維森就能立即申報這些第三方獎勵。

問題在於，在 React2Shell 公開之前，Vercel 就已在其網頁應用程式防火牆（WAF）中為此漏洞建立了過濾規則，即使客戶網站仍在執行有漏洞的 React 或 Next.js 版本，也能受到保護。Meta 與 Vercel 還與 Cloudflare 及類似的 WAF 平台合作，教導它們如何過濾 React2Shell 攻擊。

因此，在 Meta 公布 React2Shell 之後，席薇・梅爾嘗試對她事先探勘過的網站重現漏洞，但漏洞並未觸發。幾乎所有設有漏洞獎勵的網站都使用了 Cloudflare 或 Vercel，因此 WAF 阻擋了席薇・梅爾的攻擊程式。

於是，拉克蘭・戴維森與席薇・梅爾現在必須設法讓他們的攻擊程式繞過 Cloudflare 與 Vercel 的 WAF 來觸發 React2Shell，但要繞過企業級 WAF 本身就是一項龐大的研究計畫。幸運的是，席薇・梅爾在 Cloudflare 的 WAF 中找到了一個繞過方法，並在 Vercel 的 WAF 中找到了五種不同的繞過方式。

有趣的是，席薇・梅爾所獲得的報酬中，「絕大多數」並非來自 React2Shell 本身，而是來自 WAF 繞過，因為 Vercel 為每一個通報的繞過支付了 5 萬美元。

總結

完成了什麼？

• 發表了新章節：〈Improve Your Writing with AI〉與〈Meet the Reader Where They Are〉
• 與讀者舉辦了一場關於運用 AI 改善寫作的線上即時座談
• 透過漏洞獎勵計畫通報了大量資安漏洞

學到的經驗

• 長期而言，專注於寫書比投入資安漏洞獎勵對我更有利。
  • 困難之處在於，漏洞獎勵的回報是短期的，而書籍的回報通常至少會落後我的投入一個月。
• 從雲端服務遷移到本地自架的服務，竟帶來意想不到的滿足感。

下個月的目標

• 讓《重構英文》達到「內容完稿」階段。
• 打造一個讓《重構英文》讀者在閱讀時可提供回饋的工具。

需要協助的地方

如果你有興趣了解如何運用 AI 在團隊的程式碼中尋找資安漏洞，請登記加入我的意願名單。如果有足夠多的人感興趣，我就會開設這門課程。

• 意願登記 - 運用 AI 尋找資安漏洞