從 Docker Scout 到 Trivy、Grype：常見容器映像檔掃描工具操作與比較

容器映像檔掃描已經不是什麼新議題，但它一直是 DevSecOps、Container Security、Software Supply Chain Security 裡面最容易落地、最常發現一堆 CVE 漏洞的一個環節。不過它也是最容易被誤解的，雖然容器容器映像檔掃描，大部分都ˊ關注於找出有套件漏洞的CVE，不過其實一些掃描器也是有功能是找出其他安全設定的問題，例如 Dockerfile 或 image configuration 是否有一些不好的安全問題？還有這些掃描工具，其實也有很多的參數可以調整掃描設定，或是可以提供修補建議。

這篇文章是一篇容器映像檔掃描工具的介紹，但一些內也會用比較實務的角度，來分享一些看法。今天會介紹的為目前主流常見的容器映像檔掃描工具，包含 Docker Scout、Snyk Container、JFrog Xray，以及幾個常見開源的 Trivy、Grype、Dockle。重點不是要說哪一個工具最好，而是說明它們各自適合的場景、操作方式，以及在實務導入注意的地方。

這篇文章會示範哪些工具？

我這次選擇的工具分成兩大類。

第一類是比較偏平台或商業方案的工具，包含 Docker Scout、Snyk Container 與 JFrog Xray。這類工具通常不只是掃描 CLI，而是包含帳號、Dashboard、團隊協作、政策控管、CI/CD 或 registry 整合等能力。

第一個 Docker Scout 毫無疑問是今天要介紹的重點。Docker Scout 是 Docker 自家的供應鏈安全分析平台，可以透過 Docker Desktop、Docker CLI、Docker Hub 與 Docker Scout Dashboard 使用；它會分析 image 產生 SBOM，並與持續更新的漏洞資料進行比對。
Snyk Container 則是 Snyk 平台中的容器掃描能力，可以透過 CLI 掃描本機或 registry image，也可以把結果 monitor 到 Snyk 平台持續追蹤。
JFrog Xray 則比較常出現在已經使用 Artifactory / JFrog Platform 的企業環境，透過 JFrog CLI 可以對 Docker image 執行 Xray 掃描。

第二類是開源工具，包含 Trivy、Grype、Dockle。

Trivy 是目前非常常見的開源雲原生安全掃描工具，可以掃 container image、filesystem、Git repository、Kubernetes 等目標，對 image 也可以檢查 vulnerabilities、misconfigurations、secrets、licenses。
Grype 是 Anchore 維護的開源漏洞掃描工具，適合掃 container images、filesystems 與 SBOM，也常與 Syft 組成 SBOM-first 的分析流程。
Dockle 則比較不一樣，它不是典型只看 CVE 的掃描器，而是 Container Image Linter，會從 CIS Benchmark 與 image best practice 的角度提醒 Dockerfile/image 的安全問題，例如是否使用 root、是否清除 apt cache、是否疑似放入敏感檔案等。

另外還有一個很有名的開源專案叫 Clair 。但我這篇沒有把 Clair 放進上面兩大類，是因為 Clair 比較像 registry 後端與持續分析服務，常見於 Quay/registry 整合情境；今天方向比較像是能快速安裝、快速執行的本機 CLI 工具，Trivy、Grype、Dockle 會更適合。

前置準備：不安全的 Image

為了讓每個工具的結果比較容易觀察，我們先準備一個刻意不太理想的 image。這個 image 使用比較舊的 Node.js base image，而且 Dockerfile 裡面也故意沒有清除 apt cache，也沒有建立非 root 使用者。請注意，這是示範用，不是建議你在正式環境這樣寫。

先建立一個資料夾：

mkdir image-scan-demo
cd image-scan-demo

建立一個故意不太好的 Dockerfile：

cat > Dockerfile.bad <<'EOF'
FROM python:3.9-slim-bullseye

WORKDIR /app

RUN apt-get update && apt-get install -y curl

CMD ["python", "--version"]
EOFCode language: JavaScript (javascript)

建置 image：

docker build -f Dockerfile.bad -t image-scan-demo:bad .Code language: CSS (css)

接著準備一個相對比較好的版本。這個版本改用較新的 Node.js base image，安裝套件時使用 --no-install-recommends，並且清除 apt cache，最後建立非 root 使用者執行。

