文／游政卿‧校訂╱CIO 編輯室
《網路韌性法》的 24 小時通報時限一啟動，企業之間的差距，就在於能不能趕在時間還有意義之前，從一個受影響的元件，追出自己的產品、版本與影響範圍。目前，合勤集團具備 CVE 編號機構（CVE Numbering Authority, CNA）資格，為 FIRST（Forum of Incident Response and Security Teams）成員，並已簽署美國 CISA 的 Secure by Design Pledge。
「這個漏洞會影響我們的產品嗎？」
今年 3 月，我在處理一個廣泛使用的開放原始碼元件漏洞時，一個早上同時接到客戶、業務、產品主管，問的都是同一句話。只要弱點牽涉的是廣泛使用的開放原始碼元件或第三方軟體，接下來的追問幾乎都繞著六件事打轉：產品用了這個元件嗎、哪些韌體版本中鏢、市面上還流通哪些版本、停售但還在保固期的機種有哪些、有沒有已經被攻擊的跡象、該通知哪些客戶。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
平常這些問題，慢慢查都沒關係。但一旦碰上《網路韌性法》（Cyber Resilience Act，CRA，Regulation (EU) 2024/2847）的通報情境，時間立刻不夠用。CRA 的通報義務自 2026 年 9 月 11 日起適用：已遭主動利用的弱點，須在知悉後 24 小時內提交早期預警、72 小時內提交弱點通報，並於修正措施備妥後 14 天內提交最終報告。真正的考驗，其實在企業還沒開始填表之前就開始了。如果連自己有沒有中鏢都還搞不清楚，這 24 小時真正要看的，不是填表能力，是能不能在時間內做出一個可以拿去用的判斷。
24 小時，企業得先掌握全貌
講到 CRA 的通報義務，大家的焦點很容易放在時限上，於是企業開始準備通報流程、聯絡窗口、表單。這些準備都該做，但真的遇到重大弱點時，第一個卡住的地方，是連自己到底有沒有受影響，都還判斷不出來。
假設今天早上九點，冒出一個重大 CVE，產品安全事件應變團隊（Product Security Incident Response Team，PSIRT）得馬上釐清四件事：公司到底有沒有用到這個元件、牽涉哪些產品跟版本、有沒有已經被攻擊的跡象、有沒有踩到法規通報的門檻。如果牽涉到第三方元件，還得等供應商回覆確認。這個階段最花時間的，所以不是寫通報，而是把散落在研發、產品、供應商、市場端的資訊拼湊起來，真正花掉的時間大多在資訊整合上。
這種場景，我在處理漏洞的現場看過很多次：PSIRT 手上明明已經有部分資訊，該拍板的主管卻還是遲遲下不了判斷。
比起通報流程本身，我更在意另一個時間指標：Time-to-Know（得知時間）——從外部傳出重大安全議題，到企業能回答「這跟我們有沒有關係」，中間究竟隔了多久。這個數字，才是真正看得出企業準備度的地方。
SBOM 到位，「產品有沒有真的受影響」還沒判斷
軟體物料清單（Software Bill of Materials，SBOM）是 PSIRT 判斷弱點是否成立的重要基礎，沒有 SBOM，PSIRT 連這次漏洞牽涉哪些元件都無從查起。元件名稱只是起點，接下來還要確認版本、確認是否被實際呼叫、確認市場上還有哪些機種在用。
同一個元件可能有好幾個版本，同一個韌體系列也可能分成不同分支；就算某個受影響的函式確實寫在程式碼裡，它有沒有被實際呼叫到，還得再查證。有些元件來自 ODM 或其他供應商，企業自己掌握的資訊常常有缺口。產品裡有這個元件，跟產品真的因為這個漏洞中鏢，中間還隔著一層技術判斷。
SBOM 的價值，光看涵蓋率算不準。真的遇到重大漏洞時，該問的是：企業能不能從一個 CVE，很快追到對應的元件，再從元件追到產品、韌體版本、市場上流通的狀態。這條鏈路只要斷一段，PSIRT 就得靠人力去找人、比對版本、問供應商，24 小時就這樣在等待裡流掉。
最耗時的是資訊蒐集
通報時限壓力下，容易讓人覺得最耗時的是工程師在分析程式碼——有時候確實如此，但更常被低估的，是產品部門確認版本、研發確認元件用法、供應商回覆進度、業務確認市場上還有多少台在用，還要找到真正知道答案的人，這些等待加起來的時間。單一一項或許只花一兩個小時，但全部疊在一起，企業真正反應過來的時間就被拉得很長。
Time-to-Know 量的是企業平常有沒有把產品與版本、元件來源、誰該負責、供應商資訊，這幾條線串在一起——串得起來，代表準備度真的到位。
卡關的是：不知道該問誰
假設一款產品五年前上市，當初負責的工程師早就轉調，產品經理也換過兩任，裡面某個第三方元件來自 ODM，市場上還流通著好幾種韌體版本。就算已經知道漏洞叫什麼名字，PSIRT 還是會卡在一個最基本的問題上：這款產品現在的狀況，到底誰最清楚。
這牽涉的是：產品安全資料到底是存在某個人的腦子裡、散落在信件裡，還是各部門各自的檔案裡。平時這樣做好像沒差，但真的遇到重大事件，資料找得多快，就直接決定判斷得多快。
成熟的 PSIRT，不會只設一個收漏洞回報的信箱，還要清楚知道每一類產品的安全責任人是誰、研發窗口是誰、產品生命週期走到哪，以及重要的第三方依賴出狀況時該問誰。以合勤自己的做法來說，團隊透過 CNA 機制自己管理 CVE 配置，透過 FIRST 跟供應鏈上下游串聯事件應變，並依照 Secure by Design Pledge 的承諾，把責任人跟產品生命週期資料寫進開發流程裡。這些工作平常看起來像行政庶務，但事件一發生，直接決定企業還剩多少時間，可以拿來判斷、拿來反應，而不是拿來到處找人問。
沒有答案的時間，本身就是問題
重大漏洞出現後，產品大致進入三種狀態：確認受波及、確認處於安全範圍、仍在分析。其中，仍在分析的狀態最需要投入管理心力。
仍在分析，代表風險落在哪裡還沒搞清楚。如果高風險產品能在兩小時內判斷出結果，企業還有餘裕決定怎麼緩解、怎麼修補、怎麼對外溝通。但如果拖了兩天還停在確認階段，就算最後證實根本沒事，這段拖延本身，就已經暴露企業判斷不夠快的問題。
PSIRT 成熟度除了看平均多久發布修補程式，更要看前端能力：重大弱點出現後，多久能把待確認（Unknown）轉為已知（Known）。
供應鏈直接決定企業反應速度
產品安全管的範圍，不只是自己寫的程式碼。晶片廠商的軟體開發套件（Software Development Kit，SDK）、開放原始碼套件、第三方函式庫、ODM 韌體，都可能是產品的一部分。這些元件只要出現漏洞，企業的 Time-to-Know 就得看供應鏈的臉色。
平時我們會問供應商有沒有通過 ISO/IEC 27001:2022 驗證、有沒有建立弱點管理流程、有沒有落實安全開發制度。但真的遇到重大漏洞時，更實際的問題是回覆速度：今天問這個元件受不受影響，對方多久能給答案。
如果供應商要三天才能確認，企業的 24 小時通報時鐘可不會等它。供應鏈安全能力，看的是兩件事：有沒有制度，以及這套制度撐不撐得住企業需要的反應速度。
確認受波及之後，工作才排得出優先順序
企業一旦確認受波及，後續工作反而清楚：評估嚴重程度、採取緩解、準備修補、通知客戶，必要時進行法規通報。真正困難的是前面的初步研判（Triage）階段——哪些產品、哪些版本、供應商現在什麼狀態、市場上還有多少台設備在用，這些資訊都還沒到齊。
資訊零散時，管理階層很難做出適切的決策。我會把 CRA 的 24 小時，當成一次壓力測試：測試企業平常建立的產品安全資料、責任分工、供應鏈關係，能不能在時間壓力下，快速形成一個判斷。
Time-to-Know 應該被實際量測
想知道企業自己到底準備得夠不夠，最有效的方法是實際演練一次，比再開一場 CRA 說明會有用得多。
挑一款產品實際用到的第三方元件，假設它今天爆出一個重大、而且已經被拿來實際攻擊的漏洞，開始計時，看多久能回答五個問題：哪些產品用了這個元件、哪些版本中鏢、目前市面上哪些版本還在安全支援期、技術判斷該找誰、如果答案得靠供應商，要多久才拿得到。
剛開始演練，粗略沒關係。第一次可能要花兩天，下一次縮到八小時，再下一次兩小時——這幾個數字，比一句「我們已經建立通報程序」更能反映企業真正的準備度。程序說明的是企業知道該做什麼，Time-to-Know 量出來的數字，才驗證企業實際花了多久才做到。
Time-to-Know 這個指標本身，也可能被操作。一旦被排進管理報表，PSIRT 自己最快把數字壓低的做法，就是提早把狀態標成「已知」，證據其實還沒到位。所以有沒有真的完成，不能由 PSIRT 自己說了算，得由稽核或上級主管回頭抽查證據本身。這套演練還有一個前提：企業得先有基本的工單系統跟查得到的版本紀錄——連這些都沒有的組織，第一步該做的是先把告警簽收的流程建起來。
24 小時買到的是判斷時間
CRA 的 24 小時要求，容易讓企業把注意力放在最後期限上。但如果前面二十小時都花在確認自己有沒有受影響，就算最後四小時通報流程走得再完整，也補不回前面缺的那些受影響產品、版本與範圍資訊。
真正成熟的準備，是把時間往前移：產品資料平常就找得到、版本跟元件可以追溯、責任人隨時找得到人、供應商清楚知道哪些問題非快速回覆不可、PSIRT 在事件發生之前，就已經知道第一通電話該打給誰。
[ 閱讀所有 游政卿 的文章 ]
這些工作平常看起來跟通報八竿子打不著，卻直接決定了初步研判要花多久。
所以如果有人問我「CRA 的 24 小時，我們準備好了嗎」，我會先把通報表單放一邊，反問對方：假設今天早上九點出現一個正在被利用的重大漏洞，中午之前，我們能不能跟管理階層說清楚，哪些產品、哪些版本受到波及。
如果連這個問題都答不清楚，該優先補強的就是 Time-to-Know。重大產品安全事件裡，企業最珍貴的資產，不是任何一份文件或流程，而是能提早看清處境的那個時間點。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
