Original Sin of npm 論文閱讀分析：很多 JavaScript 供應鏈真正危險的，不是你今天又裝了哪個新套件，而是那幾個老洞早就沿著 dependency graph 長成整片陰影

本文由 AI 產生、整理與撰寫。

談 JavaScript 安全時，大家很容易把注意力放在「這個新套件有沒有惡意程式碼」、「這次又是哪個 maintainer 帳號被偷」，但這篇 Original Sin of npm: A Study on Vulnerability Propagation in JavaScript Dependency Networks 提醒了一件更麻煩的事：真正把風險放大的，往往不是最新那顆爆點，而是少數幾個早就存在、卻被整個 npm 生態反覆繼承、反覆擴散的老弱點。

• 論文標題：Original Sin of npm: A Study on Vulnerability Propagation in JavaScript Dependency Networks
• 作者：Muhammad Ejaz Ahmed、Aliya Tabassum、Samia Kabir、Tansu Alpcan
• 來源：arXiv:2604.17668（2026） / ACM AsiaCCS 2026
• 研究類型：software supply chain security / dependency network analysis / vulnerability propagation

這篇論文在問什麼？

作者想回答的核心問題很直接：npm 裡的已知漏洞，究竟是零星散落，還是會透過 dependency network 被少數套件持續放大？ 這不是純學術問題，因為現在很多團隊根本不直接碰到 vulnerable code 本體，而是透過一層又一層 transitive dependency，把風險默默帶進 production。

也就是說，真正該怕的未必是你明確安裝了某個有洞套件，而是：

• 你的 direct dependency 依賴了它
• 而那個 dependency 又依賴了另一個老套件
• 最後整條依賴鏈把一個早已公開的弱點默默帶到你的 build 裡

這篇研究最有價值的地方，在於它不是停在「有很多漏洞」這種老生常談，而是把問題拉到 propagation structure：漏洞到底是怎麼沿著 JavaScript 生態裡的 dependency graph 傳染開來的？

資料規模夠大，看到的也不只是個案

作者建立了一個自製漏洞資料庫，涵蓋 1,077,946 個 JavaScript packages 與對應 dependency networks，並整理出 1,515 個已回報漏洞。這個規模夠大，所以研究看見的不是某幾個知名事故，而是整個 npm 生態的結構性分布。

幾個最值得記的數字很刺眼：

• 61.30% 的 packages 依賴至少一個 dependency package
• 21.60% 的全部 packages，在其 dependency network 中至少帶有一個已知漏洞
• 這些受影響案例裡，最多的是 High severity（42%）
• 從第一個 vulnerable version 上線到真正修掉，平均要花 4 年 11 個月
• 而漏洞公開時間通常只比修補版本晚約 19 天

這組數字合起來的意思很殘酷：很多套件不是「一度有洞」，而是長時間有洞；而且這些洞不是孤立待在原套件裡，而是透過依賴關係被大量下游專案一起繼承。

最該注意的，不是平均分布，而是高度集中

如果漏洞在 dependency graph 裡是平均散布的，事情反而單純，因為你只要做廣泛掃描與持續更新就行。但這篇的關鍵發現不是平均，而是高度集中：

• 最常出現的 前 7 個漏洞，就佔了 25% 的 vulnerability cases
• 前 23 個漏洞，就佔了 50% 的 cases

這非常像供應鏈版本的 Pareto phenomenon。意思不是 npm 有很多不同洞，而是有一小撮洞，因為卡在生態關鍵節點上，所以被整個網路重複放大。 這也是我覺得作者把論文叫做 Original Sin 很準的原因：很多下游專案今天承受的風險，不是自己剛犯的新錯，而是上游某個很早以前的錯，至今還在整個生態裡投影。

這篇真正改變的是你看供應鏈風險的角度

很多漏洞管理流程還是偏 asset-centric：先問「我用了哪些套件」、「它們各自有沒有 CVE」。這樣做當然沒錯，但不夠。這篇更像是在說：你不能只看 package inventory，還要看 propagation topology。

原因很簡單。同樣一顆漏洞，放在冷門套件裡和放在生態核心節點裡，後果完全不同。真正高風險的，不一定是 CVSS 最高的那顆，而可能是那顆最容易沿著大量 dependency path 被重複繼承、最難一起清乾淨的那顆。

這點對 AppSec、SCA 與平台團隊都很重要，因為它把 prioritization 問題從「這個洞本身多嚴重」往前推成「這個洞在網路裡會傳多遠、卡多久、拖住多少下游」。

另一個很不舒服的訊號：修得慢，公開得快

我覺得論文裡最不舒服的一組結論，是平均要 4 年 11 個月才真正修掉，但漏洞資訊公開通常只比 fix 晚 19 天左右。這代表什麼？代表很多生態系不是沒有 remediation signal，而是有訊號，但 remediation 並沒有沿著供應鏈有效擴散。

換句話說，問題不只是 disclosure，也不只是 patch availability，而是：

• 誰知道自己被影響
• 誰有能力升版
• 誰敢升版
• 誰願意承擔相依套件更新帶來的 breaking risk

這讓 npm 式供應鏈風險看起來更像一個 ecosystem coordination problem，而不只是單點修補問題。

對實務團隊最有用的啟發是什麼？

如果把這篇翻成實務語言，我會帶走幾個很直接的結論：

• 第一，不要只看 direct dependencies。 很多實際風險根本活在 transitive layers。
• 第二，漏洞優先級不能只看 severity，還要看 propagation centrality。
• 第三，少數高頻弱點值得被當成 ecosystem-level chronic risk 追蹤，而不是一次性修補事件。
• 第四，SCA 工具若只列 CVE 清單、不幫你看 dependency network 裡的放大效應，其實還只做了一半。

這些觀察也很適合跟近年的 AI-assisted AppSec 結合起來看。未來比較有價值的 AI 漏洞治理工具，未必只是替你摘要 advisory 或自動開 PR，而是能夠更早指出：哪幾顆上游弱點正透過 dependency graph 形成 disproportionate downstream risk。

限制也要看清楚

當然，這篇不是沒有邊界。它聚焦的是 npm / JavaScript 生態，資料來源與漏洞辨識流程也建立在特定公開資料基礎上，所以不能直接假設所有語言生態都會長得一模一樣。再來，依賴鏈上「存在已知漏洞」不等於每個下游專案都一樣容易被 exploit，真正風險還會受 runtime reachability、部署方式與版本約束影響。

但即便如此，這篇的價值仍然很高，因為它把供應鏈安全從單點列舉拉回網路結構。這是很多團隊平常最容易看漏的地方。

總結

Original Sin of npm 最值得看的，不是它再次證明 open-source 供應鏈很多洞，而是它更清楚地說明：真正讓風險失控的，常常不是洞的總數，而是少數高影響上游弱點如何沿著 dependency graph 被整個生態反覆繼承。

如果你把這篇的訊號記住，JavaScript 供應鏈治理的優先順序就會開始變：不是先問「今天又多了幾個 CVE」，而是先問「哪幾顆老洞還卡在網路核心，直到今天都還在替整個生態持續製造新受害者？」