有些漏洞報告只有一句話：

某某功能有漏洞，可以繞過權限，請確認。

這種報告真的很省字，但收到的人完全不會省事，幾乎一定得回信追問：哪個產品？測試版本是什麼？哪個功能？怎麼繞過？原本需要什麼權限，成功後又多拿到了什麼？

通報不是寫得越長越好。真正重要的是讓另一個沒坐在你旁邊的人，能夠找到同一個位置、看到同一個現象，最後理解它為什麼是安全問題。

所以這篇想談兩套很容易混在一起的標準：一套是 CVE Record 發布時最低要有什麼，另一套是 一份剛送進來的漏洞報告，怎樣才比較容易被處理。兩者有重疊，但不是同一張清單。

先讓人找得到問題在哪裡

產品名稱聽起來是最不可能漏掉的資料，實際上卻常寫得不夠精確。

只寫「後台系統」或「API server」不夠。接手的人需要知道正式產品名稱、元件或模組，最好再附上取得版本資訊的方法。例如版本頁面、套件版本、commit hash、韌體編號，或可以辨認 build 的其他資訊。

版本也不要只寫「最新版」。報告送出那天的最新版，兩週後可能已經不同。比較穩定的寫法是：

測試產品：Example Server
測試版本：3.4.1
受影響元件：admin-api
測試環境：預設安裝，啟用 remote management

如果已經測過多個版本，可以直接寫哪些確認受影響、哪些確認不受影響。這不只省下往返，也可能幫助維護者縮小問題是在哪次變更被引入。

重現步驟要讓別人走得回去

PoC 很有用，但一段可以執行的程式不一定等於完整重現步驟。接手的人還需要知道前置條件：使用什麼身分、功能是否預設開啟、資料要先處於什麼狀態，以及請求應該送到哪裡。

一份容易跟著操作的重現內容，通常會交代：

• 測試環境與必要設定
• 攻擊者原本擁有的權限
• 建立測試資料的方式
• 每一步操作或請求
• 實際看到的結果
• 正常情況下預期看到的結果

「實際結果」和「預期結果」最好都寫。以 IDOR 為例，只貼出一個回傳 200 OK 的 request，還不能證明跨越了授權邊界；如果補上「帳號 A 不屬於組織 B，卻能讀到組織 B 的文件」，安全影響就清楚多了。

log、封包、截圖與 crash dump 都可以當證據，但應該先移除 session token、個人資料與不必要的內部資訊。能用最小測試資料重現，就不要整包上傳真實環境資料。

不只說「能打」，還要說清楚安全邊界

同一個行為，在不同安全模型下可能有完全不同的意義。

例如一般使用者能修改自己的顯示名稱，通常是正常功能；能修改別人的角色，就可能是權限問題。HTML 被原樣儲存不一定就是 Stored XSS，還要看它是否進入瀏覽器可執行的 context，以及產品原本是否允許這類內容。

因此，影響描述最好能回答三件事：

1. 攻擊者從什麼起始權限出發？
2. 哪一條安全邊界被跨越？
3. 最後影響了機密性、完整性或可用性的哪一部分？

可以先用一句不誇大的話收斂：

低權限帳號可修改其他租戶的 webhook URL，可能使該租戶後續事件被傳送到攻擊者控制的端點。

這比「可完全控制系統」更容易驗證，也比較不會讓真正重要的影響被誇張用語蓋掉。

一開始不知道根因，沒關係

研究者看到的通常是外部行為，不一定能取得原始碼。這時可以誠實區分「已確認」和「推測」。

已確認：修改 object ID 後可讀取其他帳號的檔案。
推測：後端可能只檢查檔案是否存在，未檢查 resource ownership。

這種寫法比直接斷言某個 function 缺少檢查更可靠。維護者取得程式碼後，也比較容易回覆真正根因。

漏洞類型或 CWE 也是同樣道理。確定時可以提供候選分類；只有表面現象時，不必為了讓報告看起來完整而硬選一個 CWE。錯誤分類有時比暫時不分類更費時間，因為後面的人得先拆掉錯誤假設。

CVE Record 的最低要求，和初始報告有什麼不同？

依 CNA Operational Rules v4.1.0，一筆要發布的 CVE Record 必須識別至少一個受影響產品、至少一個 affected 或 unknown 狀態、漏洞類型、文字描述，以及至少一個不是 CVE Record 自己的公開 reference。規則也要求至少一份英文描述，並建議提供修補版本。

這些是 Record 發布要求，不是說研究者第一次寄信就必須交出完整 CVE JSON。初始報告最重要的工作，是提供足夠證據讓問題能被定位、重現與判斷；產品版本、描述與公開 reference，可能在協調過程中繼續補齊。

反過來也一樣：一份已經能重現的好報告，仍不代表可以立刻公開 Record。受影響版本、公開 reference 或漏洞類型還不清楚時，CNA 可能需要繼續確認。

寄出前，做一次「陌生人測試」

把報告想像成交給一個第一次看到這套產品的人。他能不能只靠目前內容，找到版本、建立前置狀態、重做步驟，並解釋實際結果為何違反安全預期？

如果答案是可以，這份報告通常已經有很好的起點。若心裡冒出的是「他應該知道我在說哪個頁面吧」，那多半就是還要再補一點上下文。

第 7 天先把 CVE 與 CNA 基礎收在這裡。下一篇進入 CWE：為什麼一筆具體 CVE，還要再對應一個看起來更抽象的弱點分類？