《Refactoring English》:第 17 個月
原文由 Michael Lynch 于 發布,訂閱此部落格
一句話總結
我該專心寫書,還是去追漏洞獎金?
重點整理
- 我在專心寫書和投入資安漏洞獎金之間左右為難。
- 我正在考慮開一門課,分享我用 AI 尋找資安漏洞的心得。
目標評分
每個月月初,我都會宣告想完成的事。以下是這個月的達成狀況:
完成《Refactoring English》寫作
- 結果:還剩下大約 1 到 2 週的寫作進度
- 評分:C
我一直覺得快寫完了,卻總是花比預期更多的時間在漏洞獎金上。
《Refactoring English》數據
| 指標 | 2026 年 3 月 | 2026 年 4 月 | 變化 |
|---|---|---|---|
| 不重複訪客 | 6,932 | 2,578 | -4,354 (-63%) |
| 預購收入 | $725.80 | $587.73 | -$138.07 (-19%) |
這本書的收入下滑了,因為我三月以來就沒再做行銷。反而一直分心去追漏洞獎金。我很慶幸還能靠過去的累積撐著,但如果繼續忽略行銷,數據顯然會一路往零掉。
投入漏洞獎金計畫的三個月
過去三個月,我花了很多時間用 AI 來找資安漏洞。我一直沒有公開談這件事,因為不想把競爭者引來數量有限的漏洞獎金計畫。我本來不確定其他人是否已經意識到 AI 在資安研究上有多厲害,但現在看來秘密已經藏不住了。
如果你沒有持續關注 AI 與資安研究的進展,Firefox 就是一個驚人的案例。整個 2025 年(當時 AI 還不擅長資安研究),Mozilla 和外部研究人員加起來每個月大概在 Firefox 中找到 10 到 20 個資安漏洞。
2026 年 2 月,Anthropic 用 Claude Opus 找到了 22 個 Firefox 漏洞。換句話說,光是那一個月,Anthropic 一家找到的漏洞,就比過去 13 個月中任何一個月所有人加起來還多。兩個月後,Anthropic 又用 Claude Mythos 在 Firefox 中找到了驚人的另外 271 個漏洞。
我算是很早就察覺到這個趨勢,但判斷有點偏差。早在 1 月,我就覺得 AI 可能會徹底改變資安研究,但我以為它的價值在於打造資安工具。我當時用 AI 來寫模糊測試工具,發現做模糊測試的速度比我手動操作時快了非常多,讓我大為驚訝。
雖然我寫模糊測試工具的速度快了 10 到 20 倍,但後來發現這個策略其實做了太多不必要的工作。與其叫 AI 做一個模糊測試工具再去分析結果,你其實可以直接叫 AI「嘿,幫我看一下原始碼,告訴我有哪些漏洞。」
在見識到 AI 直接審查原始碼有多厲害之後,我就不再做模糊測試,轉而專注於原始碼審查。到目前為止,我已經向五個不同的漏洞獎金計畫回報了 50 多個漏洞,賺了大約一萬美元的獎金。
漏洞變得更好找了,但獎金計畫卻變得更難搞
雖然我已經成功用 AI 找到了資安漏洞,但在找到願意為這些發現付錢的公司方面,就沒那麼順利了。
以下是目前的成果:
- 廠商 1:Meta
- 我提交了八份報告,其中包含一個遠端程式碼執行漏洞。
- 好幾個星期都沒有收到回應。
- 我找到了負責該產品的開發者的電子郵件並聯繫他們,他們幫我把報告往上呈報、通過了初步分類,但之後就又沒了動靜(到現在已經兩週了)。
- 廠商 2
- 我提交了一份報告。
- 廠商在一個工作天內完成了分類,但說要徹底調查還需要好幾個星期。
- 到現在已經超過 30 天沒有任何消息。
- 廠商 3:
- 我提交了一份報告。
- 廠商說是重複回報,所以沒有獎金。
- 廠商 4
- 我提交了大約 40 份報告。
- 其中八份在兩週後獲得獎勵,總計 9,700 美元。
- 兩份被以重複為由退件。
- 其餘的都在等待分類,不過最有價值的幾份已經在前八份拿到獎金的報告裡了。
- 廠商 5:Firedancer(加密貨幣專案)
- 發現了幾個中嚴重程度的問題。
- 當我開始回報流程時,發現他們要求研究人員把護照上傳到一個我從沒聽過的服務,所以我就此打住了。
- 他們的計畫規則也很可疑,似乎與他們所使用的獎金平台規則互相矛盾。
所以,來自廠商 4 的一萬美元,其實只花了我兩週兼職的時間。如果不是還在其他完全沒付錢的獎金計畫上多花了六週以上,這報酬率其實非常好。如果能找到更多像廠商 4 這樣的廠商就好了,但我還不知道該怎麼做。
我該專心寫書,還是追漏洞獎金?
我現在很糾結該怎麼在寫書和漏洞獎金之間分配時間。我的想法是這樣的:
- 專心寫書
- 優點:這本書已經快完成了,如果專心把它寫完,就能成為一本完整的書,比半成品更有價值。
- 優點:這本書只有我能寫出來,而漏洞獎金很多人都能參與。
- 優點:我交書已經遲了,把它完成才能減少讓讀者久等的愧疚感。
- 優點:我可以公開談論寫書的過程,這不僅能幫助我釐清思路,也能讓新讀者發現這本書。
- 缺點:至少在短期內,寫書的期望收益感覺比挖漏洞低。理論上,我下週就有可能找到一個價值十萬美元的漏洞,但下週要靠什麼手段衝出十萬美元的書籍銷量,幾乎不可能。
- 專注於漏洞獎金
- 優點:兩週漏洞獎金的收入,就超過我 2025 一整年靠這本書賺到的錢。
- 優點:還有大量尚未被發現、而且有獎金可拿的漏洞,等著用 AI 工具去找出來。
- 優點:如果我暫停幾個月,剩下漏洞的價值會大幅降低,因為其他研究人員會先把好找的漏洞都領走了。
- 缺點:參與漏洞獎金很讓人沮喪,因為你完全沒有籌碼。廠商可以隨意壓價或直接坑你,而你幾乎沒有申訴或議價的空間,除非你把漏洞賣給想拿去做壞事的買家。
- 缺點:追漏洞獎金像賭博一樣會上癮,因為會出現不固定的獎勵,而且是半隨機出現的。
- 缺點:漏洞獎金又把我推回不良的 AI 使用習慣。如果我在背景跑一個找漏洞的 AI 代理人,我就會一直想去查看進度,並根據早期結果不斷調整方向。
- 缺點:我能公開分享的工作內容受到很大限制,一方面是因為獎金計畫通常有保密要求,另一方面也是我不想把競爭者引到我正在努力的地方。
理性上,我很難為自己繼續追漏洞獎金找到正當理由,但我還是想稍微持續下去,也許讓寫書和漏洞獎金的時間比例維持在七比三左右。
也許我該教大家如何用 AI 提升軟體安全性
第三種可能是,與其追逐漏洞獎金,不如把我過去幾個月學到用 AI 找資安漏洞的心得教給大家。
我在考慮開一門小型的梯次制課程,一起在開源專案中找漏洞。我們會挑選沒有附帶漏洞獎金的專案,這樣學員就能在內部分享發現,不用擔心有人搶走獎金。課程形式會是直播或錄影的螢幕示範,加上為期 2 到 4 週的私人社群討論。
這門課的重點不會是靠漏洞獎金賺錢。也許我會稍微提到,但那不會是主軸,因為那不是我過去三個月學習最多的部分。
這門課會聚焦在如何用 AI 在大型程式碼庫中找出資安漏洞。我會分享我學到的技巧,教你如何讓 AI 工具聚焦在最可能有漏洞的地方,避免在錯誤的方向上浪費時間和 token。你可以把這些方法應用在自己團隊的封閉原始碼上,或是用來協助你想貢獻的開源專案提升安全性。
如果你有興趣,請在下方加入意願名單:
推薦
Timelinize 讓你從社群媒體取回自己的資料
幾週前,我在 Reddit 上看到一個提問,有人想刪除 Facebook 帳號,但又想以可用的格式保存一份資料備份。這讓我想起曾在 Hacker News 上看過、但一直沒深入研究的專案 Timelinize。
Timelinize 讓你匯入從 Facebook、Google、Twitter 等服務匯出的資料,並建立一個統一的時間軸來瀏覽這些資料。創作者是 Matt Holt,他同時也是熱門反向代理伺服器 Caddy 的作者。
Timelinize 目前感覺還在很早期的 alpha 階段,我得自己加上不少本地 patch 才能順暢使用,但我很看好它的發展方向。隨著使用更多,我打算把更多 patch 回饋給上游。
每當我找到一個能取代雲端服務的本地、離線解決方案時,總會有一種莫名的清爽感。當我從串流服務轉到 Jellyfin 時,我很驚訝光是單純看自己想看的內容、而沒有一家公司在背後盯著我想辦法從我身上榨錢,感覺就截然不同。
奇怪的是,看 Netflix 或 HBO 的時候,我從來沒有有意識地想過:「天啊!我被監控了。」但當我開始完全在本地看影集和電影時,就好像我在辦公室隔間裡待太久,久到忘了外面還有世界。然後,我走到戶外,享受新鮮空氣和陽光。我是指比喻上的。實際上,我還是坐在室內用電腦看電視。但感覺就是快得多,也自由得多!
用 Timelinize 時,我也有類似「呼吸到新鮮空氣」的體驗。Timelinize 的介面是以使用者為中心的,這讓我意識到雲端平台的介面對使用者是多麼不友善。Facebook 和 Twitter 根本不希望你一直往回翻舊訊息,因為那對他們沒有收益。為了讓你不想去讀舊訊息,他們把體驗設計得微妙地不舒服:把對話擠在小小的方框裡,每隔幾秒就逼你停下來等待新訊息載入,還不斷跳出分散注意力的通知,把你拉回他們能變現的新內容上。
而在 Timelinize 上,閱讀體驗就是為了讓你好好讀自己的封存資料。沒有任何東西想偷走你的注意力、引誘你去看最新動態,因為 Timelinize 呈現的是歷史快照。我覺得很有趣的是,可以直接跳到 10 年前的某一天,回頭看看當時的對話是什麼樣子。

