OSV-Scanner：dependency security 不是後期治理，而是持續累積的技術債掃描流程

這篇 Threads 提到 Google 的 OSV-Scanner，核心觀念很重要：dependency security 不是專案後期才處理的治理問題，而是一筆每天都在累積的技術債。

每多裝一個 package、每多拉一層 transitive dependency，開發速度可能變快，但也把更多未知漏洞帶進專案。最麻煩的不是你知道有風險，而是你通常不知道風險藏在哪一層。

OSV-Scanner 的價值是把這件事拉回可執行流程。根據 README，它是 OSV.dev 的官方支援 frontend，並基於 OSV-Scalibr，能把專案 dependencies 與漏洞資料連起來。

OSV-Scanner 掃描範圍

官方列出的支援範圍包括：

C/C++、Dart、Elixir、Go、Java、JavaScript、PHP、Python、R、Ruby、Rust
npm、pip、yarn、maven、go modules、cargo、gem、composer、nuget 等 package managers
Linux OS packages
container images
vendored C/C++ code
lockfiles 與 source directory

它也支援 container image scanning，可以掃 base image 與內含 package；也支援 offline scanning，先下載本地 OSV database 後離線掃描。

不只是找漏洞，而是走向 remediation

Threads 提到的重點也很準：OSV-Scanner 不只告訴你「有洞」，還開始往 guided remediation 走。README 裡提到，它能依 dependency depth、minimum severity、fix strategy、return on investment 等條件，建議 package version upgrade。

這代表 dependency security 的成熟方向，不只是 vulnerability lookup，而是：

找到漏洞
判斷是否真的影響專案
決定升級路徑
降低修復破壞性
將掃描放進 CI / release workflow

我的判斷

這篇最值得保留的觀念是：dependency security 應該前移到日常開發流程，而不是等 audit 或事故後才補。

對 BigIntTech 的專案來說，OSV-Scanner 適合放在幾個位置：

CI 定期掃描 lockfile / source directory
release 前掃 container image
大版本升級前檢查 transitive dependency
第三方專案接手前做 baseline security scan
與 Dependabot / Renovate / GitLab dependency scanning 互補

但 guided remediation 也要小心：在不可信專案上跑 fix 可能觸發 package manager scripts 或外部 registry 行為，應該在受控環境執行。

來源：