cat > Dockerfile.good <<'EOF'
FROM python:3.12-slim-bookworm

WORKDIR /app

RUN apt-get update \
    && apt-get install -y --no-install-recommends curl ca-certificates \
    && rm -rf /var/lib/apt/lists/*

RUN useradd -r -u 10001 appuser
USER appuser

CMD ["python", "--version"]
EOFCode language: JavaScript (javascript)

建置修正版 image：

docker build -f Dockerfile.good -t image-scan-demo:good .Code language: CSS (css)

後面每個工具都會盡量掃描同一組 image，這樣比較容易看出差異。不過實務上也要提醒，掃描結果會受到工具資料庫、image tag 更新、平台架構、漏洞資料來源、掃描時間點影響，所以不要只拿「漏洞數量」直接判斷哪個工具比較好。

Docker Scout：Docker 原生整合的 image 分析與修補建議

Docker Scout 最大的特色是它和 Docker 生態系整合得很自然。如果你本來就使用 Docker Desktop，通常不需要另外安裝 CLI plugin；Docker 官方文件也說明 Docker Scout CLI plugin 已經預先安裝在 Docker Desktop 裡，如果只使用 Docker Engine 而沒有 Docker Desktop，才需要額外安裝 standalone binary。

Docker Scout 的定位不只是「列出 CVE」。它可以做 quickview、CVE 詳細列表、base image 更新建議、SBOM 產出、image 比較，以及 policy evaluation。官方 CLI reference 裡也列出 quickview、cves、recommendations、sbom、compare、policy 等指令。

安裝與確認版本

如果你使用 Docker Desktop，可以先直接確認：

docker scout version

如果你的環境是純 Docker Engine，可以使用官方安裝方式：
（總之，只要上面指令顯示沒有 Scout，就用以下的指令來安裝就好）

curl -fsSL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh -o install-scout.sh
sh install-scout.shCode language: JavaScript (javascript)

另外 Docker 官方也有提醒，執行從網路下載的安裝腳本前，應該先檢查腳本內容並理解風險。這點我覺得很重要，因為安全工具本身也會變成供應鏈攻擊目標。

接著如果我們直接去掃描剛剛的image，會出現以下的提醒：

就是跟你說，要登入的意思啦～雖然 Docker Scout 可以免費使用，但是必須要登入才行。

所以我們就先登入 Docker 帳號：

docker login

如果你是用 Docker Desktop 的話，在 GUI 的地方登入之後就可以了。

快速查看 image 風險摘要

登入成功後我們可以用以下指令對剛剛建立的 image 做 quickview：

docker scout quickview image-scan-demo:badCode language: CSS (css)

quickview 會用很快速的方式呈現 image 的漏洞摘要，也會顯示 base image 相關的資訊；如果有可用的 base image refresh 或 update 建議，也可能會在結果中看到。Docker 官方說明 quickview 是用來快速檢視 image 漏洞摘要與 base image 建議的指令。

如果要看比較完整的 CVE 列表，可以使用：

docker scout cves image-scan-demo:badCode language: CSS (css)

內容會超級長～如果想只看 High 與 Critical 等級的話：

docker scout cves --only-severity high,critical image-scan-demo:badCode language: CSS (css)

如果想輸出 JSON 或 SARIF，可以先查看目前版本支援的格式：

docker scout cves --help

實務上，如果你要把結果丟進其他工具或 CI/CD 系統，我會建議優先考慮 SARIF 或 JSON，因為比較容易被平台解析。

查看修補建議

Docker Scout 比較實用的一點，是它會嘗試提供 base image 更新或替換建議。這對開發團隊很有幫助，因為很多時候 image 裡面的漏洞不是你自己安裝的套件造成，而是來自 base image。

docker scout recommendations image-scan-demo:badCode language: CSS (css)

這類建議不一定可以直接照單全收，因為換 base image 可能會影響 runtime、glibc/musl、套件版本、檔案路徑或相容性。但它至少可以幫你快速回答一個問題：「我應該從哪個 base image 開始修？」

產生 SBOM

SBOM 是 Software Bill of Materials，可以把 image 裡面的套件組成列出來。Docker Scout 的 sbom 指令可以針對 software artifact 產生 SBOM，官方文件也說明 SBOM 會列出 image 中的 packages。

例如輸出 SPDX 格式：

docker scout sbom --format spdx -o scout-sbom.spdx.json image-scan-demo:badCode language: CSS (css)

也可以直接查看：

docker scout sbom image-scan-demo:badCode language: CSS (css)

比較修補前後 image 差異

Docker Scout 還有一個功能是可以把「修補前」和「修補後」的差異用比較直覺的方式呈現。

docker scout compare image-scan-demo:bad --to image-scan-demo:good --ignore-unchangedCode language: CSS (css)

docker scout compare 的用途是比較兩個 image 的分析結果，官方也特別提到它適合用在比較同一個 image 的不同版本，例如新建置版本與 production 目前執行版本。它還有一個 Aliases 是 docker scout diff。

如果還想了解更多 docker scout 的指令，也可以查看官方文件。

https://docs.docker.com/reference/cli/docker/scout/compare

本機掃描與平台掃描的差別

Docker Scout 有一個實務上很重要的差別：如果你只是用 CLI 或 Docker Desktop 做一次性的 local analysis，Docker Scout 不會儲存你的 image 資料；但如果你啟用 repository image analysis，Docker Scout 會保存 image metadata snapshot，當新的漏洞資料出現時，可以重新評估安全狀態，而不需要重新分析整個 image。

這代表它比較適合兩種情境：第一種是開發者本機快速檢查；第二種是團隊把 Docker Hub 或第三方 registry 接上 Docker Scout，讓 image 被持續追蹤。前者偏個人與開發體驗，後者偏團隊治理。

Snyk Container：開發者導向的商業掃描平台

Snyk Container 比較像是「開發者安全平台」的一部分，而不是單一容器工具。它的優勢通常不只在 CLI，而是在於它可以把容器 image、開源套件、程式碼、IaC 等風險放在同一個平台裡管理。Snyk 官方文件說明，Snyk Container CLI 可以用來在本機找出並修復 container images 的漏洞。

如果團隊已經在用 Snyk 做 SCA 或 IaC 掃描，那加入 container scanning 會很自然。但如果你只是想要一個完全離線、無帳號、單機使用的工具，那 Trivy 或 Grype 通常會更輕量。

安裝與登入

Snyk CLI 可以用 npm、Homebrew、Scoop、standalone binary 或 Docker image 安裝；官方文件也提醒，安裝後需要 authenticate 才能開始使用。

使用 npm 安裝：

npm install -g snyk

或使用 Homebrew：

brew tap snyk/tap
brew install snyk

確認版本：

snyk --version

登入：

snyk auth

Snyk 官方建議本機 CLI 使用 OAuth 2.0 驗證；CI/CD 情境則常使用 SNYK_TOKEN 環境變數。

掃描 container image

基本掃描：

snyk container test image-scan-demo:badCode language: CSS (css)

如果你有 Dockerfile，建議把 Dockerfile 一起提供給 Snyk。官方文件說明，指定 Dockerfile 可以提供更多上下文，讓 Snyk 給出更清楚的修補建議。

snyk container test image-scan-demo:bad --file=Dockerfile.bad

只看高風險以上：

snyk container test image-scan-demo:bad \
  --file=Dockerfile.bad \
  --severity-threshold=high

輸出 JSON：

snyk container test image-scan-demo:bad \
  --file=Dockerfile.bad \
  --json > snyk-container-report.json

Snyk Container 也支援一些實務上很好用的選項，例如 --exclude-base-image-vulns 可以排除只由 base image 引入的 OS package vulnerabilities，--sarif 可以輸出 SARIF，--fail-on 與 --severity-threshold 則常用在 CI/CD gate。

例如只看非 base image 引入的問題：

snyk container test image-scan-demo:bad \
  --file=Dockerfile.bad \
  --exclude-base-image-vulns

持續監控 image

Snyk 的 container monitor 會建立 image snapshot，並送到 Snyk 平台持續監控。官方說明這個 command 會擷取 image layers 與 dependencies，並監控該 snapshot 的漏洞狀態。

snyk container monitor image-scan-demo:bad --file=Dockerfile.bad

這類功能適合團隊使用，因為它可以讓 image 在未重新建置的情況下，因為新的 CVE 被揭露而重新被標示風險。但缺點也很明顯：你需要帳號、平台與權限管理，而且很多進階治理能力通常會跟付費方案有關。

JFrog Xray：適合已經使用 Artifactory 的企業供應鏈掃描

JFrog Xray 比較不是「我今天裝一個 CLI 來掃 image」的工具，而是更適合已經有 JFrog Platform / Artifactory 的企業。它的價值在於 artifact repository、build-info、policy、watch、license、vulnerability scanning 可以被整合到同一個軟體交付流程裡。

JFrog 官方文件說明，jf docker scan 可以掃描本機建置的 image，而且 image 不需要先 push 到 Artifactory；但前提是 JFrog Platform 上需要設定 Xray。另外，JFrog 說明本機 image 掃描不是把完整 Docker image 上傳到 server，而是採用 hybrid scan process。

安裝 JFrog CLI

macOS 或 Linux 桌面環境可以用 Homebrew：

brew install jfrog-cli
jf --version

CI/CD 或自動化環境可以使用官方 curl 安裝方式：

curl -fL https://install-cli.jfrog.io | sh
jf --versionCode language: JavaScript (javascript)

JFrog 官方建議不要在同一台機器混用多種安裝方法，因為不同安裝來源可能讓 PATH 指到不同版本；安裝後可以用 which jf 與 jf --version 確認。

設定 JFrog server

以下指令需要替換成你的 JFrog Platform URL 與 token：

jf config add my-jfrog \
  --url=https://<your-company>.jfrog.io \
  --access-token=<your-token> \
  --interactive=falseCode language: JavaScript (javascript)

確認設定：

jf config show

掃描 Docker image

基本掃描：

jf docker scan image-scan-demo:bad --server-id=my-jfrog

如果你的組織已經在 Xray 裡建立 Watch，可以指定 watch：

jf docker scan image-scan-demo:bad \
  --server-id=my-jfrog \
  --watches=<watch-name>Code language: HTML, XML (xml)

輸出 JSON：

jf docker scan image-scan-demo:bad \
  --server-id=my-jfrog \
  --format=json > jfrog-xray-report.json

JFrog CLI command summary 也列出 jf docker scan my-image:tag --watches=watch-name 這類用法。實務上我會把 JFrog Xray 放在比較成熟的企業流程裡評估，尤其是公司已經把 Artifactory 當作主要 artifact hub 的時候，它比單機工具更有治理價值。

Trivy：最常見的開源 all-in-one 掃描工具之一

如果只選一個開源工具來做 container image 掃描入門，目前我可能會推薦選 Trivy。原因很簡單：安裝容易、文件完整、支援範圍廣，除了 image vulnerability，也可以掃 secrets、misconfigurations、licenses，還可以掃 filesystem、Git repository、Kubernetes 等目標。Trivy 官方文件也明確說明，container image 掃描可以檢查 vulnerabilities、misconfigurations、secrets、licenses，而且預設會啟用 vulnerability 與 secret scanning。

安裝 Trivy

使用官方 install script：

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh \
  | sudo sh -s -- -b /usr/local/binCode language: JavaScript (javascript)

官方文件也提供這種 GitHub Release 安裝方式。

macOS 可以使用 Homebrew：

brew install trivy

確認版本：

trivy version

掃描 image vulnerabilities

基本掃描：

trivy image image-scan-demo:badCode language: CSS (css)

只看 High / Critical：

trivy image --severity HIGH,CRITICAL image-scan-demo:badCode language: CSS (css)

若希望在 CI/CD 裡讓高風險漏洞直接讓 pipeline fail，可以使用 --exit-code：

trivy image \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  image-scan-demo:badCode language: CSS (css)

輸出 JSON：

trivy image \
  --format json \
  --output trivy-report.json \
  image-scan-demo:badCode language: CSS (css)

輸出 SARIF：

trivy image \
  --format sarif \
  --output trivy-report.sarif \
  image-scan-demo:badCode language: CSS (css)

Trivy 支援多種輸出格式；Chainguard 的教學也提到 Trivy 可輸出 JSON、SARIF、CycloneDX、SPDX、SPDX-JSON、GitHub formats 等格式。

掃描 misconfiguration、secret 與 license

除了掃描 CVE 漏洞，也支援其他的掃描選項。如果想明確指定掃描項目：

trivy image \
  --scanners vuln,secret,misconfig,license \
  image-scan-demo:badCode language: CSS (css)

如果只想掃漏洞：

trivy image --scanners vuln image-scan-demo:badCode language: CSS (css)

產生 SBOM

輸出 CycloneDX：

trivy image \
  --format cyclonedx \
  --output trivy-sbom.cdx.json \
  image-scan-demo:badCode language: CSS (css)

輸出 SPDX JSON：

trivy image \
  --format spdx-json \
  --output trivy-sbom.spdx.json \
  image-scan-demo:badCode language: CSS (css)

實務上，如果公司只是剛開始建立 container security baseline，Trivy 很適合先放進 CI/CD 裡做最小可行的掃描。它的缺點是結果可能會很多，導入初期如果沒有定義 ignore、severity threshold、exception 流程，很容易變成「掃得出來，但沒有人修」。

Grype：適合 SBOM-first 流程的開源漏洞掃描工具

Grype 是 Anchore 維護的漏洞掃描工具，和 Syft 搭配時特別好用。Syft 負責產生 SBOM，Grype 負責根據 SBOM 或 image 內容找出漏洞。Grype 也是我當時在企業內部自建容器掃描時所選擇的工具。

Grype 官方 GitHub 說明它可以掃 container images、filesystems、SBOM，支援主要 OS package ecosystems 與多種 language-specific packages，也支援 Docker、OCI、Singularity image formats。

這個工具適合比較重視 SBOM 的團隊，因為你可以先用 Syft 固定產出 SBOM，再用 Grype 對同一份 SBOM 做漏洞分析。這樣的流程在稽核、保存證據、重現某次掃描結果時會更清楚。

安裝 Grype

使用官方安裝腳本：

curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/binCode language: JavaScript (javascript)

使用 Homebrew：

brew tap anchore/grype
brew install grype

使用 Docker image 執行：

docker run --rm anchore/grype:latest image-scan-demo:bad

Chainguard 的 Grype 教學也列出可以透過 Homebrew、Chocolatey、官方 Grype Docker image 或下載 binary 的方式安裝。

確認版本：

grype version

掃描 image

基本掃描：

grype image-scan-demo:badCode language: CSS (css)

指定輸出格式：

grype image-scan-demo:bad -o json > grype-report.jsonCode language: CSS (css)

輸出 SARIF：

grype image-scan-demo:bad -o sarif > grype-report.sarifCode language: CSS (css)

Grype 也是可以輸出 JSON、CycloneDX 與 SARIF 等格式。

Grype 也可以搭配 Syft 走 SBOM-first。這個流程的好處是，SBOM 可以被保存下來。假設某次 release 之後發生資安事件，你可以回頭看當時 image 的組成，而不是只依賴當下重新 pull image 的結果。

Dockle：不是 CVE scanner，而是 image hardening linter

Dockle 跟前面提到的掃描工具性質不太一樣，雖然也是掃描 images，但卻不是針對於找出有 CVE 的套件。Dockle 很適合拿來補足漏洞掃描工具看不到的地方。舉例來說，一個 image 可能沒有 Critical CVE，但它可能使用 root、沒有 healthcheck、Dockerfile 使用 ADD 而不是 COPY、apt cache 沒清、疑似把 credential 放進 image。這些不一定都會被 CVE scanner 當作漏洞，但在 container security review 裡仍然很重要。

Dockle 官方說明它的特色包含 detecting container vulnerabilities、協助建立 best-practice Dockerfile、支援 CIS Benchmarks，也適合放在 CI/CD 中使用。不過我會更精準地把它定位為 image linter / hardening checker，而不是主要 CVE 掃描器。

安裝 Dockle

macOS / Linux / WSL 可以使用 Homebrew：

brew install goodwithtech/r/dockle

Debian / Ubuntu 可以用官方文件中的 release 方式：

VERSION=$(
  curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" \
  | grep '"tag_name":' \
  | sed -E 's/.*"v([^"]+)".*/\1/'
)