Timelinize 的介面讓你閱讀對話時,不會被通知搶走注意力。
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,她協助 Lachlan 研究漏洞、通知廠商,並找出願意為此漏洞支付獎金的漏洞獎金計畫。
Lachlan 的文章獲得較多關注,但我覺得 Sylvie 的更有意思,尤其是考慮到她當時還只是一名 20 歲的大學生。
Lachlan 和 Sylvie 都意識到他們找到了一顆影響數百甚至數千個大型網站的「核彈」。在向 Meta(維護 React 的公司)和 Vercel(維護 Next.js 的公司)回報漏洞後,他們想找出其他願意為這個重大漏洞付費的漏洞獎金計畫。
研究人員在 Meta 公開發布資安公告之前,不能向其他廠商揭露這個漏洞。問題在於,一旦 React2Shell 公開,Lachlan 和 Sylvie 就會失去領先優勢,其他人也會一窩蜂搶著申報同樣的獎金。
為了搶得先機,Sylvie 在漏洞封鎖期間就先去探勘各個漏洞獎金計畫,並檢查那些廠商的網站是否容易受到 React2Shell 攻擊。這樣一來,等 Meta 一公告漏洞,Sylvie 和 Lachlan 就能立刻去申報這些第三方獎金。
問題是,在 React2Shell 公開之前,Vercel 已經在他們的網頁應用程式防火牆(WAF)中為這個漏洞建立了過濾規則,即使客戶網站仍在執行有漏洞的 React 或 Next.js 版本,也能受到保護。Meta 和 Vercel 也與 Cloudflare 等類似的 WAF 平台合作,教他們如何過濾 React2Shell 攻擊。
所以,在 Meta 公告 React2Shell 之後,Sylvie 試圖在她事先探勘的網站上重現漏洞,卻無法觸發。幾乎所有提供漏洞獎金的網站都架在 Cloudflare 或 Vercel 上,因此 WAF 擋下了 Sylvie 的攻擊程式。
於是,Lachlan 和 Sylvie 必須想辦法讓他們的攻擊程式繞過 Cloudflare 和 Vercel 的 WAF 來觸發 React2Shell,但要繞過企業級 WAF 本身就是一項龐大的研究計畫。幸好,Sylvie 在 Cloudflare 的 WAF 中找到一個繞過方法,並在 Vercel 的 WAF 中找到五種不同的繞過方式。
有趣的是,Sylvie 賺到的錢中「絕大部分」並非來自 React2Shell 本身,而是來自 WAF 繞過,因為 Vercel 每回報一個繞過就支付 5 萬美元。
總結
完成了什麼?
- 發布了新章節:「用 AI 提升寫作」和「站在讀者的角度」
- 與讀者舉辦了一場關於用 AI 改善寫作的線上直播
- 透過漏洞獎金計畫回報了一堆資安漏洞
學到的教訓
- 長期來看,專心寫書對我比追資安漏洞獎金更好。
- 困難的地方在於,漏洞獎金的回報是短期的,而寫書的回報通常至少要一個月後才會顯現。
- 從雲端服務遷移到本地自架的服務,竟有出乎意料的滿足感。
下個月的目標
- 讓《Refactoring English》達到「內容完成」的階段。
- 打造一個工具,讓《Refactoring English》的讀者在閱讀時就能提供回饋。
需要幫忙的地方
如果你有興趣學習如何用 AI 在團隊的程式碼中尋找資安漏洞,歡迎加入我的意願名單。如果有足夠多的人有興趣,我就會開設這門課程。
隨機一篇部落格
留言
登入後參與討論