自架弱點掃描完整指南：OpenVAS / Greenbone 安裝實錄、七套可選工具與真實成本

一台 Ubuntu、一個 docker compose 指令、四十分鐘之後，你會有一套能掃整個內網的弱點掃描系統，授權費零元。

聽起來像廣告詞，但這件事技術上完全成立。真正會卡住你的是裝完之後的三個問題：資料庫要等多久才同步完、掃出來的三百多項報告誰來看、以及免費的漏洞資料庫到底缺了什麼。

這篇把這三件事一次講清楚，並且把自架的帳實際算給你看。

先說清楚我們的立場

恆遠做的是客製化系統開發，不賣弱點掃描服務、也不代理任何掃描軟體，這份工具清單背後沒有分潤關係。

我們自己在交付系統前會跑掃描，把相依套件與設定問題清掉再上線。40+ 企業客製案累積下來，踩過的坑大致都在這篇裡。至於三種資安檢測的定位差異與市場行情，我們另外寫過一篇弱點掃描、滲透測試與壓力測試的完整對照。

弱點掃描分好幾層，工具各管一塊

先建立一個觀念：沒有任何一套工具能掃完所有東西。弱點掃描依「掃什麼層」分成幾個不同世界，工具各管一塊。

拿 Nessus 去掃網站的 SQL Injection，或拿 ZAP 去檢查伺服器有沒有中 OpenSSL 漏洞，都是用錯工具，然後得到一份很乾淨、很讓人安心、但完全沒有意義的報告。

選型的第一題是「我要掃的東西住在哪一層」，第二題才是「哪一套工具比較強」。

七套值得自架的工具

最務實的起手組合是三套：Greenbone 掃主機、ZAP 或 Nuclei 掃網站、Trivy 掃 image 與套件。加起來授權費零元，涵蓋絕大多數中小企業的實際攻擊面。

等掃描器變多、報告分散到看不完，再把 DefectDojo 架起來當統一收斂點。它能解析兩百種以上掃描器的輸出格式並自動去重，但那是「已經有多套工具」之後的解法，起手就裝反而是負擔。

被低估的那一套是 Trivy

如果只能裝一套工具，而你的系統是這五年內開發的，我們會選 Trivy。

理由很現實：現代應用的漏洞絕大多數不在自己寫的程式碼裡，而在 npm install 進來的那一千兩百個套件裡。Trivy 掃的正是這一塊，包括容器 image 裡的 OS 套件與應用程式套件、專案的 lockfile、Terraform 與 Kubernetes 設定錯誤，以及原始碼裡外洩的密鑰。

它是單一執行檔，掃一個 image 只要幾秒，塞進 CI pipeline 是十分鐘的事：

# 掃一個 container image
trivy image your-app:latest

# 掃專案目錄，含相依套件、IaC 設定與密鑰
trivy fs .

在我們自己的交付流程裡，這個指令跑在每次建置之後。它擋掉的問題數量，比其他所有掃描工具加起來還多。

另外三套值得先認識的工具

ZAP 是完整的 Web 應用動態掃描器，能當攔截 proxy、能爬站、能做主動攻擊測試，支援 REST、GraphQL 與 SOAP。它原本是 OWASP 專案，2024 年起由 Checkmarx 接手維運，仍然開源免費。對有自架網站或 API 的團隊來說，它是主機弱掃之外的必要補充，因為 Greenbone 看得到伺服器的漏洞，卻看不到你的登入流程有沒有越權問題。

Wazuh 走的路線不同，它在每台主機上裝 agent，持續回報已安裝軟體清單、設定基準與檔案異動，由伺服器端比對 CVE。優點是不用每次重新掃描全網段，主機一開機就自動納管，適合內網主機數量到達十台以上、而且經常有新機器加入的環境。代價是要多維運一套 server 加 agent 架構，起手複雜度明顯高於前面幾套。

DefectDojo 本身不掃描，它是弱點管理平台。當你同時跑 Greenbone、ZAP、Trivy 三套工具，每季會拿到三份格式完全不同的報告，同一個漏洞可能在兩份報告裡各出現一次。DefectDojo 能解析兩百種以上掃描器的輸出格式，自動去重並追蹤每一項的修補狀態。判斷要不要裝它有個簡單標準：當你開始需要用 Excel 手動比對兩份掃描報告時，就是該裝的時候。

