想設立漏洞懸賞專案，應界定一套通報者能夠遵循的制度，並留意相關的法律要求

在過往的資安新聞報導裡，一談到漏洞懸賞（Bug Bounty），往往集中在研究人員得到多少獎金，或是企業願意為了漏洞提供的獎勵多寡，甚至是研究人員通報漏洞卻得不到應有的報酬等議題，但較少提及一般企業該如何設置相關的獎勵制度與賞金獵人溝通的管道。一般而言，大家通常只看到企業開放的懸賞項目及金額。

在2023臺灣資安大會上，資安社群UCCU成員Vic Huang特別公開企業設置與運作漏洞懸賞專案的經驗，以及他本身曾從事賞金獵人的過程，彙整雙方面臨的問題與作法，從而提供設立漏洞懸賞計畫的建議。

為何企業需要經營漏洞懸賞專案？從最基本的層面而言，自然是找出系統的漏洞或程式設計上的邏輯弱點，並予以修補，尤其是企業的開發人力、資源、時間往往相當有限，難以通盤檢驗整個系統的安全。有了這樣的專案，企業不只有了徵求研究人員發現漏洞的管道，甚至能進一步控管這些瑕疵的後續處理事宜，例如：登記CVE編號進行管理，或是向賞金獵人買下零時差漏洞，進而在修補之前防堵漏洞遭到利用。

此外，企業一旦成立了漏洞懸賞專案，也代表他們相當重視資安，對於企業的名聲也有所助益。

接獲漏洞需要與通報者、內部開發人員進行溝通

然而，持續運作這類專案並不容易。Vic Huang指出，在接獲漏洞通報後，專案小組必須先確認，通報者是否為第一手消息來源？這項漏洞是否已被利用？以及漏洞對於企業或是服務的損害情況為何？

若是漏洞需要進行修補，漏洞懸賞專案小組也必須與內部溝通，向RD或是研發部門表明必須修補漏洞的原因，以及帶來的風險等。若是收到較為緊急的漏洞通報，需要3天至7天內完成處理，該如何說服相關部門的專案負責人（PM），也是處理漏洞通報時所需要面對的工作。

由於現在許多企業導入DevOps，開發時程大幅縮短，每2週就會推出新版本的專案，很有可能前天才釋出，今天就收到漏洞通報的資料，因此，漏洞懸賞專案的負責人員也要幫忙協調，促使研發團隊能夠在繁忙的開發流程當中，執行漏洞修補的工作。

還有，專案小組接獲的漏洞，也有可能出現在不同的系統或是服務，若要進行徹底的清查，往往要花費很多時間。

建立良好制度將有助於抓漏工作的進行

既然企業在執行這種漏洞懸賞的工作會面臨許多挑戰，有那些是需要特別注意的部分？Vic Huang認為，在設定此類專案的過程中，若能夠進行充分的內部溝通，建立明確的通報規則，日後實際執行相關工作會較為順利。

首先，這類專案須徵求老闆或上司的認同。由於漏洞懸賞涉及獎金的預算，也會需要相關資源因應，但上司很有可能不清楚其中的內容，如處理獲報的漏洞的過程，可能面臨一些狀況而導致需要額外的處理成本，此時往往需要透過上司向公司高層爭取額外預算。若是上司對專案內容有一定程度的了解，將有助於獲得所需的資源。

再者，是必須明確規範執行的範圍，以及獎勵的內容。企業很可能會在懸賞的資訊當中，表明特定網域上的應用系統、服務，其漏洞是在專案的懸賞範圍當中。

在成立漏洞懸賞專案的過程裡，推動者尋求公司高層支持之餘，也要規畫相關的規則，並兼顧法律與會計層面，然後在正式上線前，指派相關負責人進行演練，檢驗是否其中是否有需要調整之處。

但Vic Huang也提到最好明確指定範圍，舉例來說，有些人可能會用*.google.com，表示其抓漏範圍涵蓋所有google.com的服務，這麼做看似一勞永逸，但問題是，若有個公司10年前曾經提供的服務，現在專案負責人有可能根本不知道其用途，而這個已經淘汰的系統變成賞金獵人刷漏洞的標的時，公司因此必須支付大量獎金，卻無法改進重要系統的安全。

而對於漏洞的類型，Vic Huang認為企業可指定受理的漏洞類型，以及定義獎勵的多寡，例如，在Tier-1服務上面的漏洞，給予較高的獎金；在Tier-2或較為不重要的服務，獎金會略低。

