啟用 VDP
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
用較少的預算開始
雖然有提到,但值得重新審視。您可能會想「公開」推出您的計畫 (例如向全世界宣布計畫),或採用內部計畫,使您的計畫政策和報告提交表單開放公開存取。這可能會產生風險,因為您無法從小規模著手擴充。無論準備多少準備工作
發布 VDP 時一定會發生意外您收到的安全漏洞可能會超出預期,並且無法跟上進度。可能有一半的團隊因生病而無法分類錯誤。也許您忘記執行經過驗證的掃描,而研究人員卻建立 100,000 個新帳戶,意外使系統發生洪水!無論意外狀況為何,最好先從小規模著手,再慢慢擴充計畫。您可能會遇到任何問題,這是正常現象,但最好還是使用頻寬一次處理這些問題。
如果您決定在內部建構計畫,仍然建議您在網站上建立計畫政策和報告提交表單。不過,您可能需要要求駭客必須先登入才能看見。如果您使用第三方平台,該平台會自動為您邀請少數安全性研究人員。無論是何種情況,您都可以建立邀請範本,用來邀請駭客參與您的私人 VDP,如下所示:
您好:
<您的機構名稱> 想邀請您參加我們的私人 VDP。為了盡可能為安全性研究人員提供最佳體驗,我們會先從私人模式下著手進行 VDP 程序。請參閱我們的計畫政策,瞭解測試規範和範圍。如果您在 VDP 的早期階段有任何意見回饋,歡迎與我們分享。第一組研究人員受邀並獲準存取您的計畫後,系統就會開始產生報表。或者您可能不會收到任何報告,但沒關係。假設您邀請五位安全性研究人員。可能是因為兩個成員過於忙碌,決定完全不查看程式。另一位使用者可能正在休假,因此完全錯過你的邀請訊息。第四和第五名駭客可能會看一到兩天的時間進行測試,但最後沒有發現任何安全漏洞。他們可能會在幾週後回來進行回報,但還是要完成所有工作、發送邀請,也不收到任何報告。如果發生這種情況,請別擔心。這屬於正常現象,您為何要從小規模著手再擴大規模。如果您傳送了五次邀請,但是報表量不夠多,請再傳送五次,然後再傳送五、十筆或二十筆。如果您使用第三方平台,這類平台即具備自動化機制,可根據所需的報告量,隨著時間緩慢邀請駭客。另一方面,如果您只邀請五位安全性研究人員後才收到大量的安全漏洞報告,您可能會想在報告量減少之前再發出更多邀請。
分類並反覆測試
在發布 VDP 後的第一或兩週內,您可能需要安排兩名以上的職責同時協助分類收到的安全漏洞報告、回報錯誤,以及與研究人員溝通交流。一般來說,計畫推出時會出現大量的報表,因此會隨著時間而趨於穩定。將收到的安全漏洞報表分類時,您可能會收到駭客的意見回饋,並找出計畫政策中的漏洞或誤解。您也可能會在處理程序和工具中發現問題。如果您一開始是小規模,且在前幾週獲得團隊的注意力和精力,不妨利用這段時間快速疊代及改善您的計畫。一個月或兩個月後,一切就會停止,順暢執行程式也會成為第二次本質。
向上擴充、公開發布
隨著您的團隊習慣執行計畫,您也會邀請更多駭客參加。您已擴大範圍,納入所有已知的資訊 (甚至包括您不知道的資產)。畢竟,您或許會因此到收到一百或幾百名駭客的消息,但報告量卻似乎會日漸降低。所有該階段的報告嚴重性為低或中度。輪值輪換似乎不容易,您的團隊很擅長分類安全漏洞報告、將安全漏洞報告推送至解決方案,並與駭客聯絡。此時,您已準備好公開發布計畫。開始執行前,請先與所有相關人員聯絡,確保他們知道,並已入選您公開發布計畫的名單。與首次公開發布類似,請讓團隊做好準備,以因應另一項可能在公開發布規模上的報告量增加問題。公開發布作業的主要差異在於,任何人都能提交安全漏洞報告給您。請注意,這麼做可能會產生大量雜訊。例如,對於如何登入帳戶的使用者感到困惑,甚至是利用表單填寫並傳送電子郵件的垃圾內容機器人,就可能將報告提交至 VDP。有時候,您可以採用範本來快速關閉常見的非安全性相關報告,甚至可以調整表單,將使用者重新導向至正確位置 (例如忘記密碼之類的支援人員)。更重要的是,您可以將計畫對外公開,讓技術老練的駭客過去無法聯絡您。現在,這或許有助於找出您不知道的高嚴重性或重大嚴重性安全漏洞。此外,本文還具備本文先前提及的所有好處,包括建立全球駭客社群的標準化管道,直接向您揭露安全漏洞,降低資料侵害風險和負面公關風險。
歡慶同樂
恭喜!你的評論成效更上一層樓,且你現已取得公開 VDP。也別忘了和你的團隊及所有相關人士一起慶祝。請務必表達謝意,並設法一起慶祝您的成功。除了慶祝 VDP 公開發布事宜外,也別忘了慶祝各個里程碑,例如產品公開發布的一年週年,或是特別透過 VDP 發現並修正的特別有趣和重大錯誤。收集相關指標有助於證明您的計畫成功,並突顯您和團隊的成就。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-26 (世界標準時間)。
[null,null,["上次更新時間:2025-07-26 (世界標準時間)。"],[[["\u003cp\u003eStart your VDP privately with a small group of researchers to refine processes and handle initial vulnerabilities before a public launch.\u003c/p\u003e\n"],["\u003cp\u003eRegularly iterate on your program policy, workflows, and tooling based on researcher feedback and initial findings.\u003c/p\u003e\n"],["\u003cp\u003eGradually scale up the program by inviting more researchers and expanding scope as your team gains experience and report volume stabilizes.\u003c/p\u003e\n"],["\u003cp\u003eBefore going public, ensure stakeholder alignment and prepare for an increased volume of reports, including non-security-related submissions.\u003c/p\u003e\n"],["\u003cp\u003eCelebrate milestones and recognize the contributions of your team and stakeholders throughout the VDP journey.\u003c/p\u003e\n"]]],["Initially, start with a small, private program, inviting a few researchers to test and refine processes. Triage incoming reports, address feedback, and improve the program. As the team becomes proficient, gradually invite more hackers. When the volume and severity of reports decrease, prepare for a public launch, notifying stakeholders and readying for a potential surge. After launching publicly, address non-security reports efficiently and celebrate this achievement, highlighting ongoing milestones and successes.\n"],null,["# Launching Your VDP\n\nStart small\n-----------\n\nWhile this has been mentioned before, it's worth revisiting. It may be\ntempting to launch your program \"publicly\" by announcing it to the world, and in\nthe case of an in-house program, making your program policy and report\nsubmission form publicly accessible. This can be risky, as it does not give you\na chance to start small and scale up. No matter how much you prepare, there will\nalways be surprises when you launch a VDP. You might receive more\nvulnerabilities than expected and not be able to keep up. Maybe half of your\nteam comes down sick and is unable to help triage bugs. Perhaps you forgot to\ntry running authenticated scans, and when a researcher does, it accidentally\nfloods your system by creating 100,000 new accounts! Whatever the surprises may\nbe, it's better to start small and slowly scale your program up over time. You\nwill run into issues, which is totally normal, but it's best to have the\nbandwidth to handle these issues one at a time.\n\nIf you've decided to build your program in-house, you'll still want to stand\nup your program policy and report submission form on your website, but you may\nwant to require hackers to login before being able to see it. If you're using a\nthird party platform, they will automatically handle inviting a small set of\nsecurity researchers for you. In either case, you can create an invitation\ntemplate to use for inviting hackers to your private VDP, like this:\n*Hello,* *\\\u003cYour organization name\\\u003e would like to invite you to\nparticipate in our private VDP. We're starting small in private mode so we can\nbuild upon our VDP processes to provide the best experience possible for\nsecurity researchers. Please check out our program policy for testing guidelines\nand scope. If you have any feedback for us in the early stages of our VDP,\nplease let us know.*\n\nAfter your first set of researchers have been invited and given access to\nyour program, reports will start to come in. Or, you may not receive any\nreports, but that's okay. Let's say you invite five security researchers. It's\npossible two of them are too busy and decide not to look at your program at all.\nAnother one may be on vacation and entirely miss your invite message. The fourth\nand fifth hackers might take a look and do some testing for a day or two, but\nnot find any vulnerabilities. They may come back to it a few weeks later and\nreport something then, but it can still be shocking to go through all of this\nwork, send out invites, and not receive any reports. If this happens, don't\nworry. This is totally normal, and why you want to start small and scale up. If\nyou send out five invites and aren't seeing much report volume, send out five\nmore, then another five, or ten, or even twenty. If you're using a third party\nplatform, they have automated mechanisms that will invite hackers slowly over\ntime based on desired report volume. On the other hand, if you get a huge number\nof vulnerability reports after only inviting five security researchers, you\nmight want to hold off on inviting more until your report volume slows\ndown.\n\nTriage and iterate\n------------------\n\nFor your first week or two after launching your VDP, you may want to have two\nor more people on duty at the same time to help with triaging incoming\nvulnerability reports, filing bugs, and communicating with researchers. Usually\nthere's a large spike of reports at the launch of a program, then it settles\ndown over time. As you triage incoming vulnerability reports, you might receive\nfeedback from hackers and identify gaps or misunderstandings in your program\npolicy. You might also find issues in your processes and tooling. As you start\nsmall and have a lot of attention and energy from your team in these first\ncouple of weeks, use this time to quickly iterate and improve upon your program.\nAfter a month or two, things will die down, and running your program smoothly\nwill become second nature.\n\nScale up, launch publicly\n-------------------------\n\nAs your team gets used to running your program, you'll invite more and more\nhackers to participate. You've expanded your scope to include everything you\nknow about (and even assets you perhaps didn't realize existed). Eventually, you\nmay get to a point where you've invited one hundred, or even a few hundred\nhackers, but report volume seems to be dwindling. The reports being sent in all\nseem to be low or medium severity. On duty rotation seems to be fairly light,\nand your team is well versed in triaging vulnerability reports, pushing them to\nresolution, and communicating with hackers. At this point, you're likely ready\nto launch your program publicly. Before you do so, reconnect with all of your\nstakeholders to ensure they're aware of and bought into your public launch.\nSimilar to your initial, private launch, get your team ready for another\npotential spike in report volume for your public launch. One key difference when\nlaunching publicly is that *anyone* can submit a vulnerability report to\nyou. Keep in mind this can generate a lot of noise. For example, users that are\nconfused about how to login to their account, or even spam bots filling out\nforms and sending emails automatically might submit reports to your VDP. It's\nvaluable to have templates in place for quickly closing out common non-security\nrelated reports, or even pre-empting this by adjusting your form to redirect\nusers to the right place (for example, your support staff for things like\nforgotten passwords). On the bright side, by opening your program up to the\npublic, skilled hackers that had no way of contacting you before will now be\nable to do so. This might help you uncover high or critical severity\nvulnerabilities you didn't know existed. It also comes with all the benefits\nmentioned earlier in this guide, including having a standardized channel for the\nglobal hacking community to disclose vulnerabilities directly to you, reducing\nthe risk of breaches and negative PR.\n\nCelebrate\n---------\n\nCongratulations, You've come a long way, and you now have a public VDP. Don't\nforget to celebrate with your team and all the stakeholders that helped you\nalong the way. It's important to express your gratitude and find a way to\ncelebrate your success together. Beyond celebrating the public launch of your\nVDP, don't forget to celebrate milestones along the way, such as the year\nanniversary of your public launch, or by highlighting particularly interesting\nand critical bugs that were found and fixed via your VDP. Gathering metrics\nalong the way can help demonstrate the success of your program and highlight the\naccomplishments of you and your team."]]