GitHub 在 2026 年 10 月 28 日推出 Dependabot alerts 的可達性分析公開預覽，先支援具有 npm、Yarn 或 pnpm lockfile 的 JavaScript 與 TypeScript repository。它會用 CodeQL 建立專案與相依套件的呼叫圖，判斷應用程式是否有路徑呼叫到公告標示的漏洞函式，並在既有警示上加入 verdict 與部分 call-path 證據。

這項功能解決的是「先看哪一個警示」，不是證明漏洞可被利用，也不是替團隊自動關閉風險。相依套件出現在 lockfile，不代表執行時一定呼叫漏洞函式；反過來，靜態分析沒有找到路徑，也不代表套件永久安全。正確用法是把可達性與嚴重度、EPSS、是否在 production、資料敏感度、網路暴露和修補成本一起判斷。

四種 verdict 各自代表什麼

GitHub 的發布公告列出四種結果。Reachable 代表找到至少一條從專案程式到漏洞函式的呼叫路徑；Potentially reachable 代表分析無法排除可達，官方建議與 reachable 一樣優先處理；Unreachable 代表本次分析完成但沒找到路徑，可降低優先級；Reachability unavailable 則是未支援、失敗或逾時，應回到原本的漏洞分類方式。

GitHub Docs特別提醒，可達不等於可利用。呼叫路徑存在，但攻擊者可能無法控制輸入、功能不對外或前面已有驗證；不可達也不是可以單靠 verdict 關閉警示的理由，因為程式碼、依賴與 advisory 都會變動。每個結論都是特定 commit 與分析能力下的快照。

因此，工單不要只抄一個綠色或紅色標籤。至少保存 repository、commit SHA、package 與版本、advisory、verdict、call path、部署範圍、外部輸入點、補償控制與重新檢查日期，才能在之後回答當時為何延後或優先修補。

先確認資格與分析邊界，再解讀結果

公開預覽目前適用 GitHub Enterprise Cloud，包括 data residency 版本；官方表示不需 GitHub Code Security 授權，也不會計入該分析使用的 GitHub Actions 分鐘。必須先啟用 Dependabot alerts，reachability 本身預設關閉，可由 enterprise／organization 的 custom security configuration 批次啟用，也可在單一 repository 的 Advanced Security 設定開啟。

分析使用 GitHub-hosted runner，自架 runner 在預覽期間不支援。大型 monorepo、多個 manifest 目錄或複雜程式可能無法完整分析；公告說掃描超過三小時時，部分結果可能顯示 unavailable。第一輪可從數分鐘到數小時，之後在仍有開放警示時每日重跑。若公司政策不允許 GitHub-hosted runner，不能為了取得 verdict 默默繞過政策，而應維持原有 SCA 與人工風險流程。

啟用前也要確認 lockfile 已提交且與正式部署一致。若 Docker build 使用另一個 workspace、production 安裝會忽略 dev dependencies，或正式 artifact 來自不同 commit，分析的 dependency graph 就不一定代表上線內容。單一 repository 同時產出前端、後端與 CLI 時，還應記錄漏洞套件進入哪個 artifact。

用可達性重排工作，不讓低優先等於不處理

第一層處理 reachable 與 potentially reachable。閱讀 call path，找到從路由、queue、檔案解析或排程進入漏洞函式的入口，再判斷攻擊者能否控制參數、需要什麼身分、資料與權限影響。能安全升版時，仍以更新依賴為主；無法立即升版時，先停用路徑、限制輸入、加 WAF 或權限控制只算暫時措施，必須保留到期日。

第二層是 unavailable。它不是低風險，而是缺少訊號。依嚴重度、EPSS、直接或間接依賴、runtime 使用情況與網路暴露進行原本的 triage；若是分析逾時，可拆分 manifest、改善建置或向 GitHub 確認限制，但不要把「工具沒結果」改寫成「沒有影響」。

第三層才是 unreachable。可降低排程優先級，但仍應在正常依賴更新中移除漏洞版本，尤其是套件同時存在其他問題、未維護或未來可能啟用相關功能時。若決定暫緩，設定 30 或 60 天重新檢查，並在新功能、依賴或 advisory 更新時自動重開。

修補驗收不能只看 Dependabot 警示消失

升版前先閱讀上游 release notes 與 breaking changes，保留 lockfile 差異並確認實際解析版本。依 call path 建立針對性測試，涵蓋正常輸入、惡意邊界、錯誤處理與權限；再執行完整單元、整合、建置與 smoke test。若是間接依賴，確認 override 或 resolution 不會造成父套件不相容，也不要只在 package.json 改版本卻漏交 lockfile。

部署後應確認 artifact 真的包含修補版、production 流量沒有新錯誤，並等待 dependency graph 與警示更新。若警示仍存在，檢查是否有第二條依賴路徑或未使用的舊 lockfile。若採補償控制而未升版，警示應保持開放或有可追溯的風險接受記錄，不能為了清空 dashboard 直接 dismiss。

對外包或多團隊專案，可把 SLA 定義為「完成 triage 與交付證據」而不是所有警示使用同一修補天數。例如 reachable 且對外暴露的高嚴重度問題先處理；unavailable 的高嚴重度問題不得被排到 unreachable 之後；unreachable 仍要進入例行更新。每月檢查 verdict 分布、逾時數、平均 triage 時間、過期例外與修補回歸，而不是只追求警示總數下降。

Dependabot 可達性分析的價值，在於把相依套件清單連回實際程式呼叫，讓有限人力先看更可能影響產品的路徑。它能提供新的證據，但不能取代威脅模型、上游修補、測試與部署驗證。把 verdict 當成排序訊號、保存 commit 與判斷依據，才不會從「警示太多」走向另一個錯誤極端：因為工具顯示 unreachable，就把漏洞當作不存在。