Apple 為漏洞懸賞報告加配額：AI 搵到線索，研究員仲要交到證據

Apple 開始為漏洞懸賞計劃加閘：每名研究員可以提交嘅報告數量有上限，觸及配額後會有 30 日冷靜期，想繼續交就要申請提高配額。呢個改動值得睇，因為 AI coding agent 已經令搵可疑程式碼平咗同快咗好多，但判斷嗰段程式碼係咪真係可以俾人利用，依然要研究員逐步驗證。

限制提交量，計劃冇停收

Apple 向 Financial Times 確認，配額同 30 日冷靜期喺 6 月加入內部保安報告平台。改動落喺每名提交者嘅入口，成個懸賞計劃照常運作，Apple 亦冇全面禁用 AI。 公司暫時冇公開實際配額數目，超額申請會點批亦未有完整準則，所以唔應該將呢次改動理解成 Apple 為全部漏洞報告設總上限。

圖片：Apple

AI 發現只係報告嘅起點

Apple 官方指引寫得幾直接：合資格報告要完整、可跟進，通常要有可運作嘅 exploit 或 PoC，清楚示範安全影響；指定類別仲要取得 Target Flag。純理論推測、冇可靠重現方法，或者 AI 搵到但未經人手驗證嘅問題，都唔合資格。換句話講，模型可以幫手翻程式碼、追資料流同提出攻擊路徑，不過研究員仍要親自證明條路真係行得通。

Apple 另有一套較重嘅處理：研究員如果反覆提交唔合資格報告，官方可以暫停處理 180 日；研究員如果俾官方暫停處理多過兩次，Apple 甚至可能永久取消佢嘅參加資格。呢個 180 日處分同今次報道提到嘅 30 日冷靜期係兩回事，前者針對持續交垃圾或錯誤報告，後者就係入口層面嘅流量限制，兩個數字唔應混埋講。

搵線索平咗，驗證成本冇跟住跌

AI agent 可以長時間掃大量程式碼，同時生成多條假設，再自動整理成一份睇落好完整嘅報告。麻煩係，接收一方仍然要搭返相同環境、重跑步驟、排除重複個案、核對產品範圍，再判斷攻擊者實際做到咩。提交一份推測嘅成本可能只係幾個 prompt，反駁佢卻要保安工程師花幾個鐘；大量未驗證輸出堆埋一齊，真正高風險漏洞反而會排得更後。

GitHub 同 curl 都俾低質報告拖慢

GitHub 今年 5 月公開話，過去一年收到嘅報告大增，當中好多冇 PoC、只講理論攻擊，或者連實際安全影響都證明唔到。GitHub 話歡迎研究員用 AI，亦認為 AI 可以放大研究能力，但交報告前一定要先驗證同重現問題，再附上可運作嘅 PoC。呢套標準其實同傳統 scanner 一樣：工具負責提示，人就要為報告準確度負責。

資源較少嘅 curl 項目就採取更硬嘅做法。維護者 Daniel Stenberg 話，團隊曾經喺 16 小時內收到 7 份 HackerOne 報告，部分真係搵到程式錯誤，但最後冇一份構成安全漏洞；2026 年初已累積 20 份同類提交。curl 其後喺 1 月底停止付費懸賞，希望移除大量亂交報告嘅金錢誘因，同時繼續接收研究充分嘅真正漏洞。

漏洞披露會多一層品質閘口

對認真做研究嘅人，AI 依然好有用：可以幫手搵入口、縮窄範圍、寫測試架構同整理證據。不過交報告前要做嘅功夫反而更清晰，包括喺受支援版本重現、排除已知問題、準備最小可用 PoC，再解釋攻擊者可以跨過邊條安全界線。Apple 下一步點批額外配額，同高質素研究員會唔會因新限制等耐咗，先會反映呢套閘口實際有幾準。

參考來源

• Engadget — Apple caps bug bounty program due to deluge of AI submissions — original report
• Apple caps security bug reports amid surge in AI-generated findings — Apple 向 Financial Times 確認改動，係配額安排嘅主要報道來源。
• Apple Security Bounty Guidelines — Apple 官方列出完整報告、PoC、Target Flag、人手驗證同 180 日暫停處理規則。
• Apple Security Bounty Terms and Conditions — Apple 官方條款，確認重複、大量提交未經驗證 AI 報告可令參加資格終止。
• Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program — GitHub 官方解釋點解歡迎 AI 輔助研究，同時要求重現、驗證、PoC 同實際影響。
• Daniel’s week: January 16, 2026 — curl 維護者親自交代報告數量、審核負擔，同停止漏洞懸賞嘅原因。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。