DAST、SAST、SCA 與滲透測試有什麼不同？完整比較與導入指南

先講結論：四種方法解決的是不同問題

SAST 讀取原始碼或編譯產物，尋找不安全的資料流與程式實作；SCA 盤點第三方及開源元件，確認版本、已知漏洞與授權資訊；DAST 從外部與正在運行的網站或 API 互動，觀察攻擊輸入在真實部署環境中的反應；滲透測試則由具備經驗的人員根據範圍與威脅情境，嘗試驗證、繞過控制並串連多個問題。

它們的差異不只是工具不同，而是可取得的資訊、測試時間點與能回答的問題不同。SAST 看得到程式內部但不一定知道正式環境如何運作；DAST 看得到實際回應卻通常看不到根因所在的程式碼；SCA 能快速辨識已知有問題的元件，卻不等於該元件在目前系統中一定可被利用；滲透測試能深入情境，但受限於人力、範圍與測試時間。

因此，專業的選擇方式不是問『哪一個最好』，而是先確認目前要保護的資產、可取得的測試條件、希望在哪個階段阻止問題，以及需要多高程度的證據。

SAST：在程式尚未運行前檢查實作風險

SAST（Static Application Security Testing，靜態應用程式安全測試）在不執行程式的情況下分析原始碼、位元碼或編譯產物，屬於白箱檢測。它會依語言與框架建立語法、控制流與資料流模型，追蹤外部輸入如何進入程式、經過哪些處理，以及最後是否流向資料庫查詢、系統命令、檔案操作或輸出頁面等敏感位置。

SAST 最大的價值是提早與可定位。它可以在開發者提交程式或建立 Pull Request 時執行，將問題定位到檔案、函式與程式行，讓修復發生在尚未部署之前。對重複出現的不安全 API 用法、輸入驗證缺失、硬編碼機密或部分注入風險，SAST 很適合建立一致且自動化的基礎檢查。

限制是它看到的是程式模型，不是真正部署後的系統。框架行為、執行環境、反向代理、雲端權限與實際設定可能讓結果成立或失效；動態產生的程式碼、複雜反射及跨服務資料流也可能降低準確度。SAST 的發現應經過判讀，不能把規則命中數直接當成已確認弱點數。

• 最適合：開發中自有程式碼、可取得原始碼或編譯產物的系統
• 主要證據：程式位置、來源與敏感操作之間的資料流、命中的安全規則
• 優勢：能提早執行、容易整合 IDE 與 CI、通常能快速指出修復位置
• 盲點：無法完整反映正式環境設定，也不擅長確認多步驟業務邏輯是否真的可被利用

SCA：管理第三方元件與軟體供應鏈風險

SCA（Software Composition Analysis，軟體成分分析）聚焦應用程式使用的第三方套件、開源函式庫與間接相依元件。它通常分析套件清單、lockfile、建置產物或容器內容，建立元件名稱與版本，再對照公開弱點資料、供應鏈情報與授權政策。

現代應用程式很少完全由自有程式碼構成。一個專案直接安裝的套件，可能再引入數十個遞迴相依元件；團隊甚至不知道有問題的元件已經進入正式版本。SCA 可以協助建立元件清冊與 SBOM，持續追蹤發布後才被揭露的漏洞，這也是它與只在提交當下執行一次的程式碼檢查不同之處。

但『元件版本存在已知 CVE』不一定等於目前應用程式已經暴露。實際風險還要確認受影響功能是否被引入、是否可以從外部到達、執行環境與設定是否符合利用條件，以及是否已有補償性控制。反過來說，資料庫沒有收錄也不能證明元件安全，因為尚未公開或尚未指派 CVE 的問題不會出現在比對結果中。

• 最適合：套件相依多、更新快速、需要 SBOM 或授權治理的軟體專案
• 主要證據：元件名稱、版本、相依路徑、已知漏洞公告與授權資訊
• 優勢：元件盤點速度快，可在建置前阻擋已知高風險版本並持續重新比對
• 盲點：通常無法單獨證明弱點程式路徑可達，也不檢查企業自行開發的業務邏輯

DAST：從外部檢查正在運行的網站與 API

DAST（Dynamic Application Security Testing，動態應用程式安全測試）以黑箱方式對正在運行的網站或 API 發送請求，觀察 HTTP 回應、錯誤行為、標頭、Cookie、驗證狀態與輸入處理。OWASP 將 DAST 描述為不需要取得原始碼，即可透過安全測試輸入辨識 SQL Injection、XSS、驗證問題與伺服器設定錯誤等風險的方法。

