📚 课程目录第1章 DAST工程化认知

1. DAST工程化认知

动态应用安全测试（Dynamic Application Security Testing，DAST）是一类在应用运行状态下，从外部以攻击者视角对目标发起请求、观察响应，从而发现安全缺陷的黑盒测试技术。它不依赖源代码，也不需要编译期插桩，核心输入是可达的URL、接口、认证凭据与测试策略，核心输出是带请求/响应证据的漏洞报告。理解DAST，关键要抓住三个特征：运行时（测试对象是已部署的应用）、黑盒性（通过HTTP/HTTPS等协议交互）、证据驱动（每条漏洞都能回溯到具体的请求报文与响应差异）。

在SDLC中，DAST的位置具有明确的“右移”属性。需求与设计阶段它几乎不介入；编码阶段由SAST主导；而DAST真正发挥作用的区间是测试环境部署之后、生产发布之前，并在生产环境以被动扫描或定期巡检的方式持续运行。这意味着DAST天然处于CI/CD流水线的后段，通常作为质量门禁的一环：当扫描发现高危漏洞时，流水线应阻断发布。它与单元测试、集成测试并列，但关注点不是功能正确性，而是可被利用的安全弱点。

核心定位一句话：DAST验证的是“应用在真实运行、真实协议交互下，是否会被攻击者利用”，这是静态工具无法替代的验证维度。

与SAST、IAST、SCA的边界与协同

四类工具常被并列讨论，但它们的观测面完全不同。SAST分析源代码或字节码，属于白盒，能在编码期发现注入、硬编码密钥等问题，但误报率高、无法感知运行时配置与框架行为。SCA聚焦第三方依赖与开源组件的已知漏洞（CVE），关注的是“用了什么、版本是否受影响”。IAST通过Agent插桩，在测试执行时同时观测代码路径与运行时数据流，精度高，但需要部署Agent且依赖测试用例覆盖。DAST则完全从外部观测，能发现配置错误、认证缺陷、会话管理问题、以及只有运行时才暴露的逻辑漏洞。

它们的协同关系可以概括为：SAST与SCA负责“左移”尽早发现，IAST负责在测试期提供高精度定位，DAST负责在发布前做最终的外部可利用性验证。一个漏洞从SAST告警到DAST确认，往往经历“静态可疑→动态可复现”的收敛过程。工程化实践中，常见做法是将SAST/SCA结果与DAST结果按URL、参数、CWE编号做关联去重，避免同一问题在多个工具中重复上报。

工程化落地的核心挑战

把DAST从“偶尔跑一次的工具”变成“流水线中的稳定环节”，难点并不在扫描器本身，而在工程约束。第一是认证与会话：现代应用普遍使用SSO、JWT、多因素认证，扫描器必须能自动登录并维持会话，否则大量需要认证的接口无法覆盖。常见做法是配置登录宏（Login Macro）或注入有效Token，并设置会话失效后的重登策略。第二是爬虫覆盖率：单页应用、GraphQL、WebSocket等场景下，传统爬虫难以发现全部接口，需要结合OpenAPI/Swagger文档导入、流量录制回放或接口清单来补充攻击面。第三是误报治理：DAST的告警需要人工或规则确认，工程化要求建立漏洞基线（Baseline），只对新增漏洞阻断流水线，避免历史问题反复干扰。第四是扫描时长与资源：全量扫描可能耗时数小时，需要按模块拆分、增量扫描或夜间调度，并与CI/CD的构建节奏协调。

实践建议：初次落地DAST时，先选择1～2个非核心但接口清晰的应用做试点，重点验证“登录宏是否稳定、爬虫能否覆盖主要接口、报告是否可读”，再逐步扩展到核心业务。不要一开始就追求全量扫描和零误报。

一个可参考的扫描配置示例

以下是一个面向REST API的DAST扫描配置片段（以常见扫描器配置风格示意，参数为示例值，非实测结果）：

target: https://test.example.com/api
auth:
  type: form
  login_url: /login
  username_field: user
  password_field: pass
  success_indicator: "dashboard"
  session_check: /api/me
scan:
  mode: active
  policy: owasp-top10
  max_duration: 3600
  exclude_paths:
    - /api/logout
    - /api/health
report:
  format: [html, json]
  severity_threshold: high
  baseline: baseline.json

这份配置的关键点在于：session_check用于判断会话是否仍有效，exclude_paths避免扫描登出和健康检查接口造成副作用，baseline用于对比历史结果、只上报新增问题。扫描结束后，应重点查看三类信息：漏洞的请求/响应证据是否可复现、受影响接口是否属于本次变更范围、以及是否存在因会话失效导致的“未覆盖”告警。只有把“扫描—确认—修复—回归”串成闭环，DAST才真正具备工程价值。

总结来看，DAST不是SAST的替代品，而是SDLC右端不可省略的验证环节。它的工程化难点集中在认证、覆盖、误报和调度四个方面，解决思路是配置化、基线化和流水线化。理解这些边界与协同关系，是后续搭建DAST流水线、编写扫描策略和治理漏洞的基础。