TL;DR
弱掃的目的，不是把報告數字壓到零，而是盡快知道系統裡有哪些已知漏洞、它們來自哪裡、哪些真的需要優先處理。用 Trivy 這類工具，可以很快掃 Docker image、作業系統套件、語言套件，甚至 repo 設定與 secret。重點不是只會跑指令，而是要先分清楚：問題來自你的應用程式，還是來自 base image / 工具鏈。
弱掃到底是在做什麼
所謂弱點掃描，通常是拿你系統裡已安裝的元件去比對已知漏洞資料庫，看看目前版本是否命中已公開的 CVE 或安全公告。
在開發場景裡，常見被掃的對象包括：
- 作業系統套件，例如 Alpine、Debian、Ubuntu 裡安裝的 package
- 應用程式依賴，例如 npm、pip、Maven、Go modules
- Container image
- IaC / 設定檔，例如 Dockerfile、Terraform、Kubernetes manifest
- Secret，例如不小心放進 repo 的 token 或 key
所以弱掃不是只在看「你寫的 code 有沒有 bug」，而是在看你整個交付物裡有哪些已知風險元件。
為什麼工程團隊要做弱掃
原因其實很務實。
第一，很多漏洞不是你自己寫出來的，而是來自第三方套件或 base image。
第二，現代系統很依賴開源元件，不掃基本上很難知道自己到底帶了什麼進 production。
第三，弱掃能讓修補工作更有順序，而不是看到安全議題就一律大升版。
弱掃最有價值的地方，不是「有報表」，而是它幫你回答這幾個問題：
- 這個風險在哪裡？
- 是哪個元件帶進來的？
- 它是 direct dependency 還是 transitive dependency？
- 它是不是其實來自 base image？
- 這個風險現在需不需要立刻處理？
常見誤解
1. 弱掃有紅字，代表一定是我 app 的問題
不一定。
以 Docker image 為例，掃描工具通常會掃整個 image filesystem，不只你的 app 目錄。也就是說，掃到的弱點可能來自：
- 你的 app dependency
- base image 的 OS package
- base image 內建工具鏈，例如 npm、python、java runtime
所以同樣看到 tar、openssl、glibc 之類的套件，不代表一定是你在 package.json 或 requirements.txt 裡裝的。
2. 弱掃數量一定要歸零
理想上很好，但實務上不一定。
有些弱點：
- 在你的執行路徑裡根本用不到
- 上游尚未釋出修補版本
- 需要大版本升級，風險比漏洞本身還大
- 只是 build-time tool，不會進 runtime
所以弱掃更像是風險管理，不是單純的數字遊戲。
3. 升 app 套件就能解掉所有問題
也不一定。
有些漏洞根本在 base image 或工具鏈本身。例如 Node.js image 裡常見的情況是：專案套件已升級，但 image 內建的 npm 仍帶著舊版 tar、glob、minimatch，這時候要改的是 Dockerfile，不是只改 package.json。
Trivy 是什麼
Trivy 是 Aqua Security 推出的安全掃描工具，特色是：
- 安裝簡單
- 支援多種掃描目標
- CLI 好上手
- 很適合先導入開發流程或 CI
Trivy 常見用途有幾種：
- 掃 container image
- 掃檔案系統 / 專案目錄
- 掃 repo 設定問題
- 掃 secret
- 掃 SBOM
如果你的目標是先快速建立團隊的基本弱掃能力，Trivy 是一個很好起點。
Trivy 可以掃什麼
掃 image
這是最常見的用法：
trivy image node:22-alpine或掃自己 build 出來的 image：
trivy image your-app:latest這種模式通常會看到兩大類結果：
- OS packages
- Language packages
掃專案目錄
如果你想先看 repo 內的依賴問題，可以直接掃檔案系統：
trivy fs .這對還沒打包成 image 的專案很方便，能先從 lockfile 與 dependency manifest 看問題。
掃 secret
trivy fs --scanners secret .這能幫你找 repo 裡疑似憑證、token、private key 的內容。
掃設定問題
trivy config .這類掃描比較偏 misconfiguration，像是 Dockerfile、Terraform、Kubernetes manifest 的不安全設定。
一開始怎麼看 Trivy 結果
剛開始看 Trivy 報告，很多人會先被數量嚇到。比較有用的方式是先分三件事。
先看掃到的是哪一層
先分清楚：
- 是 OS package？
- 是 app dependency？
- 還是工具鏈自己的 dependency？
這一步非常重要，因為它直接決定你要改哪裡：
- 改 base image
- 改
Dockerfile - 改
package.json/ lockfile - 或暫時接受風險
再看嚴重度
通常會看到像 LOW、MEDIUM、HIGH、CRITICAL。
但不要只看嚴重度，還要一起看：
- 套件是否真的存在於 runtime
- 是否有 fixed version
- 你的系統有沒有實際使用到那條路徑
最後看有沒有修法
Trivy 常會直接列出 fixed version。這時候可以先問：
- 是不是只要升 patch version 就好？
- 會不會牽涉 major upgrade？
- 是 direct dependency 還是 transitive dependency？
- 要改 app，還是改 image？
一個實務上很好用的判斷方法
如果你掃的是 Docker image，我很建議固定用這個順序：
- 先看 image report 裡的 package name、installed version、fixed version
- 回頭查 app 依賴樹，看專案是否真的裝了它
- 如果 app 依賴樹對不上，就進容器查 base image 內建工具鏈
- 確認來源後，再決定要升 app 套件還是升 base image / npm / 其他工具鏈
這個流程的好處是，你不會一看到 npm 生態系的套件名稱，就直覺去改 package.json。
Trivy 的導入建議
如果團隊剛開始導入，不用一開始就做得很重。可以先從這幾步開始：
1. 先掃 image
因為 image 最接近實際部署物，結果也最有參考價值。
2. 先聚焦 HIGH / CRITICAL
不要一開始就想清光全部 LOW / MEDIUM，不然團隊很容易疲乏。
3. 先建立分類習慣
每次看到弱點，先標記它屬於：
- app dependency
- base image
- toolchain
- config
- secret
這會比單純列清單更容易追。
4. 放進 CI，但先用提醒模式
一開始可以先讓 Trivy 在 CI 裡出報告，不一定馬上 fail build。等團隊比較熟悉結果，再逐步收緊門檻。
結語
弱掃最難的地方，通常不是「怎麼跑工具」，而是「怎麼讀結果」。Trivy 很適合拿來建立這個基本功：先知道有哪些風險，再學會判斷來源，最後才決定修法。只要把「app 套件」和「base image / 工具鏈」分開看，很多原本看起來很混亂的報告，其實很快就能釐清。