其次，則是專案可設定為公開徵求漏洞，或是尋求少數人士來抓漏。什麼樣的情況會需要邀請特定對象參與？像是應用系統可能無法承受大量賞金獵人執行指令碼癱瘓，企業就有機會選擇這種模式，看看會不會因此導致服務出現問題，概念有點類似「試營運」。

最後，漏洞的揭露規範也很重要。這類懸賞專案必須明確告知賞金獵人，在何種情況之下，才能公開他所找到的漏洞。例如，漏洞修補完成，且由通報者進行確認，之後等到企業同意，才能公布漏洞的相關資訊。

附帶一提，企業也可以表明非懸賞的項目將視情況提供獎勵，但這可能給專案小組增加很多工作。

合作夥伴契約、法律文件、賞金支付流程要特別留意

除了對於抓漏的範圍、漏洞類型、如何揭露，企業都要有明確的定義，Vic Huang認為，很多人可能會忽略法規遵循的層面。首先，很多公司可能會使用外部的漏洞懸賞平臺（如HackerOne），那麼，與這類平臺簽定的契約內容就要特別留意。

再者，有些企業要求賞金獵人簽署的保密協議（NDA）文件、支付獎金的流程，也需要準備。針對文件的部分，Vic Huang認為需有相關的範本，並且要讓公司的法律團隊協助檢視。

而對於付款的流程，也要有規畫，因為，企業很有可能會面臨相關稅務的問題，導致通報者的觀感不佳。Vic Huang以他曾找出某個國內公營事業的漏洞為例，負責人不僅晚了2個月發獎金，並表示該公司忘記計算稅金，因此，要求Vic Huang把這筆錢轉到這位負責人的郵局戶頭，此種增加大家麻煩的做法讓人不禁搖頭 。

值得留意的是，如果漏洞懸賞的標的存放了客戶（或員工）資料，我們也要意識到存在個資外洩的風險，而這取決於公司位於的國家或地區，若必須遵循GDPR，標準又會變高。這些部分都需要事先與公司法務團隊確認，而非等到可能因漏洞導致資料外洩，才不得不處理個資相關法規衍生的問題，這都為時已晚。

在正式上線之前，指派相關人員進行模擬、測試

有了上述的規範並兼顧法律層面的需求，接著企業要進行實際測試，指派相關的工程師來操作，記錄執行的結果，檢視初步規畫的內容，是否存在需要調整的地方。 例如，實際執行之後，很有可能發現懸賞的規畫有疏漏，此時就要根據遇到的情況進行修改，也可以考慮參考其他專案的作法。

雖然要做好相關規畫讓通報者能遵循，但Vic Huang指出，實務上，他們還是會遇到各式各樣的通報者和狀況，因為有些人並非單純想要獎金或尋求名聲、證明自己是很強的駭客，而想要「自我實現」──這種人很可能認為企業收到他們通報的漏洞後，就要對他的百般要求照單全收，而衍生許多糾紛。

他提及有個通報者偏好在臉書公開找到的漏洞，而且有時對於相關資訊的遮蓋並不嚴謹，導致漏洞部分細節曝光，但這些狀況都發生在尚未向企業通報或在企業受理的過程中，就在這位通報者的臉書發文。對此，Vic Huang表示，他們可能會尋求該通報者所屬的公司，透過主管來進行溝通。

但例外情況也不全是壞事。Vic Huang舉出有人發現公司使用者資料流入暗網的情況為例，他最初和通報者表明，這種情況不在漏洞懸賞的範圍，事隔2天，這名通報者表明打下駭客的C2，並找到更多公司內部員工的資訊，提供很多C2伺服器流量資訊，讓Vic Huang能進一步調查，最終甚至找到根本原因──原來有員工不慎安裝惡意瀏覽器外掛程式，導致部分資訊被側錄，並傳送至C2。

即使這項發現完全與漏洞懸賞的內容無關，但因為該名通報者相當誠實，Vic Huang仍決定給予對方獎金鼓勵。

目前在企業與通報者之間，存在著不少漏洞通報流程的衝突，不是企業無法給予適當報酬、不願承認通報者找到的漏洞，讓通報者感到失望；或者，通報者不願遵循相關流程，提供充分的資訊，甚至是在通報前公開細節，而造成企業因應漏洞上的困擾。對此，未來很有可能需要第三方介入，企業與通報者能有更為良好的互動，讓這樣的漏洞懸賞機制帶來正向循環。