先做一題國小算術。

2025 年全年公布了 48,185 條 CVE，平均一天 132 條。

你可能會說，那些大多無關緊要。好，我們只看最嚴重的那一級：Critical 有 3,984 條，佔 8.3%。

除以 365。

一天 10.9 條。

假設你的團隊看一條 CVE 只花三十分鐘就能判斷「這條跟我們有沒有關係」，一天要五個半小時。而這只是判斷，還沒開始修，也還沒算 High 那 15,003 條。

如果你的產品資安團隊是個位數，這道算術的答案很清楚：不是努力一點就做得完，是結構上做不完。

你不是不夠努力，你是接了一個做不完的工作

我最近常想到消防隊。

假設某個轄區一天固定有 132 通報案電話，隊上三個人。這時候「把每一通都接好」聽起來很敬業，實際上是幻想。真正的專業是決定哪幾通要出勤，而且要能解釋為什麼另外那些不出。

資安圈很少這樣講。我們習慣講縱深防禦、持續監控、零信任，每一個聽起來都像「全部都要做好」。但一個資源有限的團隊，第一件該學會的事其實是放棄的方法論。

這也是為什麼我把系列的第三天用來講數字，而不是講解法。**先讓你認清做不完，後面的取捨才有正當性。**否則你會一直覺得自己不夠努力，然後在某個週三晚上十一點對著三千條掃描結果懷疑人生。

更糟的是，時間也在縮短

數量變多是一回事，速度變快是另一回事。

Google 的威脅情資團隊追蹤過一個指標叫 Time-to-Exploit（TTE）：一個弱點從被揭露到出現實際利用，平均隔多久。

五年之間，從兩個月縮到五天。

這對合規的意義很直接：**你的反應窗口跟你的處理量能，正在往相反方向跑。**案件變多、時間變短，中間那個開口就是你的風險。

而 CRA 第 14 條要求 24 小時內送出早期預警。24 小時，比 TTE 的五天還短一個數量級。

那個「三千條」是怎麼長出來的

上面講的是全世界的總量。實務上你不會全部都看，你只看跟自己產品有關的。

但「有關」的範圍比想像中寬。一台工業電腦裡有作業系統、開機韌體、網路堆疊、驅動程式、開源函式庫、加密套件，往下還有晶片商給的 BSP。掃描器跑完一輪，三千條起跳很正常。

這三千條裡，絕大多數落在三種情況之一：

元件在，但那段程式碼不會被執行（這是最大宗）
理論上可利用，但需要的前提在你的產品上不成立
真的有問題，而且已經有修補版本

問題是掃描器不幫你分。它給你的是一份全院體檢報告：每一項紅字都列出來，但沒有一項告訴你先做哪個。

**分辨這三千條，就是這個系列後半段在解的事。**幕三講流程怎麼分，幕五講怎麼用工具把三千條砍到三十條。

交付物：算出你團隊的缺口

這張表拿去給老闆看，比講一小時道理有用。

用法：把最後那一行填出來。

如果是負的，你手上是一個需要自動化或需要加人的問題，不是一個需要加班的問題。這個數字寫進簽呈，比「我們人力不足」有說服力得多——它把主觀抱怨換成客觀算術。

三個提醒。

**第一，這張表算的是研判，不是修補。**修補的工時通常是研判的好幾倍，而且散落在各產品團隊，不在你的中樞。這件事 Day 08 會專門講。

**第二，每人每天可用於研判的工時請誠實填。**扣掉會議、信件、支援、其他專案之後，真實數字通常比你以為的少一半。填三小時的人，實際上大概只有一個半。

**第三，缺口是負的不代表你做錯什麼。**它代表這個工作的設計本來就超出人力上限，而你手上有三條路可以走：把量能拉上來（自動化）、把案件量壓下去（分流），或者把標準往下修（明確定義哪些不處理，並且寫下來）。多數團隊最後是三條一起走，只是順序不同。

明天 Day 04：家裡失火，跟房子要抗震補強

這是整個系列的骨架。CRA 給了兩個期限，一個近一個遠，但性質完全不同。用同一種方法處理，一定會失敗其中一件。附一張對照框架。

順便問一句。你們掃描器最近一次跑完：

吐出來大概幾條？

（a）幾百條　（b）一兩千條　（c）三千條以上　（d）還沒跑過，不太敢跑

留個字母就好，不用打長篇。我猜（d）比想像中多，而且完全可以理解。

這系列每天更新，覺得有用的話訂閱一下，我盡量不寫廢話。

參考：2025 年 CVE 統計取自 Jerry Gamblin 的 2025 CVE Data Review；Time-to-Exploit 數據取自 Google Cloud 威脅情資團隊的 Time-to-Exploit Trends 報告；通報時限見 Regulation (EU) 2024/2847 第 14 條。