本文整理目前業界常見的弱點掃描技術與分類，重點放在「有哪些技術、各自檢查什麼、適合什麼場景」，不涉及任何攻擊手法或侵入式操作步驟。提醒：所有掃描都應只針對自有、或已取得書面授權的系統進行。
一、先分清楚：非侵入式與侵入式
- 非侵入式（被動／基線）：只讀取系統本來就公開回應的資訊，例如憑證、HTTP 標頭、版本字串、DNS 紀錄，不送出任何試圖改變系統行為的資料。風險極低，適合日常例行監控。
- 侵入式（主動測試）：會送出特製請求驗證弱點是否真的可被利用，屬於滲透測試範疇，必須事先授權並控制範圍。本文不展開這部分。
二、主要掃描技術分類
1. 資產探索與外部攻擊面管理（EASM／ASM）
先知道「自己有什麼」才能談保護。透過 DNS、憑證透明度紀錄（Certificate Transparency）、WHOIS 與公開搜尋資料，盤點對外暴露的網域、子網域、IP 與服務。許多事故都發生在被遺忘的測試站或舊主機上。
2. 網路／主機弱點掃描
辨識主機上開放的服務與版本，再與 CVE 資料庫比對，分為兩種：
- 未認證（外部視角）：只看得到對外服務的標語與版本，誤判率較高。
- 認證式（Credentialed）：以唯讀帳號登入主機，直接讀取套件版本、修補狀態與設定，準確度高得多，也是稽核常用方式。
代表工具：OpenVAS／Greenbone、Nessus、Qualys、Rapid7 InsightVM。另有「代理程式（Agent）」模式，在主機上常駐回報，適合筆電與雲端短期主機。
3. 組態與合規基線檢查
不找程式漏洞，而是檢查「設定是否安全」：SSH 是否允許 root 密碼登入、檔案權限、密碼政策、日誌是否開啟等，對照 CIS Benchmark、DISA STIG 等標準。代表工具：Lynis、OpenSCAP、CIS-CAT。
4. 網站外部基線檢查（非侵入）
針對網站的被動檢查，是最容易落實的一層：
- TLS 版本、加密套件、憑證有效期與憑證鏈完整性
- 安全標頭：CSP、HSTS、X-Frame-Options、X-Content-Type-Options、Referrer-Policy
- Cookie 旗標：Secure、HttpOnly、SameSite
- HTTP 是否正確轉址到 HTTPS、是否有混合內容
- 前端函式庫版本（如 jQuery）與已知 CVE 對照
- 是否意外公開版本資訊、目錄列表或除錯頁面
常見的免費檢測服務：Mozilla Observatory、SSL Labs、securityheaders.com。
5. 動態應用程式安全測試（DAST）
從外部以「使用者」角度測試執行中的網站或 API，涵蓋 OWASP Top 10 類型的問題。現代 DAST 的重點技術包括：能爬取 SPA 單頁應用的瀏覽器引擎、登入後掃描、OpenAPI／GraphQL 規格匯入，以及用帶外回連（OAST）確認沒有回應徵兆的盲性弱點。代表工具：OWASP ZAP、Burp Suite、Invicti、Acunetix。（DAST 的主動測試部分屬侵入式，需授權。）
6. 靜態應用程式安全測試（SAST）
直接分析原始碼，找出不安全的寫法（例如未過濾的輸入流向資料庫查詢）。優點是能在開發階段就發現問題並指出確切行號；缺點是誤報較多。代表工具：Semgrep、CodeQL、SonarQube、Checkmarx。
7. 軟體組成分析（SCA）與 SBOM
現代軟體大部分由開源套件組成，SCA 會列出所有相依套件（含間接相依），比對已知弱點與授權條款。SBOM（軟體物料清單，CycloneDX／SPDX 格式）已逐漸成為供應鏈法規要求。代表工具：Dependabot、Snyk、OWASP Dependency-Check、Trivy、Grype、Syft。
8. 互動式測試（IAST）與執行期防護（RASP）
在應用程式內部放入感測器，於測試或實際執行時觀察資料流，兼具 SAST 的精準定位與 DAST 的實際執行驗證，誤報較低。代表產品：Contrast Security、Black Duck Seeker。
9. 容器、雲端與基礎設施即程式碼（IaC）掃描
- 容器映像檔：掃描映像內的作業系統套件與函式庫弱點（Trivy、Grype、Clair）。
- IaC：部署前檢查 Terraform、Kubernetes YAML、Dockerfile 的不安全設定（Checkov、tfsec、KICS）。
- 雲端態勢管理（CSPM／CNAPP）：以唯讀 API 檢查雲端帳號設定，例如公開的儲存桶、過寬的權限（Prowler、Wiz、Prisma Cloud）。
10. 機密資訊掃描（Secret Scanning）
找出被誤放在程式碼、Git 歷史或設定檔中的 API 金鑰、密碼與私鑰。代表工具：gitleaks、TruffleHog、GitHub Secret Scanning。
11. 網站木馬與入侵跡象（IOC）掃描
以唯讀方式比對網站檔案中的後門特徵、混淆程式碼，或與官方版本做完整性雜湊比對（例如 WordPress 核心檔 md5），並檢查主機上的可疑排程、啟動項目等入侵跡象。代表工具：Linux Malware Detect（maldet）、ClamAV、Wordfence、YARA 規則。
12. 網域信譽與黑名單查詢
檢查網域或 IP 是否被 Spamhaus、SURBL、Google Safe Browsing 等列管。網站遭入侵、被植入釣魚頁或垃圾轉址後，常最先在這裡出現徵兆，例如瀏覽器顯示紅色警告或郵件被退信。
三、掃描放在哪個階段？
現在的做法是把掃描分散到開發與維運的各階段（DevSecOps）：程式撰寫時跑 SAST 與機密掃描，建置時跑 SCA 並產生 SBOM，封裝時檢查映像檔與 IaC，上線後用 DAST 與外部基線把關，維運期間再以主機稽核、雲端設定檢查與木馬監控持續觀察。越早發現，修補成本越低。
四、弱點排序：不是每個 CVE 都一樣急
掃描結果動輒上百項，現在的趨勢是依「實際風險」排序，而不是只看分數：
- CVSS v4.0：弱點嚴重度的基礎分數（2023 年發布，逐步取代 v3.1）。
- EPSS：FIRST 提供的「未來 30 天被利用機率」預測。
- CISA KEV：美國 CISA 維護的「已知遭實際利用弱點」清單，列入者應優先修補。
- SSVC：依「是否已被利用、是否對外、影響程度」決定處理優先度的框架。
- 可信度分級：把結果分為已確認／很可能／待人工判斷，降低誤報干擾。
五、近年的技術趨勢
- 持續掃描：把 SAST、SCA、機密掃描接進 CI/CD，每次提交自動檢查，而不是一年做一次。
- 差異追蹤：比較兩次掃描的「新增／已修復／仍存在」，驗證修補成效。
- AI 輔助：用大型語言模型整理報告摘要、說明修補方式、協助判讀誤報；結論仍需人工確認。
- API 優先：API 成為主要攻擊面，以 OpenAPI／GraphQL 規格驅動的檢測愈來愈重要。
- 工單與通知整合：發現自動送進 Jira、Slack 等，形成修補流程閉環。
六、從哪裡開始？
沒有單一工具能涵蓋全部面向。實務上建議依「資產盤點 → 非侵入基線 → 認證式主機稽核 → 程式碼與套件掃描 → 定期複檢」逐層建立，並搭配風險排序。最後也要記得：掃描「未發現問題」不等於「安全」，自動化工具只是起點，關鍵系統仍需要人工審查。
參考標準
- OWASP Top 10、OWASP WSTG（網站安全測試指南）、OWASP ASVS（應用安全驗證標準）
- CIS Benchmarks、NIST SP 800-115（技術安全測試指南）
- CVE／NVD 弱點資料庫、CWE 弱點分類
※ 本文插圖皆為本站自行繪製。