至於 Nikto、Grype、Semgrep、Gitleaks 這幾套，功能上分別被 ZAP、Trivy 涵蓋掉一部分，起手階段可以先不用管。等基本流程跑順了，再依實際缺口補。

Nessus Essentials 在 2026 年縮水了

這件事值得單獨拉出來講，因為網路上大量中文文章（包含 2025 年寫的）都還在說「Nessus Essentials 免費、可掃 16 個 IP」。

我們在 2026 年 7 月查 Tenable 官方頁面，現況已經完全不同：

三個限制都很致命。5 個 IP 對任何真實環境都不夠，而且 Tenable 的計算方式是掃過就算，刪掉掃描結果不會把額度還給你。plugin 延遲 30 天直接抵銷了弱點掃描的核心價值，新公布的 CVE 最危險的就是前幾週，你的工具剛好在這段時間看不見它。非商用授權則意味著企業拿它掃生產環境屬於違反授權條款，這一點連付費的 Essentials Plus 都一樣。

Tenable 對學生與教職人員有 Nessus for Education 方案可免費取得 Essentials Plus，教學與自學用途值得申請。定價與方案他們調整得很頻繁，採購前請自行到官網確認當下條款。

Greenbone 自架實作

Greenbone Community Edition 是 OpenVAS 的正式後繼專案。名字有點混亂，簡單說：掃描引擎叫 OpenVAS Scanner，整包含 Web 介面的系統叫 Greenbone Community Edition，官方文件與容器映像都在 Greenbone 名下維護。

硬體需求

依 Greenbone 官方文件：

官方文件同時註明，這組數字是測試與開發用途的基準，不是正式環境部署規格。實務建議直接照建議值配，而且記憶體寧可多給。記憶體不足最痛的地方在於首次同步弱點資料庫時會失敗或卡住，而且錯誤訊息不會直接告訴你原因，很容易誤判成網路問題。

Docker Compose 安裝步驟

最省事的裝法是官方提供的容器版本。在一台乾淨的 Ubuntu 或 Debian 上：

第一步，安裝 Docker 與必要套件

sudo apt update
sudo apt install -y ca-certificates curl
# 依 Docker 官方文件安裝 Docker Engine 與 compose plugin
sudo usermod -aG docker $USER && su $USER

第二步，下載官方 compose 檔

export DOWNLOAD_DIR=$HOME/greenbone-community-container
mkdir -p $DOWNLOAD_DIR
curl -f -O -L https://greenbone.github.io/docs/latest/_static/compose.yaml \
  --output-dir "$DOWNLOAD_DIR"

第三步，拉映像檔並啟動

docker compose -f $DOWNLOAD_DIR/compose.yaml pull
docker compose -f $DOWNLOAD_DIR/compose.yaml up -d

第四步，設定管理者密碼

docker compose -f $DOWNLOAD_DIR/compose.yaml \
  exec -u gvmd gvmd gvmd --user=admin --new-password='換成你的強密碼'

第五步，開啟 Web 介面

預設會在 https://127.0.0.1，部分版本綁在 9392 埠，以你下載到的 compose 檔裡的 port mapping 為準，帳號是 admin。

第一次啟動別急著掃

這是新手最常見的挫折點：裝好了、登入了、馬上建一個掃描任務、跑完顯示沒有任何弱點，於是以為工具壞了或系統很安全。

實際上是弱點資料庫還沒下載完。Greenbone 首次啟動要同步十萬筆以上的檢測腳本（NVT）、CVE 與 SCAP 資料，依網路速度可能要數十分鐘到數小時。在 Web 介面的 Administration → Feed Status 可以看到同步進度，四個 feed 全部顯示為 current 之後再開始掃，數據才有意義。

建立第一個掃描任務

1. Configuration → Targets 新增目標，填入要掃的 IP 或網段，例如 192.168.1.0/24
2. 有主機帳密的話，設定 Credentials 做認證掃描
3. Scans → Tasks 新增任務，掃描設定選 Full and fast
4. 執行，等結果，報告可匯出 PDF、CSV 或 XML

