iT邦幫忙

2026 iThome 鐵人賽

DAY 29
0

邱吉爾在敦克爾克之後講過一句話:戰爭不是靠撤退打贏的。

這一整個系列講到這裡,做的幾乎都是撤退式的救援。一條 CVE 進來,判斷、評分、反查、通報、修補,然後下一條。做得再好,也只是撈得比較快。

而每年有將近五萬條在等你。

所以我想問一個不太務實的問題:這個行業什麼時候才會有抗生素。

抗生素真正厲害的地方,在於它打的不是菌株,是作用機轉。青黴素不是為了金黃色葡萄球菌設計的,它擋的是細胞壁的合成,於是所有靠那個機轉活下去的東西一起中招。一個藥,對付的是一整類。

資安有沒有這種東西?個案有將近五萬,但弱點的類型呢。

所以我跑了一個小實驗

用的是公開資料,沒有碰任何公司的內部資料。

方法:抓取社群重建的 NVD JSON 資料集裡,所有編號為 CVE-2025 的紀錄,讀出每一筆的 weaknesses 欄位,統計 CWE 的分布。抓取時間是 2026 年 9 月 16 日。

母體:抓到 44,353 筆。其中公布日期落在 2025 年、而且沒有被撤回的,是 37,475 筆。

結果:
https://ithelp.ithome.com.tw/upload/images/20260929/20169113InvPa5ym6u.jpg

三萬七千個個案,落在五百四十種類型上。而且分布極度不平均:

https://ithelp.ithome.com.tw/upload/images/20260929/20169113S6zWcXKcMJ.jpg

十種弱點類型,覆蓋掉一半。

前五名是這幾個:跨站腳本(CWE-79)15.8%、SQL 注入(CWE-89)8.1%、注入類的通用父類(CWE-74)5.7%、缺少授權檢查(CWE-862)4.7%、跨站請求偽造(CWE-352)3.8%。

這個實驗不能證明什麼

結果算漂亮,所以更要把限制講完,不然這篇就變成拿數字唬人。

**第一,我抓的母體跟我想講的母體不是同一個。**我抓的是「編號開頭為 2025」的 CVE,不等於「2025 年公布的 CVE」。有些 2025 編號的案子到 2026 年才公布,有些 2025 年公布的案子掛的是 2024 的編號。所以 37,475 這個數字,跟公開報告常引用的四萬八千多,本來就對不起來,差距主要來自這個定義差異。

**第二,CWE 有階層,所以「540 種」是浮動的。**CWE-74 是注入的父類,CWE-79 與 CWE-89 都在它底下;CWE-119 是記憶體邊界問題的父類,CWE-787 越界寫入跟 CWE-125 越界讀取是它的子類。分析師選哪一層,統計就長得不一樣。**把抽象層級往上拉,種類會更少、集中度會更高;往下拉則相反。**所以那條覆蓋率曲線的形狀是真的,刻度不是。

**第三,那 4.1% 沒有 CWE 的案子,不是隨機缺漏。**它們多半是沒有人分析到那一步的,而沒有人分析通常意味著資訊不足,也就是說它們可能系統性地偏向某幾類。

**第四,這個實驗只證明了個案集中在少數類型,完全沒有證明「打類型就有效」。**這中間還差一大段:類型層級的防護是不是真的擋得住,成本多少,以及在韌體與嵌入式的情境下能不能落地。抗生素的類比到這裡就要停,再往下就是我自己想像的了。

但它改變了我要問的問題

實驗跑完,我沒有得到一個新工具,我得到一個新的問法。

以前的問法是:**這條 CVE 我要怎麼處理。**這個問法的成本,跟每年的 CVE 數量一起成長。去年四萬,今年四萬八,明年呢。

新的問法是:我的產品裡,那十種類型各自被什麼擋住。

這個問法會直接撞上 Annex I Part I,而且撞得很準:

https://ithelp.ithome.com.tw/upload/images/20260929/20169113lzL5rv7xaq.jpg

第 (k) 項那一列值得單獨看。編譯選項開起來,不會讓那幾類弱點消失,但會讓它們從「可以穩定利用」變成「不一定打得中」。這是少數投資一次、之後每一條同類型的 CVE 都受益的東西,而它剛好也是 Day 24 那個二進位分析會順手幫你檢查的欄位。

工地把鋼筋綁好,不會讓地震變小,但會決定那棟樓在地震裡的表現。而且鋼筋只綁一次。

交付物:類型層級的盤點表

這張表填一次可以用很久,因為它問的不是今天有哪些 CVE。

https://ithelp.ithome.com.tw/upload/images/20260929/20169113NcChkor3O2.jpg

填寫準則三條:

□ 第三欄只填「有/沒有/部分」,不要填工具名稱。這張表問的是能力,不是採購清單。
□ 第四欄填不出來的,等於第三欄是「沒有」。這一條很傷人,但查廠的邏輯就是這樣。
□ 最後一欄用「一次性」或「持續性」標註,不要填金額。一次性的缺口優先補,因為它補完就不再回來。

想自己重跑這個實驗的話,步驟很短:取一份公開的 NVD 鏡像資料、讀每筆的 weaknesses 欄位、把 CWE- 開頭的值做次數統計、排序後算累積覆蓋率。整段邏輯不到三十行,難的部分在後面,在於怎麼把類型對應回你自己的產品。

明天 Day 30:從救火走向設計

三十天的最後一篇。抗生素是治療,還有另一半沒講完,那一半才是 CRA 真正想要的東西。附全系列索引。

順便問一句。如果你們產品線做一次類型層級的盤點:

你猜第一個空格會出現在哪一列?

(a)記憶體相關那幾列 (b)存取控制那幾列 (c)更新驗證那一列 (d)每一列都會空

留個字母就好。選(d)不丟臉,那代表你認真想過這張表要怎麼填。

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

參考:資料來源為 fkie-cad/nvd-json-data-feeds(社群重建的 NVD JSON 資料集),抓取日期 2026/09/16,母體為編號 CVE-2025 的紀錄 44,353 筆,經公布年份與撤回狀態過濾後 37,475 筆。CWE 清單版本 4.20。Regulation (EU) 2024/2847 Annex I Part I (c)(d)(e)(f)(j)(k)。統計方法與限制如文中所述,類型對應表為個人整理。


上一篇
Day 28|如果只有一個人、三個月,我會照什麼順序做
下一篇
Day 30|從救火走向設計
系列文
時鐘從「知悉」開始:從零打造 PSIRT,三十天走完歐盟 CRA 的通報與 SBOM 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言