SAST vs DAST vs IAST：安全測試三兄弟的互補而非替代
應用安全測試裏最常見的三個縮寫：SAST、DAST、IAST。很多人第一反應是“選一個最強的”，但這是個僞命題——這三兄弟不是競爭關係，而是從不同視角看同一個問題。選誰不取決於誰更先進，而取決於你處在軟件生命週期的哪個階段、想發現哪一類漏洞、能承受多少誤報。
一、先看一句話定義
- SAST（靜態應用安全測試）：在不運行程序的前提下，掃描源代碼/字節碼找漏洞，屬於“白盒”。
- DAST（動態應用安全測試）：在運行中的程序外部發起請求、模擬攻擊，屬於“黑盒”，不需要源碼。
- IAST（交互式應用安全測試）：在程序運行時從內部插樁（agent），結合運行流量與代碼上下文，屬於“灰盒”。
理解這三者的關鍵，是它們各自回答不同的問題：SAST 問“代碼裏哪裏可能出錯”，DAST 問“實際運行時能不能被打穿”，IAST 問“這次運行中，哪個數據流真的流到了危險點”。
二、SAST：把問題扼殺在寫代碼階段
SAST 直接分析源碼（或編譯中間產物），不執行程序。優點是能在開發早期、甚至提交代碼時就發現問題，定位到具體文件與行號，修復成本低。它覆蓋的是“代碼可達即能掃到”，不依賴運行時環境。
短板：誤報率通常較高，因爲它無法判斷某段代碼在真實業務裏是否會被觸發；對運行時才暴露的問題（如配置錯誤、鑑權繞過、依賴庫的實際調用鏈）看不全；需要源碼，第三方閉源組件無能爲力。
典型場景：CI 流水線裏做代碼提交門禁，防止明顯的注入、硬編碼密鑰、危險函數調用合入主幹。
三、DAST：從攻擊者視角驗證“真能打穿嗎”
DAST 把目標當成黑盒，從外部發送請求、構造攻擊載荷，觀察響應。它最大的價值是貼近真實攻擊——發現的是“運行時確實可被利用”的問題，誤報相對少。不需要源碼，所以也能覆蓋第三方組件、配置層的問題。
短板：通常要到部署之後才能測，發現晚、修復成本高；覆蓋面受限於爬蟲和測試用例能觸達的路徑，測不到沒被發現的功能點；難以精確定位到源碼位置，開發拿到報告往往只知道“哪個 URL 有問題”；對需要登錄、多步驟業務流程的場景，配置成本高。
典型場景：上線前的安全驗收、對已部署環境做週期性掃描。
四、IAST：運行時插樁，兼顧上下文與真實數據流
IAST 通過在應用內植入 agent（探針），在程序運行時同時觀察代碼執行與外部流量。它既能看到請求怎麼進來，也能看到數據在代碼裏怎麼流轉到危險點，因此能給出帶完整調用棧的證據，誤報通常低於 SAST，定位也精確。
短板：需要能在目標環境部署探針（對生產環境有顧慮）；依賴測試覆蓋率——沒被執行到的代碼就發現不了，所以它常與功能測試/自動化測試綁定；對語言和框架的支持有差異；性能上會有一定開銷。
典型場景：配合自動化測試在測試環境跑，既驗證功能又同步產出安全結論。
五、三者對比一覽
| 維度 | SAST | DAST | IAST |
|---|---|---|---|
| 測試對象 | 源碼/字節碼（不運行） | 運行中的目標（外部） | 運行中的應用（內部插樁） |
| 視角 | 白盒 | 黑盒 | 灰盒 |
| 介入時機 | 編碼/提交階段最早 | 部署後 | 測試/運行時 |
| 是否需要源碼 | 需要 | 不需要 | 需要（可插樁） |
| 誤報水平 | 偏高 | 偏低 | 較低 |
| 定位精度 | 到文件/行 | 到 URL/接口 | 到調用棧/數據流 |
| 覆蓋依賴 | 有限（看得到源碼的部分） | 可覆蓋運行時暴露面 | 受執行路徑限制 |
| 典型場景 | CI 代碼門禁 | 上線前驗收 | 與自動化測試結合 |
六、爲什麼是互補而不是替代
把三者放在一起看，會發現它們的盲區恰好互補：
- SAST 看得到代碼但不知道會不會被觸發；DAST 知道能不能被觸發但不知道問題在哪一行；IAST 兩者都要，但要求代碼被執行到。
- SAST 覆蓋早、覆蓋廣但噪聲大；DAST 噪聲小但介入晚、覆蓋窄；IAST 精度高但要能插樁、要跑得夠全。
- 只上 SAST，容易陷入“一堆誤報沒人修”的疲態；只上 DAST，漏洞往往到上線才暴露；只上 IAST，沒跑到的路徑就是盲區。
現實的答案不是三選一，而是按階段編排：早期用 SAST 卡住明顯的壞味道與危險模式，測試階段用 IAST 配合自動化用例做精確驗證，上線前後用 DAST 從攻擊者視角做外部驗收。三者疊加，才構成一個沒有明顯缺口的應用安全測試閉環。
七、落地時的幾個實際問題
1. 誤報誰來處理
無論哪種工具，報告沒人修就等於沒做。要有明確的 triage 流程：誰看、多久內關閉、如何標記“接受風險”。SAST 尤其需要基線管理，否則歷史遺留問題會淹沒新增問題。
2. 覆蓋率比工具品牌更重要
IAST 的發現能力直接取決於測試用例覆蓋了多少代碼；DAST 取決於爬蟲與用例觸達了多少接口。上線前先量一下“被測到的比例”，比換一個更貴的工具更有意義。
3. 別把安全測試當成一次性驗收
安全測試應該嵌進研發流程持續跑，而不是上線前集中補一次。CI 裏跑 SAST、測試環境跑 IAST、定期對生產做 DAST，形成節奏，才不至於每次都靠人肉救火。
4. 關注工具之間的協同
理想狀態是三類結果能歸併到同一個視圖：同一個漏洞，SAST 給代碼位置、IAST 給數據流證據、DAST 給可利用性驗證。能打通這三者的工具鏈，價值遠大於三個各自爲戰的孤島。
八、一張決策清單
- 想在提交階段就攔住明顯漏洞 → 上 SAST，重點做門禁與基線。
- 想驗證已部署系統是否真能被攻擊 → 上 DAST，重點是覆蓋面和登錄態配置。
- 想讓安全結論跟着自動化測試一起產出、且要精確定位 → 上 IAST。
- 資源有限只能先做一個 → 優先 SAST 建立底線，再逐步補 IAST/DAST。
- 追求“一次選對、永久解決” → 這條路不存在，編排與流程纔是答案。
SAST 管“可能”，DAST 管“實際”，IAST 管“具體”——三者合起來纔是一張完整的圖。