認證掃描與非認證掃描的差距比想像中大

非認證掃描從外面看，只能靠服務回應的 banner 猜版本，誤報多、漏報也多。認證掃描用帳密登入主機，直接列出已安裝套件版本比對 CVE，準確度是另一個量級。

如果你只做非認證掃描，然後覺得開源工具果然沒有商用的準，多半跟工具無關。商用工具在非認證模式下一樣不準，這是方法問題。

Community Feed 的真實限制

自架最需要誠實面對的一點：免費的 Community Feed 跟 Greenbone 的商用 Enterprise Feed 並不等價。

依 Greenbone 官方的 feed 比較說明，兩者差別在：

• Community Feed 不涵蓋企業級產品的弱點偵測，Cisco、Palo Alto、Fortinet、AWS 這類商用網通與雲端產品的檢測項目屬於 Enterprise Feed
• 更新頻率較低，新公布漏洞的收錄速度跟不上商用 feed
• 不包含 EPSS 指標（漏洞實際被利用機率的評分），排修補優先順序時少一個重要依據
• 不含 CIS 那類合規基準與官方技術支援

這對你的意義取決於環境長什麼樣。

如果你的環境是 Linux 主機加開源中介軟體加自己寫的應用，也就是絕大多數台灣中小企業與新創的樣子，Community Feed 的涵蓋率相當夠用。

如果你的機房裡有一整櫃 Cisco 設備、Fortinet 防火牆，跑在企業版商用軟體上，那 Community Feed 會有系統性的盲區，這時候商用工具的錢省不掉。

有一個簡單的自我檢查方式：把你機房裡的設備與軟體列一張清單，數一數其中有多少項是需要跟原廠買授權的商用產品。如果比例低於兩成，Community Feed 大致覆蓋得住；超過一半，就該認真評估商用方案，或者至少接受這些設備得靠原廠的漏洞公告與更新機制自行追蹤，而不是靠掃描器發現。

這個判斷比「開源好還是商用好」有用得多，因為它直接對應到你環境裡的實際盲區大小。

自架的真實成本

「開源免費」只講了成本的一半。以下把該算的都算進來，情境設定為 30 個 IP 的中小企業內網加 3 個對外網站，每季掃一次。

直接成本

雲端 VM 費用為市場概估區間，實際請以你選用業者的計價為準。掃描主機不需要 24 小時開機，只在掃描期間啟用可以再降低費用。

人力成本才是大頭

以每季一輪計算，穩定運作後每年約 8 到 15 人天，加上第一年的建置 1 到 3 人天。

以工程師人天成本抓 NT$8,000 到 15,000 估算（含勞健保與管銷的內部成本，非外包報價），第一年約 NT$10 萬到 27 萬，第二年起約 NT$7 萬到 23 萬。

所以「免費」的正確理解是：自架省下的是授權費與服務費，換來的是工時。 授權費是確定支出，工時是隱藏支出，這就是為什麼自架的帳很容易被算漏。

人力成本裡最大的一塊是報告判讀，不是安裝。安裝一個下午就好了；每季拿到一份三百多項的報告，要逐項判斷哪些是誤報、哪些不用管、哪些現在就要修，這件事沒有捷徑，而且需要一定的資安判斷力。

自架划不划算、什麼規模開始划算，我們在自建與委外的完整成本試算用三個情境算給你看。

把掃描接進開發流程的最小做法

Greenbone 適合定期掃整片內網，但它不適合每次改版都跑一次。真正能做到「每次上版都檢查」的，是下面這三個輕量工具，它們都能塞進 CI pipeline，單次執行時間以秒計。

相依套件與容器：Trivy

在建置流程的最後一步加上掃描，發現高風險漏洞就讓建置失敗：

# 只在出現 HIGH 與 CRITICAL 漏洞時回傳非零結束碼
trivy image --severity HIGH,CRITICAL --exit-code 1 your-app:latest

實務上剛導入時建議先用 --exit-code 0，讓它只報告不擋建置，把既有的一批舊漏洞清完再改成擋。否則第一天就會卡住所有人的部署，然後這個檢查會在三天內被關掉。

