Hacker V Triage: The Bug Bounty Battleground by Richard Hyunho Im & Denis Smajlović | BBV DEF CON 33
三句話摘要
Bug Bounty 計畫的研究者與審理團隊間的溝通障礙與協作最佳實踐。 Bug Bounty 計畫的成功取決於公司投入專職資源、建立明確流程、維持誠實溝通，並讓研究者感受到他們的工作被尊重與適當認可。 實際運作與預期的鴻溝來自組織內部混亂。公司跳入 Bug Bounty 時常低估工作量，將其交給已超負荷的 on-call 人員，導致回應緩慢、評估不當、或乾脆不回應。同時法務、通訊等部門介入時，因對程式目的理解不足而設置障礙（如害怕高賠償會暗示產品有嚴重問題），進一步惡化流程。
重點整理
重點- 1
實際運作與預期的鴻溝來自組織內部混亂。公司跳入 Bug Bounty 時常低估工作量，將其交給已超負荷的 on-call 人員，導致回應緩慢、評估不當、或乾脆不回應。同時法務、通訊等部門介入時，因對程式目的理解不足而設置障礙（如害怕高賠償會暗示產品有嚴重問題），進一步惡化流程。
- 2
高品質報告的關鍵是簡潔與可重現性，不是詳盡的技術說教。Triager 最需要的是「端點 X 的參數 Y 未進行 Z 過濾」這樣的直敘法，而非複製貼上 Wikipedia 關於 XSS 的段落。許多 LLM 生成的報告讓人頭昏，反而延長審理時間；清晰的復現步驟讓專家立刻掌握問題，加快決策。
- 3
禮貌的異議和補充背景資訊往往改變公司態度。Richard 向 Apple 指出報告符合其公開類別後，Apple 重新評估並額外支付 $4,000；向 Google 說明 app lock 繞過的業務風險後，激發了重新考慮。誠實溝通與建立個人信任，比對抗性姿態更能解決分歧。
- 4
公司改善程式的系統性方案包括資源與流程整合。提供 Triager 完整測試帳戶與文件以減少內部升級；確立明確的嚴重性分級與賠償表以增進一致性；指定專職團隊而非 on-call 人員；確保法務、溝通等部門達成對 Bug Bounty 目的的共識；透過社群活動與事件吸引並留住優秀研究者。
實用技巧與重點
乾貨- 研究者成績案例：Richard（1.5年經驗）獲 Apple 15 次認可、3 個 CVE、Google 和 Microsoft 認可
- 具體漏洞案例：
- Microsoft Authenticator Face ID bypass：提交清晰 20 秒 POC，被判 moderate 級別，無賠償，90 天保密期
- Apple iOS Siri 側通道：繞過鎖屏存取最近應用（如 ChatGPT）內容，初期判定不符類別，異議後獲 $4,000 賠償
- Google Drive app lock 繞過：透過 Safari 分享按鈕存取受保護應用，Google 判定因需先解鎖手機故不構成問題
- Triager 資源瓶頸：測試帳戶受騙欺流程限制、缺乏文件、無法執行測試購買
- 常見程式問題：回應緩慢/無回應、嚴重性低估、有效報告遭拒、內部衝突（法務擔憂責任曝露）
- 改善機制：統一審理工具（如 Hacker One、BugCrowd）、明確的賠償指南、自動化工單分派（Jira）、專職審理團隊、定期研究者回饋、社群活動和線上駭客馬拉松
結論
結論“Bug Bounty 計畫的成功取決於公司投入專職資源、建立明確流程、維持誠實溝通，並讓研究者感受到他們的工作被尊重與適當認可。”
完整解析
詳細Bug Bounty 計畫的理想流程聽似簡單：研究者發現漏洞、提交報告、公司驗證、支付賞金、發布修補。但現實運作中，大多數計畫都在溝通與流程上出問題，導致研究者感到不被尊重。
問題根本來自公司資源配置不當。Dennis 觀察到許多大型科技公司將 Bug Bounty 工作交給已超載的 on-call 人員，期望他們每天只需花 30 分鐘。但實際上這涉及大量上下文切換、內部協調、外部溝通，以及維護往期賠償紀錄以確保一致性。當 Bug Bounty 被視為低優先級工作，積壓會累積，測試帳戶故障，問題惡化成無人能控制的局面。更複雜的是，法務部門往往擔心高額賠償會傳達產品有嚴重安全問題的訊號，導致政策模稜兩可，最終讓研究者感到評估標準不公平。
Richard 分享的微軟認證器案例很典型：他發現 Face ID 繞過並提交了清晰的 20 秒 POC，微軟迅速修補卻判定為 moderate 級別不付款。更令人沮喪的是保密協議讓他無法討論這個明顯的安全承諾破口。他的 Google Drive app lock 案例更離奇：Google 的論點是「手機必須先被解鎖」，但那正是所謂的安全控制應該防止的情況。這種邏輯脫節正是研究者最感挫折的地方—不是金錢，而是他們的工作投入沒有被合理認可。
改善的關鍵在兩端平衡。研究者這端，應該提交簡潔、可直接重現的報告，假設閱讀者從未接觸過該產品。許多 LLM 生成的冗長報告反而浪費審理時間；Dennis 強調「端點 X 的參數 Y 未過濾 Z」這類表述已足夠，無須複製 Wikipedia 段落。公司這端，必須投資基礎設施：為 Triager 提供工作測試帳戶、內部文件、統一的審理工具；建立明確的嚴重性分級與賠償表以保證一致性；指定專職團隊（非 on-call）負責；最重要的是，確保法務、溝通、工程等部門達成對 Bug Bounty 目的的內部共識。
溝通本身也是修復分歧的工具。當研究者禮貌而有據地指出公司判定有誤時，絕大多數公司會重新考慮。Richard 向 Apple 指出他的漏洞符合公開的類別，Apple 重新審視並增加賠償 $4,000。這示範了誠實對話的力量。Dennis 在擔任 Triager 時也經歷過類似翻轉：起初判定不符範圍，Richard 提供更多背景後，他和內部團隊決定接受並支付賞金。多數分歧都能透過這種理性回應而化解。
最後，公司應透過社群參與（如 DEF CON 會議）和定期的線上或現場駭客馬拉松吸引並留住優秀研究者。研究者的話語在彼此間傳播，好的計畫會獲得聲譽，不良的計畫會被口碑打擊。Richard 例舉，微軟因回應速度與嚴重性評估問題，已讓他改變對該計畫的投入心態，即使發現問題也寧願不報。相反，Apple 因透明溝通與公平對待贏得他的信任，讓他持續貢獻。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
