我該如何撰寫企業會採取行動的風險發現報告？

大多數安全發現死在電子表格裡，因為它們是為了其他安全人員而寫的，而不是為了簽署預算的人。如果你的報告寫著「CVE-2023-XXXX、CVSS 9.8、立即修補」，你描述的是漏洞，而不是風險。企業不會因為漏洞而採取行動。它會因為能想像到的後果而採取行動。

為什麼嚴重程度分數單獨無法說服任何人

CVSS 告訴你一個缺陷本身有多嚴重。它對該缺陷是否可以被利用、其背後的資產是否關係到收入、或補償性控制是否已經減輕了它，完全沒有說明。一個沒有網際網路路徑、沒有敏感資料的內部開發機器上的 9.8，與支付閘道上的 7.5 不是同樣的對話。如果你純粹按 CVSS 排名發現，你會浪費信譽去修補沒人真的會利用的東西，真正重要的發現則淹沒在噪音中。

能被採取行動的風險有三個要素：一個合理的影響路徑、附加在該影響上的美元或營運成本，以及一個能實際修復它的擁有者。漏掉其中任何一個，發現就會坐在待辦事項裡。

圍繞場景而不是掃描器輸出來建構發現

與其說「在 /login 端點發現 SQL 注入」，不如寫出場景：「未經認證的攻擊者可以透過登入表單提取完整的客戶表，包括雜湊密碼和帳單地址。這個表支援 40,000 個活躍帳戶，同一資料庫保存與 PCI 範疇相關的訂單歷史。」現在讀者不是在解析漏洞類別，而是在想像一封資料外洩通知信和合規電話。

每個發現的有用結構：

• 可能發生什麼 — 以平白語言表述的攻擊路徑，一到兩句話。
• 它涉及什麼 — 特定系統、特定資料、特定業務流程。
• 它要花多少成本 — 停機小時數、監管風險、客戶信任、契約罰款。如果你有實數就用實數（SLA 罰款條款、過去事件成本、網路保險免賠額）。
• 修復要花多少工夫 — 工作量，不只是「修補它」。有時修復是今天的 WAF 規則和下個衝刺的程式碼變更。
• 誰負責修復 — 一個人名或一個團隊，不是「IT」。

將發現與企業已經追蹤的東西連結

每家企業都有領導層已經在關注的指標：正常運行時間 SLA、流失率、上一個 SOC 2 週期的稽核發現、網路保險費、具有安全條款的特定客戶契約。如果你能把你的發現連結到這些已有的項目之一 — 「這是我們的保險商在上次續約時標註的同一類問題」或「這個資料流在 Q3 的 SOC 2 稽核範疇內」 — 你就不是在要求他們關心新東西。你是在向他們展示對他們已經負責的東西的威脅。

這也是在定案報告前和企業端談話能派上用場的地方。花十分鐘和財務或營運人員談談特定系統四小時的停機實際上要花多少成本，勝過任何籠統的「名譽傷害」說法。拿到數字，引用它，繼續。

按可利用性和影響範圍排名，而不只是 CVSS

一個可行的優先順序方法：

1. 它是網際網路可以到達的，還是需要內部存取？
2. 有公開漏洞利用程式，還是純粹理論上的？
3. 它涉及受管制資料（PCI、PHI、PII）或關鍵系統嗎？
4. 實際的修復時間和成本與放著不管的成本是什麼？

In可利用性和影響範圍上評分高但 CVSS 只有中等的發現，通常應該排在只在跳板後面隔著多個網路躍點、有 MFA 的關鍵級漏洞前面。

寫下要求，而不只是問題

用具體請求結束每個發現：預算項目、變更視窗、要關閉的政策例外，或需要在某個日期前做出的指定決定。「我們建議修復」會被忽視。「我們需要在 15 號前的四小時維護視窗來修補支付閘道，或者我們以書面形式接受剩餘風險」會強制做出一個或另一個決定。給領導層一個明確的以書面形式接受風險的選項，並簽上他們的名字，通常是最後讓修復得到批准的關鍵。

如果你想練習將原始掃描輸出轉換成這樣的發現，可以一起進行 Korra Studio 的 Blue Team 和 Offensive 段落 — 將漏洞利用背景與報告練習配對是這項技能真正得到磨練的地方。