那個 Dependabot 自動開的 security PR，到底在修什麼？

如果你的專案放在 GitHub，大概都收過這種通知：某個套件有 security vulnerability，然後系統自動開了一個 PR 要你升級版本。

這就是 Dependabot。很多人的處理方式是——看 CI 有沒有變紅，綠的就 merge，紅的就先放著。

但那個 PR 到底在修什麼？不修會怎樣？是不是每一個都得修？

這篇把這些先講清楚。下一篇再講我們團隊實際怎麼把這件事自動化、導入 Renovate 時踩到什麼。

漏洞通常不在你「自己裝」的套件裡

你的專案不會所有東西都自己寫，會裝一堆別人做好的套件（package）——處理日期的、發 request 的、跑測試的。

這些你自己挑、寫進設定檔的，叫直接依賴（direct dependency）。

但每個套件自己也會用到別的套件。那些被間接帶進來、你根本沒主動裝、甚至沒聽過的，叫傳遞依賴（transitive dependency）。

一個中型前端專案，直接依賴可能幾十個，傳遞依賴常常數百上千個。

關鍵在這：大多數漏洞 alert，出在傳遞依賴。也就是你沒挑、不知道存在的那一堆。

而傳遞依賴麻煩在它不能直接升——版本是上層套件決定的，上層往往還鎖死了舊版。所以「升一下不就好了」這句話，對傳遞依賴常常不成立。

CVE、GHSA、OSV：漏洞是怎麼被「登記」的

當有人發現某個套件的某個版本有漏洞，會走一套公開流程把它記錄下來。你在 alert 裡看到的那幾個縮寫，就是這套流程的產物。

CVE（Common Vulnerabilities and Exposures）是每個公開漏洞的全球唯一編號，長得像 CVE-2025-12345。它本身只是「編號 + 一段描述」，是大家在講同一個漏洞時的共同語言。

GHSA（GitHub Security Advisory）是 GitHub 自己維護的漏洞資料庫。Dependabot 的情報主要來自這裡。

OSV（Open Source Vulnerabilities）是 Google 發起的開放漏洞資料庫，跨多個語言生態系彙整。

為什麼要認得這三個名詞——因為工具能不能幫你自動發現、自動修一個漏洞，取決於那個漏洞有沒有被登進這些資料庫，以及你用的語言被收錄得夠不夠多。等一下選工具會用到這件事。

alert 來了，要馬上全部修嗎

不用。這是最反直覺、但最重要的一點。

「有 CVE」不代表「你會被攻擊到」。漏洞通常藏在某個函式裡，而那個函式很可能根本不在你程式的執行路徑上（業界講的 unreachable）。很多有漏洞的套件甚至只在 build / test 階段用到，不會被打包進上線的程式。

而且升級本身有風險。一次跨大版的升級可能直接弄壞功能，風險有時比那個漏洞還高。

所以一筆 alert 進來，值得先看這幾件事：

這套件是上線會跑到的，還是只在開發 / 測試用？
有漏洞的那段功能，我們到底有沒有在用？
這個服務對外嗎？公開網站、會吃使用者輸入 → 風險高；內部後台 → 低。
有沒有修復版？沒有的話，評估後接受並記錄，不硬修。

心態是：工具負責「看見」跟「排出輕重」，要不要修是人的判斷。這點下一篇會用實際數字講得更細。

但有一種漏洞要特別當心

上面說「多數沒那麼急」，有個重要的例外。

前面講的低風險，前提是漏洞「要被你的程式呼叫到才會發作」。但有一類套件根本不等你呼叫——它在 npm install 的當下，或在 CI 跑的時候，就會執行自己的安裝腳本。

如果一個套件被植入惡意程式碼（這叫供應鏈攻擊，supply chain attack），它可以在安裝那一刻就跑起來：偷走環境變數裡的 token、把 CI 的金鑰外傳、在你打包出來的程式裡塞後門。這種風險不管你「有沒有用到它」，只要它出現在依賴樹裡、被裝起來，就成立。

所以判斷一筆 alert，除了看嚴重度，也要看「是哪一種」。一個只在測試用、又要被呼叫到才會出事的漏洞，可以緩；一個會在安裝期執行的惡意套件，要往前排。

升級套件，跟修漏洞，是兩件事

這兩件事常被混在一起，動機卻完全不同。

一個是版本更新：把套件保持在最新版，拿新功能、效能、bug 修正。這件事沒有止境，今天升完明天又有新版。

一個是修漏洞：只在某個版本被揭露安全問題時，把它升到安全版。

你完全可以選擇「只做後者」。一直追每個套件的最新版，只會製造一堆沒必要的改動跟風險。我們後來導入工具時就是這樣選的——平常不主動升版，只在有漏洞時才動。怎麼設定留到下一篇。

把這件事自動化：Dependabot 與 Renovate

逐筆手動判斷、開 PR、本機驗證，每來一波重跑一次，很快就煩了。所以會想自動化。

Dependabot 是 GitHub 內建的，免費、開箱即用，會自動偵測漏洞、自動開升級 PR。對「升級你直接裝的套件」很好用。

但它有些做不到的事——例如不太能處理傳遞依賴的修法、設定彈性有限。這部分牽涉比較多實作細節，留到下一篇。

Renovate 是另一個工具，背後是 Mend 這家公司在維護，做的事類似，但設定彈性大很多，也比較能處理傳遞依賴。它本身是 open source 的。

Renovate 怎麼跑起來：託管 vs 自架

Renovate 有兩種跑法，差別只在「誰來執行那個掃描」。

託管（hosted）：你到 GitHub 裝一個官方的 App，授權它讀你的 repo，之後掃描、開 PR 全部交給 Mend 的雲端。零維運，裝完就動。代價是你授權了一個外部雲端服務，對你的程式碼有讀、甚至寫的權限。如果是公司的私有 repo，這通常要先過資安、甚至法務那關。

自架（self-hosted）：用官方提供的 GitHub Action 或 Docker image，跑在你自己的機器或 CI runner 上，排程觸發。設定檔跟託管版一模一樣，只差執行的地方。好處是程式碼完全不出自家環境；代價是要自己顧排程、token 跟版本更新。

那要錢嗎

Renovate 本身免費（open source）。Mend 提供的託管 App，不管公開還是私有 repo，也是免費。

所以對多數團隊，費用根本不是決策點。真正要拍板的是前面那個問題：要不要讓一個第三方雲端讀你的私有原始碼。不想，就走自架。這也是為什麼 Renovate 特地留了自架這條路。

小結

你收到的依賴漏洞 PR，多數修的是傳遞依賴——你沒主動裝、也不能直接升的那些。
CVE 是漏洞編號；GHSA / OSV 是情報資料庫，決定工具在你的語言裡修不修得動。
不用每個 alert 都修。有 CVE 不等於你被打得到，先分輕重。
但有例外：會在安裝期執行的供應鏈惡意套件，不管你用不用得到都危險，要優先處理。
Dependabot 免費內建；Renovate 更彈性，可託管（零維運、但要授權第三方）或自架（程式碼不出門、但要自己顧），本身免費。

下一篇講我們實際把 Renovate 導入公司前端站、再擴散到後端與 iOS 的過程：怎麼設定成「只修漏洞、人工合併」、一次面對上百筆 alert 我們決定不全修的理由，以及 Renovate 自己也修不到的那些坑。

→ Part 2：從 Dependabot 換到 Renovate，為什麼我不把漏洞修完