我們見過幾乎每一件卡住的漏洞通報，失敗原因都一樣無聊：它寄進了一個沒有人負責的信箱。不是因為廠商態度惡劣，也不是因為發現本身有爭議——那封信就只是掉進了一般客服佇列，被標成客戶抱怨，然後過期了。技術的部分反而是簡單的那一半。
以下是我們實際採用的順序，以及每一步的心得。
一、先找 security.txt
在做任何事之前，先試 https://vendor.example/.well-known/security.txt。這只花五秒鐘。如果它存在，通常會給您一個真的有人看的信箱、偏好語言，有時還有 PGP 金鑰——這代表您的第一封信就能加密、而且寄對地方。
台灣廠商的採用率還不高，但在成長，而且這是個不錯的早期訊號：會發佈 security.txt 的廠商，通常已經想過收到通報之後該怎麼辦。
二、找到一個人，而不是一個部門
如果沒有 security.txt，我們會先找一個具名的人，而不是先找信箱。給過大會議程的資安工程師、commit 歷史裡的維護者、專業社群上的產品經理都算。寄給一個人的信會被讀；寄給 support@ 的信會被分類。
這個做法感覺繞遠路，確實也是，但另一種結果是看著一個重大發現六週都沒人讀。
第一封信該寫什麼
產品與確切版本。一句話說明影響，用商業語言。一句話說明利用難度。您預計的公開日期。以及願意透過加密管道寄出完整報告。就這樣——五行。技術細節留到對方回覆之後再寄，因為第一封信只有一個任務：讓一個真人回話。
三、透過 TWCERT/CC 升級
當直接聯絡失敗——我們的判斷門檻是沉默十四天——對台灣廠商來說，下一步是 TWCERT/CC。他們營運漏洞通報平台，擁有個別研究員所沒有的、通往國內廠商的機構管道，也能協助 CVE 編號的申請。相關流程請以他們公告的版本為準，而不是這裡寫的內容；那些流程確實會更新。
若是國外廠商，對應的步驟是該國的國家級 CERT，或美國的 CERT/CC。若是開源專案，通常是專案 repository 裡自己的安全政策，然後才是負責打包發行的各發行版維護者。
四、需要 CVE 時才找 CNA
CVE 編號不是揭露的目的，但它是防守方日後找到您的通報的方式、是掃描器標記受影響版本的依據，也是忙碌的系統管理員爭取臨時維護時段的理由。去申請一個。
如果廠商本身就是 CNA，由廠商指派是最理想的。否則就走涵蓋該產品範圍的 CNA，或相關的國家級協調機構。請預期這一步比技術修補還久。
五、公開，但保留利用細節
我們自己的政策是從確認收件起算九十天，而且公開日期會寫在第一封信裡，所以它永遠不會是個意外。當天發佈的通報包含編號、受影響產品類型、缺陷類型、CVSS 評分與修補狀態——足夠讓防守方判斷自己是否受影響、該怎麼做。
PoC 則等到修補真正能被使用者取得之後才釋出，那往往比廠商宣稱發佈的時間又晚了數週。躺在一個沒人部署的組建裡的修補保護不了任何人，這時候公開可運作的利用程式，只是在白送優勢。
目標不是搶第一。目標是讓能修這個問題的人，增加得比能濫用它的人更快。
完全沒有人回覆時
這種情況確實會發生，最常出現在已停產的產品，以及離實際撰寫韌體者隔了三層的 OEM 硬體上。我們的做法是：發佈通報，附上緩解指引但不含利用細節，明確說明廠商未回覆以及我們嘗試聯絡的日期，並通知國家級 CERT 讓這筆紀錄留在某個官方之處。一個營運者知道的未修補缺陷，仍然勝過一個沒人知道的未修補缺陷。