● 前言

在軟體開發的安全檢測中，除了 SAST（靜態應用測試） 之外，另一個重要的環節就是 DAST（動態應用測試）。
如果說 SAST 是在源碼層面找漏洞，那麼 DAST 就像是一個駭客，直接對運行中的應用程式發動攻擊，檢驗系統是否能抵擋住真實世界的威脅。

● 什麼是 DAST？

• 定義：
  DAST（Dynamic Application Security Testing）是針對「已經運行中的應用程式」進行動態測試，不需要接觸原始碼，而是透過模擬攻擊來驗證安全性。

• 核心特點：
  🔸 黑箱測試（Black-box testing），無須知道內部程式碼。
  🔸 模擬駭客行為，以外部攻擊者的角度檢視系統弱點。
  🔸 側重於 應用程式與外部互動的介面（HTTP API、Web 介面）。

• 🔍 能檢測的問題：

  1. SQL Injection（SQL 注入）
  2. XSS（跨站腳本攻擊）
  3. CSRF（跨站請求偽造）
  4. 不安全的錯誤訊息回應
  5. 驗證與授權漏洞
  6. 配置錯誤（如 HTTP Headers 缺失）

● SAST vs DAST

● 常見工具

在 DevSecOps 與日常開發流程中，常見的 DAST 工具有：

• OWASP ZAP：開源、功能完整，支援自動化與手動測試。
• Burp Suite：商用工具，滲透測試工程師常用。
• Nikto：專注於 Web Server 弱點掃描。
• Acunetix / Netsparker：商業化產品，適合企業規模應用。

👉 開源方案適合學習與自動化整合，商業工具則更適合大規模或複雜場景。

● 實作範例

🕵️Baseline 掃描＋上傳報告

name: DAST (OWASP ZAP)

on:
  push:
  pull_request:

jobs:
  zap_scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.14.0
        with:
          target: "https://your-staging.example.com"
          rules_file_name: ".zap/rules.tsv"   # 可選：忽略已知誤報
          cmd_options: "-a"                   # 啟用自動攻擊模式
          allow_issue_writing: false          # 不在 Repo 自動開/更新 Issue
          artifact_name: "zap-report"         # 下載時看到的 artifact 名稱
          token: ${{ secrets.GITHUB_TOKEN }}  # 建議仍帶，供權限用

👉 在 Actions → 該次工作執行頁 的下方「Artifacts」看到 zap-report（含 ZAP 報告檔）。

👉 若你想用預設名稱，也可以拔掉 artifact_name；預設會叫 zap_scan。

● 總結

DAST 的價值在於 「模擬真實世界的威脅」，彌補了 SAST 無法發現的問題。
然而，DAST 的弱點是「無法直接指出程式碼哪裡出錯」，所以更適合作為 SAST 的補充。
兩者搭配使用，才能兼顧 開發早期的防護 與 上線前的實戰檢驗。

👉 下一篇 : Day 26｜依賴與套件安全：守住軟體供應鏈的第一道防線