DAST 的重要價值是測試『實際被部署出來的系統』。它能同時涵蓋應用程式、Web 伺服器、中介軟體與部分安全設定，並留下具體請求與回應作為重現證據。對第三方建置、無法取得原始碼的網站，DAST 也經常是建立外部安全可視性的主要方法。

覆蓋率則取決於掃描器是否真的走到相關功能。未被爬取的頁面、缺少測試帳號的登入後流程、需要特定角色的 API、複雜前端狀態與多步驟交易，都可能形成盲區。DAST 找到的是外部可觀察行為，通常仍需要分析人員確認證據、處理誤報，並由開發團隊回到程式或設定定位根因。

• 最適合：已部署的網站、Web API、無法取得原始碼或需要驗證實際環境的系統
• 主要證據：實際網址與參數、HTTP 請求與回應、驗證狀態及重現條件
• 優勢：技術堆疊相對無關，能觀察真實部署行為並適合排程重複執行
• 盲點：只看得到成功抵達的攻擊面，對業務邏輯、複雜權限與程式根因理解有限

滲透測試：由測試人員驗證攻擊路徑與實際影響

滲透測試是在合法授權與明確範圍內，由測試人員模擬攻擊者進行資訊蒐集、假設建立、弱點驗證、控制繞過與影響評估。它可能使用自動化掃描工具協助建立線索，但核心價值來自人的推理：理解業務流程、切換不同角色、調整攻擊方法，並把多個單獨看似有限的問題串成實際攻擊路徑。

例如重設密碼流程洩漏帳號狀態、API 授權檢查不一致與 Session 失效不完整，三個問題單獨看可能都不嚴重，但在特定步驟下可能被串連成帳號接管。這類跨頁面、跨角色與跨系統的推理，通常不是一次自動掃描能完整完成。

滲透測試同樣有邊界。它是特定時間內對特定範圍進行的深入抽樣，結果高度受測試人員能力、可用時間、帳號權限與環境限制影響。OWASP 指出，滲透測試不應成為唯一的安全測試技術；NIST SP 800-115 也將弱點掃描與滲透測試視為各有優缺點、應依目標組合的技術方法。

• 最適合：重大上線、核心交易、複雜權限、特定威脅情境與高風險系統
• 主要證據：完整攻擊敘事、跨步驟重現方式、控制繞過與可證明的業務影響
• 優勢：能理解情境、驗證可利用性，並探索工具難以辨識的業務邏輯與弱點串連
• 盲點：成本與時間較高，結果是範圍內的時間點樣本，不適合取代日常自動化覆蓋

DAST、SAST、SCA 與滲透測試完整比較

比較四種方法時，最重要的是先看它們取得什麼測試素材，以及證據來自哪裡。以下表格呈現典型差異；實際工具能力仍會因語言、框架、驗證方式與設定而不同。

正確時機：把四種方法放進同一條 SDLC

成熟的 AppSec 流程不會等系統完成後才一次執行所有檢查。NIST SSDF 強調，安全實務應整合進既有軟體開發生命週期，並依風險、可行性、成本與自動化程度調整。OWASP 也建議採取平衡方法，在設計、開發、整合驗證與營運階段使用不同證據。

SAST 與 SCA 可以靠近開發者，在變更進入主分支前提供快速回饋；DAST 需要可運行環境，適合在整合測試、上線前與正式環境建立持續覆蓋；滲透測試則應聚焦重大風險、核心流程與工具難以理解的情境。四者產生的發現應進入同一套去重、判讀、排序、指派與複驗流程，而不是形成四份彼此分離的清單。

• 設計階段：先以威脅建模與安全需求確認信任邊界，四種檢測都無法取代這一步
• 開發階段：SAST 檢查自有程式碼，SCA 檢查第三方元件，先處理高信心且可快速修復的問題
• 整合與上線前：在接近正式設定的環境執行登入後 DAST，驗證完整頁面、API 與角色範圍
• 重大發布或高風險系統：安排滲透測試，集中驗證業務邏輯、控制繞過與弱點串連
• 正式營運：持續監控元件新公告並排程 DAST，在改版、設定異動與修復後重新檢測

用同一個帳號系統，看懂四種方法如何互補

假設企業新增一套會員帳號與訂單查詢功能。SAST 可能在程式中發現使用者輸入未經適當參數化就進入資料庫查詢，或某個 API 路由缺少一致的授權檢查；SCA 可能發現身分驗證套件的版本存在已公開弱點，並指出它是由哪一個上層元件間接引入。

