弱點發現速度持續提高之後，企業面對的挑戰往往不只是修補能力，而是如何說明每一次風險判斷與處置決策。
文／游政卿（合勤投控資安長）
做過弱點管理的人都知道，掃描工具跳出大量高風險警示時，通常還不是最忙的時候。真正開始消耗組織資源的，是後面那一段：哪些弱點要先處理？哪些系統可以等到下一個維護窗口？哪些修補可能影響既有服務？哪些需要重新驗證？如果短時間內無法處理，風險又該由誰承擔？很多時候，找到問題只是開始。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
最近一年，AI 在程式碼分析、弱點研究以及開放原始碼分析上的進展，確實讓許多原本需要投入大量人力的工作變得更有效率。從資安研究的角度來看，企業能更早知道問題存在，也有機會更快採取行動。不過從企業管理的角度來看，我比較在意的不是工具能力本身。弱點被發現的速度愈來愈快，但企業後面的流程並沒有出現同樣幅度的變化。研發驗證需要時間，版本發布需要時間，客戶升級更需要時間。做過產品的人都知道，很多事情不是修補程式寫完就算結束。
客戶查核正在看企業如何做決定
這兩年和客戶討論產品安全議題時，我有一個感受愈來愈明顯。大家已經不太花時間討論掃描工具了。幾年前查核時，客戶還會詢問多久掃描一次、覆蓋率多少、修補週期如何管理。現在比較常看到的情況，是直接拿著某個 CVE（Common Vulnerabilities and Exposures，常見漏洞與暴露）來討論，然後一路往下問：什麼時候知道這個弱點？如何確認受影響範圍？是否評估過實際風險？如果沒有立即修補，原因是什麼？誰做的決定？
幾次下來，我發現客戶在意的事情其實變了。以前比較像在確認企業有沒有做，現在比較像在看企業當時怎麼決定。這種變化對產品安全團隊來說其實很有感，因為客戶關心的已經不只是流程是否存在，而是企業是否說得清楚當時的判斷依據。
一個 CVE 後面，往往不只是一個修補程式
對我們這類長期需要承擔產品安全責任的企業來說，這種變化尤其明顯。合勤本身是 CNA，也有專責 PSIRT 團隊，並參與 FIRST 社群及 Secure by Design Pledge。平常就需要面對弱點揭露、版本修補以及客戶通知相關工作。所以看到一個 CVE 時，我們第一個反應通常不是急著發布公告，而是先確認到底有沒有影響。
外面看到的是一個 CVE，但對產品安全團隊來說，後面通常還有很多事情要確認：受影響的是哪些產品？哪些版本需要處理？修補後是否影響既有功能？是否需要重新驗證？客戶是否能在短時間內完成升級？有些弱點最後確認與產品無關，有些確實受到影響但修補後可能造成相容性問題，也有一些情況即使完成修補，客戶仍需要自行安排升級。
前陣子和幾位產品安全主管聊天，大家背景不同，有做網通設備的，也有做軟體服務的。原本聊的是 AI 對弱點研究的影響，結果聊到最後，大家抱怨的其實都差不多：弱點一直進來，待處理項目也一直增加。一個 CVE 出來之後，要確認影響版本、安排驗證、排進發布時程，有時還要準備客戶說明資料。很多人以為找到弱點最麻煩，做過產品安全的人通常知道，後面那段才比較花時間。
[ 推薦閱讀：當 AI Agent 開始做事，CISO 真正該管的是什麼 ]
當弱點數量持續增加時，每一個優先順序背後其實都是資源配置。研發人力有限，驗證資源有限，發布窗口有限，客戶願意接受的變更次數也有限。所以企業最後面對的，通常不是要不要修補，而是如何安排處理順序。
這也是近年愈來愈多人談 Secure by Design 的原因之一。如果產品在設計與開發階段就能降低後續弱點產生的機會，當然能減輕後面的修補壓力。對我們這類需要長期維護產品生命週期的企業來說，愈早把安全考量納入設計，後面需要投入的修補與驗證成本通常也會比較低。不過從產品安全團隊的角度來看，再好的設計也無法保證未來不會出現新的弱點。
這幾年參與 Secure by Design 相關討論後，我有一個很直接的感受：產品安全不能只看弱點數量有沒有下降，後面如何判斷影響、如何安排修補、如何完成驗證，以及如何向客戶說明，同樣是產品安全責任的一部分。也因為如此，企業除了思考如何減少弱點之外，也必須準備好面對弱點出現之後的判斷、修補與記錄工作。
修補證據鏈留下的是判斷脈絡
也是因為這些經驗，我後來愈來愈在意一件事。比起弱點數量本身，我更在意幾個月後回頭看，團隊還能不能說清楚當時怎麼判斷。我自己習慣把這件事稱為修補證據鏈，名稱其實不是重點，重點是半年後回頭看，團隊還能不能把當時的判斷說清楚。
幾年前有一次內部討論，我們回頭檢視一個已經結案好幾個月的弱點。當時大家都記得曾經討論過，也記得最後決定延後發布。但再往下問，為什麼延後？當時評估了哪些風險？有沒有考慮客戶環境影響？會議記錄找得到一些，工單裡也有部分資訊，只是已經很難完整還原當時的判斷脈絡。
那次之後，我對記錄這件事有不同看法。很多決定在當下其實都有合理理由，可能是驗證尚未完成，可能是版本發布時程已經排定，也可能是客戶環境還沒準備好升級。真正麻煩的是時間過去之後，大家是否還記得當時掌握哪些資訊。
我曾在一次查核討論中看到一個很有意思的情況。某個高風險 CVE 已經存在一段時間，企業也知道風險存在，但並未立即修補。查核人員追問的焦點其實不是為什麼沒有第一時間更新，而是企業是否完成評估、是否分析過實際影響、是否有風險接受記錄，以及是否有人正式核准。如果這些資料完整，很多事情其實都說得清楚。反過來說，如果只是開過幾次會議、做過口頭討論，卻沒有留下記錄，即使最後完成修補，事後仍可能面臨許多說明上的困難。
當查核開始追問決策過程
大部分組織都有弱點掃描工具，也都有工單系統。真正容易出現缺口的，往往是中間那段決策過程，包括當時掌握哪些資訊、如何確認影響範圍、是否完成風險評估、誰核准接受風險，以及修補完成後如何確認有效。平常工作忙的時候，這些記錄其實很容易被往後排，但真正被追問的時候，大家最想找的往往也是這些資料。
[ 閱讀所有游政卿之文章 ]
這幾年大家一直在談 AI 對資安工作的影響。從弱點管理的角度來看，我看到的變化其實很直接：問題會更早被看見，數量也可能更多，但驗證、發布、升級、客戶通知這些事情，還是得照原本的步調進行。
最近如果有客戶拿著某個 CVE 來詢問，我比較不擔心找不到弱點資訊。真正讓我在意的，是能不能很快找到當時的評估記錄：誰判斷產品受到影響，誰決定延後修補，當時有哪些風險考量。這些東西平常看起來不起眼，真正被追問的時候，往往才知道它的重要性。
對產品安全團隊來說，弱點公告發布出去通常不是工作的終點，很多時候反而只是後面一連串工作的開始。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