已知 CVE 快速驗證：Nuclei

Nuclei 是模板式掃描器，載入 YAML 格式的檢測規則，社群維護的模板超過一萬個，涵蓋最新 CVE、雲端設定錯誤與暴露的管理後台：

# 掃單一目標，只跑高風險與嚴重等級的模板
nuclei -u https://your-site.example -severity high,critical

它的強項是快，掃一個網域通常一兩分鐘內結束，適合放在部署後的煙霧測試階段。

Web 應用掃描：ZAP

ZAP 提供 baseline scan 模式，用容器跑一次即可，適合放在測試環境部署完成之後：

docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://staging.your-site.example

baseline scan 只做被動掃描，不會對目標發出攻擊性請求，跑在自家測試環境相對安全。要做主動掃描請先確認環境是測試環境，並且資料庫有備份。

這三個加起來的執行時間通常不到五分鐘，卻能擋掉相依套件過舊、已知 CVE 未修、常見設定錯誤這三類問題。對開發團隊而言，它們的投報率遠高於一年跑兩次的大型掃描。

自架之前要先確認的三件事

第一，你有沒有權限掃？

自己公司的系統當然可以。但主機如果在雲端或代管平台，掃描前請確認服務條款，多數業者對高強度掃描與滲透測試有報備規定。掃到不屬於你的 IP 是《刑法》第 358 條的問題，不是技術問題，這條線我們在三種檢測的對照文裡講得更完整。

第二，掃描本身會不會弄壞系統？

會，雖然機率不高。認證掃描與部分積極的檢測項目可能造成老舊服務崩潰、印表機噴出滿地白紙、工控設備異常。第一次掃描請避開營業時間，並且先在測試環境試跑。

第三，掃出來之後誰修？

這是最該先想清楚的一題。掃描報告會很誠實地告訴你有 47 個中高風險項目，然後呢？

如果答案是沒人有空修，那自架的意義就只剩下讓自己焦慮。這種情況下請先只掃對外服務、只處理高風險項，做得完的小範圍比做不完的大範圍有價值得多。

我們怎麼看

自架弱點掃描的技術門檻比多數人想的低，Greenbone 一個 docker compose 就起來了。真正難的是維持一個持續運作的節奏：每季固定掃、報告有人看、修補有人追、下一季複掃驗證。工具是免費的，紀律不是。

我們的判斷是，接下來三年主機層弱點掃描會愈來愈像 CI 裡的一個 step，而不是一年跑幾次的獨立活動。Trivy 這類單一執行檔工具已經證明這條路走得通，Greenbone 的容器化也在往同個方向靠。真正的分水嶺會落在「有沒有把掃描綁進交付流程」，而不是「用哪一套掃描器」。

對中小企業老闆的實際意義：評估自架時，別問「我們養不養得起一套掃描系統」，改問「我們的系統每次改版後，有沒有人會記得重新檢查一次」。前者是預算問題，後者才是會不會出事的關鍵。

掃出來的洞，誰來修？

我們常收到客戶轉來的弱掃報告，要我們照著修：相依套件版本過舊、輸入沒有驗證、權限判斷寫在前端、日誌什麼都沒留。這些項目多半在當初交付時就沒有被要求，久了就變成技術債。

如果你正在評估把一套系統重做、或接手一套沒人維護的舊系統，希望這些控制項在交付時就內建，而不是上線後靠掃描報告一項項補，歡迎跟我們聊聊。

想先把工具本身搞懂，接著看弱點掃描工具怎麼選；想確認法規要求的檢測頻率，看資通安全管理法 A/B/C 級的八份附表對照；系統真的被入侵之後怎麼止血，另有一篇WordPress 網站被駭處理 SOP。

資料來源與查核日期

• Greenbone Community Documentation，安裝指令與硬體需求（2026-07-31 查核）
• Greenbone 官方 Community Feed 與 Enterprise Feed 比較說明
• Tenable 官方 Nessus Essentials 產品頁與定價頁（2026-07-31 查核，方案異動頻繁，請以官網為準）
• 雲端主機與人力成本為市場概估區間，非報價