curl -L -o dockle.deb \
  https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.deb

sudo dpkg -i dockle.deb
rm dockle.debCode language: JavaScript (javascript)

官方文件也提供 Docker 執行方式，如果要掃描 host 上的 local image，需要掛載 Docker socket。

VERSION=$(
  curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" \
  | grep '"tag_name":' \
  | sed -E 's/.*"v([^"]+)".*/\1/'
)

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  goodwithtech/dockle:v${VERSION} image-scan-demo:badCode language: JavaScript (javascript)

確認版本：

dockle --version

掃描 image

基本掃描：

dockle image-scan-demo:badCode language: CSS (css)

輸出 JSON：

dockle --format json image-scan-demo:bad > dockle-report.jsonCode language: CSS (css)

讓 CI/CD 在 WARN 以上 fail：

dockle --exit-code 1 --exit-level warn image-scan-demo:badCode language: PHP (php)

如果某些規則在你的環境中可以接受，可以用 .dockleignore 忽略：

cat > .dockleignore <<'EOF'
CIS-DI-0001
EOF

dockle --exit-code 1 --exit-level fatal image-scan-demo:badCode language: PHP (php)

由於掃描目的與性質的差異，實務上我建議把 Dockle 和「 Trivy / Grype」類型工具搭配使用。Trivy / Grype 專職負責回答「有哪些已知漏洞」，Dockle 負責提醒「這個 image 寫法是否符合基本安全實務」。這兩件事情不一樣，但都重要。

容器映像檔掃描工具比較表

工具	類型	主要強項	適合情境	主要限制
Docker Scout	Docker 原生平台 / CLI	Docker Desktop、Docker CLI、Docker Hub、Dashboard 整合；SBOM、CVE、base image 建議、image compare	Docker 使用者、Docker Hub/registry image 持續追蹤、開發者本機檢查	repository 數量可能受到方案限制；部分功能需要登入與平台整合
Snyk Container	商業 Developer Security 平台	容器、開源套件、IaC、程式碼安全可整合到同一平台；修補建議與 monitor 能力	已使用 Snyk 的 DevSecOps 團隊、需要團隊協作與持續監控	需要帳號與平台；進階功能通常與付費方案相關
JFrog Xray	商業供應鏈安全平台	與 Artifactory、build-info、policy、watch、artifact flow 整合	已使用 JFrog Platform / Artifactory 的企業	不適合單純本機輕量掃描；需要 Xray/平台設定
Trivy	開源 CLI	安裝容易、支援範圍廣；可掃 vuln、secret、misconfig、license、SBOM	快速導入 CI/CD、開源工具優先、需要 all-in-one scanner	結果可能很多，需要治理例外與門檻，否則容易告警疲乏
Grype	開源 CLI	SBOM-first 流程、與 Syft 搭配清楚；支援 image、filesystem、SBOM	重視 SBOM、稽核、可重現掃描流程的團隊	較專注 vulnerability scanning，misconfig/hardening 需搭配其他工具
Dockle	開源 image linter	Dockerfile/image best practice、CIS Benchmark、root user、apt cache、credential 類提醒	補足 CVE scanner 不看的 image hardening 問題	不是主要 CVE scanner，不能取代 Trivy/Grype/Scout

該怎麼選比較好？

如果是個人開發者或 Docker 使用者，我會先從 Docker Scout 和 Trivy、Grype開始。Docker Scout 的優點是整合 Docker 工作流程，很適合在 Docker Desktop 或 Docker CLI 裡快速看 image 狀態；Trivy 和 Grype 則是開源、彈性高、很適合放進 CI/CD。

針對企業現有的方案導入，如果已經是 Docker / Snyk / JFrog 體系，或是便於整合的，預算充足情況下建議優先考量這些工具，對於治理、管理、稽核、安全性(例如需要登入)、團隊協作，都更加有好處。

而在資安或 DevSecOps 團隊導入時，我會至少把工具分成兩層。第一層是「漏洞掃描」，可以選 Docker Scout、Trivy、Grype、Snyk Container 或 JFrog Xray。第二層是「image hardening lint」，可以加入 Dockle。這樣可以避免只看 CVE，卻忽略 Dockerfile 實務問題。

如果是課程、教學、示範，我會建議用 Docker Scout、Trivy、Grype、Dockle 這四個就非常夠了。Docker Scout 代表 Docker-native 體驗，Trivy 代表開源 all-in-one，Grype 代表 SBOM-first vulnerability scanning，Dockle 代表 image hardening lint。這四個放在一起，會比較容易理解「容器映像檔安全掃描不是只有一種問題」。

實務導入時的幾個提醒

第一，不要只比較漏洞數量。不同工具使用的漏洞資料來源、matching logic、package detection 方式不同，所以 A 工具掃出 50 個、B 工具掃出 80 個，不代表 B 一定比較好。比較工具時應該看可解釋性、修補建議、CI/CD 整合、誤報處理、SBOM 支援、例外流程，而不是只看數字。

第二，盡量固定 image digest。很多人掃描時會直接用 latest 或浮動 tag，但 tag 可能會變，導致今天掃的 image 和明天掃的 image 不是同一份。實務上要重現掃描結果，最好記錄 digest。

docker image inspect image-scan-demo:bad --format='{{index .RepoDigests 0}}'Code language: JavaScript (javascript)

第三，把掃描結果分成「可立即修」、「需要測試」、「接受風險」、「不是我方可控」。例如 base image 引入的 CVE 可能要等上流修補，有時候會發生最新版也有漏洞的情況，這時開發團隊也是沒辦法修補的。可以的話，資安也應該將風險排序，列出優先修補的漏洞，不要把所有 findings 都丟給開發者，否則很快就會變成資安噪音。

第四，安全工具本身也要管理版本與來源。2026 年 Trivy 曾公開說明安全事件，攻擊者曾使用 compromised credential 發布惡意 trivy / trivy-action / setup-trivy release，受影響版本與時間窗也有公告；這提醒我們，在 CI/CD 裡使用安全工具時，也應該 pin version、驗證來源，必要時使用 digest，而不是永遠追 latest。

最後，掃描不是最後一關，而是回饋迴圈。理想流程不是「上線前掃一下」，而是開發者本機先掃、PR/CI 再掃、registry 持續監控、production image 有版本紀錄。當新的 CVE 出現時，團隊可以知道哪些 image 受影響、誰負責、要怎麼修、修完怎麼驗證。

結論

容器映像檔掃描工具很多，但每個工具的定位不完全一樣。Docker Scout 適合 Docker-native 的開發流程與 image 修補建議；Snyk Container 適合已經走 developer security platform 的團隊；JFrog Xray 適合 Artifactory / JFrog Platform 為核心的企業供應鏈治理；Trivy 適合快速、開源、全面的掃描導入；Grype 適合 SBOM-first 的漏洞分析流程；Dockle 則適合補足 image hardening 與 Dockerfile best practice 檢查。

如果只是剛開始導入，不要一開始就追求最完整的平台，而是先建立一個可落地的基本流程：開發者本機能掃、CI/CD 能擋重大風險、掃描結果能輸出保存、修補建議能回到 Dockerfile 或 base image 選擇。等這些基本流程跑順，再考慮導入更完整的 Dashboard、policy、exception、registry monitoring 與企業報表。

容器安全不是單靠一個 scanner 就會完成，但 scanner 是一個很好的起點。它讓我們把 image 裡面原本看不見的套件、漏洞、設定風險攤開來看，也讓開發、維運、資安可以針對同一份證據討論風險與修補優先順序。這才是容器映像檔掃描工具真正有價值的地方。

這篇文章會示範哪些工具？

前置準備：不安全的 Image

Docker Scout：Docker 原生整合的 image 分析與修補建議

安裝與確認版本

快速查看 image 風險摘要

查看修補建議

產生 SBOM

比較修補前後 image 差異

本機掃描與平台掃描的差別

Snyk Container：開發者導向的商業掃描平台

安裝與登入

掃描 container image

持續監控 image

JFrog Xray：適合已經使用 Artifactory 的企業供應鏈掃描

安裝 JFrog CLI

設定 JFrog server

掃描 Docker image

Trivy：最常見的開源 all-in-one 掃描工具之一

安裝 Trivy

掃描 image vulnerabilities

掃描 misconfiguration、secret 與 license

產生 SBOM

Grype：適合 SBOM-first 流程的開源漏洞掃描工具

安裝 Grype

掃描 image

Dockle：不是 CVE scanner，而是 image hardening linter

安裝 Dockle

掃描 image

容器映像檔掃描工具比較表

該怎麼選比較好？

實務導入時的幾個提醒

結論

Please Share This Share this content

You Might Also Like

容器安全案例分析：Docker Hub 的「Imageless」攻擊

Docker 新功能”Ask Gordon”：讓 AI 來幫你除錯與修復容器問題

發佈留言 取消回覆

Share this content

發佈留言取消回覆