當服務部署到測試環境，DAST 可以實際登入、爬取功能並對輸入點與 Session 行為進行探測，確認某個錯誤是否會在目前設定中產生可觀察的異常回應。滲透測試人員則可能切換一般會員、客服與管理者角色，檢查訂單識別碼、密碼重設與權限提升是否能被串連。

四種結果不應互相比數量，而應互相補充證據。SAST 提供根因位置，SCA 提供受影響元件與更新脈絡，DAST 提供外部重現結果，滲透測試補上可利用性與業務衝擊。當它們指向同一個風險時，團隊才能更快做出可靠的修復決策。

四種方法仍然無法取代哪些安全工作？

即使同時導入四種方法，也不能宣稱應用程式因此『完整安全』。不安全設計、錯誤的信任假設、資料使用方式、權限治理與事件應變能力，不一定能從程式規則或測試輸入中被完整辨識。安全測試提供的是特定範圍與條件下的證據，而不是無限期保證。

工具也無法代替資產盤點與安全責任。若團隊不知道有哪些網站、API、子網域、套件與服務正在運行，再好的工具也只會檢查被送進去的那一部分。發現之後若沒有負責人、修復時限與複驗標準，檢測同樣不會轉化成風險降低。

• 威脅建模與安全架構評估：在寫程式前確認資產、信任邊界與可能濫用情境
• 安全程式碼審查：針對高風險模組進行具備脈絡的人工分析
• 雲端、容器與 IaC 檢測：確認基礎設施與部署設定是否符合安全基準
• 機密資訊管理：控制金鑰、Token、憑證的建立、使用、輪替與撤銷
• 事件偵測與應變：確認系統能留下足夠紀錄，並在攻擊發生時識別與處理

企業導入順序：先建立覆蓋，再逐步提高深度

導入順序應由風險與現有開發流程決定，不需要一開始就購買所有工具。對已有 CI/CD 的自研團隊，可先從套件盤點、基礎 SAST 與公開網站 DAST 建立自動化覆蓋；對外包或套裝系統，因為未必能取得原始碼，資產盤點、DAST、設定檢查與供應商風險管理通常更實際。

第二階段再補上登入後 DAST、規則調校、結果去重與修復 SLA，讓掃描結果真正能被工程團隊處理。對高風險交易、複雜權限與重大改版，則安排針對性的人工測試或滲透測試，並將其中確認過的攻擊情境轉成後續可以重複執行的測試案例。

無論從哪一種方法開始，都應先定義成功標準：哪些資產必須被覆蓋、什麼情況阻擋發布、誰負責判讀與接受風險、修復後如何複驗。沒有治理規則的工具堆疊，最後只會產生更多無人處理的警示。

評估工具與服務時，應該問的十二個問題

工具展示通常聚焦能找到多少弱點，但企業真正需要評估的是覆蓋、證據、整合與後續維運成本。以下問題可以用於 PoC、採購或既有工具檢討，並要求供應商以實際測試環境證明，而不是只回答功能清單。

• 它需要哪些輸入：原始碼、建置產物、套件清單、網址、API 規格或測試帳號？
• 支援哪些語言、框架、套件生態、API 格式與驗證流程？
• 能否處理多角色登入、MFA、SPA、GraphQL 與多步驟業務流程？
• 如何衡量掃描實際覆蓋，而不是只呈現找到的弱點數？
• 每項發現是否包含可定位、可重現且經適度遮罩的證據？
• 如何處理誤報、重複結果、已接受風險與補償性控制？
• 規則、漏洞資料與元件情報多久更新，如何保留版本與執行紀錄？
• 能否整合版本控制、CI/CD、工單、通知與身分權限系統？
• 哪些情況會阻擋發布，哪些只提出警示，例外如何核准與到期？
• 掃描是否可能改變資料或影響正式服務，能否設定速率與停止條件？
• 修復後能否針對原始位置重新測試，並留下前後一致的複驗證據？
• 資料保存地點、存取權限、機密遮罩與報告交付方式是否符合企業要求？

用互補覆蓋取代單一工具迷思

SAST、SCA、DAST 與滲透測試的共同目的，是降低未被發現與未被處理的軟體風險；它們的差異，決定了各自應在哪個階段提供什麼證據。SAST 提早處理自有程式碼，SCA 掌握第三方元件，DAST 持續觀察真實網站，滲透測試深入驗證重要攻擊情境。

企業不應追求一份看似涵蓋所有問題的掃描清單，而應建立一條能把不同來源發現整合、去重、判讀、排序、修復與複驗的流程。當每種方法被放在正確位置，安全測試才會從部署前的最後一道檢查，轉變為貫穿軟體生命週期的持續能力。