从 Burp Suite Professional 到 DAST：把 Web 安全测试接入持续 AppSec 的工程化路径

本文承接此前"人工掌控测试深度"和"自动化释放专业判断力"两类 Burp Suite 内容，继续回答第三个问题：当测试对象从一个项目变成整个应用组合，Burp 的能力怎样进入组织级、持续化流程？

1. 从"会不会测"到"能不能持续运行"

Burp Suite Professional 更贴近测试人员的桌面工作流：通过 Proxy 观察流量，在 Repeater 中控制变量，用 Scanner 扩大检查范围，再回到人工验证上下文。

当企业只有少量目标时，这套模式可以围绕项目逐一展开。但资产数量、团队数量和发布频率上升后，问题会发生变化：

哪些 Web 应用和 API 已经进入测试范围？
同一配置何时重新扫描，怎样比较前后变化？
哪个团队能看到、启动或处理哪些站点？
代码变更后，扫描由谁触发？结果回到哪里？

这正是 Burp Suite DAST 与 Professional 的边界所在。前者并不是简单把桌面扫描器放到一台更大的服务器，而是围绕站点、计划、权限、集成和报告建立持续运行能力。PortSwigger 官方资料说明，Burp Suite DAST 与 Professional 使用 Burp Scanner 技术，但两款产品面向的使用方式和交付能力并不相同。

概念图：单次扫描提供快照，持续 AppSec 需要扫描、分诊、修复和复测形成反馈循环。

2. 第一条路径：用站点模型组织规模化扫描

在 DAST 中，Web 应用或 API 先作为 Site 纳入管理。团队可以为站点定义扫描范围、排除 URL、认证方式、通知和扫描配置，再安排定期扫描。

这里有一个容易被忽略的工程价值：**同一对象以相同配置按固定节奏运行，更适合比较变化。**

一次性扫描可以告诉我们某个时间点发现了什么，却很难单独回答以下问题：

新版本引入了哪些问题？
哪些问题已被修复？
哪些问题在后续版本中回归？
某个业务组合的高风险问题是增加还是减少？

Burp Suite DAST 支持用文件夹组织站点，并在文件夹级看板查看不同严重等级的当前问题，以及新增、解决和回归问题的变化。文件夹还可用于限制用户对特定站点组合的访问。

这使"资产清单"从一张静态表格变成可运行对象：每个站点不只是一个 URL，还关联范围、认证、扫描策略、执行记录和问题状态。

适合重点评估的能力

资产组织方式：能否按业务线、区域、环境或责任团队建立层级？
认证与范围：登录流程、排除路径和测试账户能否稳定维护？
扫描节奏：夜间、每周、版本前或按风险等级的策略如何区分？
趋势口径：比较是否基于同一目标、同一配置和相近环境？
权限控制：RBAC、LDAP/SAML SSO、SCIM 与现有身份体系如何配合？

需要注意的是，看板展示"问题数量下降"不一定直接证明安全水平提高。扫描范围变化、认证失效、配置调整或资产下线都可能改变数据。趋势必须与范围和配置一起解释。

3. 第二条路径：让 CI/CD 触发动态扫描

定期扫描解决的是"按节奏复查"，CI-driven scan 解决的是"按变更触发"。PortSwigger 官方文档说明，Burp Suite DAST 可以通过 Docker 容器在支持 Docker 的 CI/CD 环境中运行扫描，结果可输出为 JUnit XML 或 Burp XML，也可以在配置关联信息后进入 DAST 看板。

一个简化的流程可以表示为：

复制代码

代码变更
  -> 构建并部署到受控测试环境
  -> CI 启动 DAST 扫描
  -> 输出 JUnit/Burp XML
  -> 按严重性和置信度执行门槛判断
  -> 问题进入 AppSec 看板或缺陷跟踪系统
  -> 开发修复并再次验证

阈值不是越严越好

CI-driven scan 的配置支持启用报告阈值，并按最低严重性、最低置信度决定扫描步骤是否返回非零退出码。官方文档中的相关字段包括：

复制代码

reporting.threshold.enabled
threshold.minimumSeverity
threshold.minimumConfidence

其中严重性可配置到 INFO、LOW、MEDIUM、HIGH，置信度可配置为 TENTATIVE、FIRM、CERTAIN。实际字段结构和默认值应以部署版本的官方 schema 为准。

工程上不建议把所有发现都设成阻断条件。更合理的分层通常是：

高严重性且高置信度：阻断或进入紧急人工确认；
中等风险：创建工单，限定处理时限；
低风险或暂定问题：保留证据，进入常规分诊；
已接受风险或明确误报：按有审批记录的规则处理，而不是静默忽略。

否则"安全左移"很容易变成"告警左移"：开发更早看到大量噪声，但真正重要的问题仍然没有更快解决。

4. 结果必须回到责任人，而不只是回到看板

Burp Suite DAST 可与 Jira、GitLab、Trello 等问题跟踪平台集成，也提供 GraphQL API。其价值不在于多一个连接器，而在于把安全问题变成研发流程中可分配、可追踪、可关闭和可复测的工作项。

建议为每个进入缺陷系统的问题保留以下信息：

受影响站点、环境与版本；
发现时间与扫描配置；
严重性和置信度；
请求/响应证据及必要的脱敏；
复现条件和影响边界；
责任团队、状态和复测结果。

如果缺少这些上下文，自动建单只会把"报告搬运"升级为"工单搬运"。

5. DAST 在持续 AppSec 中负责什么、不负责什么

DAST 从运行中的应用外部观察行为，尤其适合验证真实 HTTP 交互、认证后功能和可从外部触达的漏洞。它不需要读取源代码，但也因此看不到所有代码路径和依赖风险。

一个较完整的组合通常包括：

|------|-------------|-------------------|
| 方法 | 主要观察对象 | 适合解决的问题 |
| DAST | 运行中的Web/API | 外部可触达漏洞、认证于运行态交互 |
| SAST | 源代码或中间表示 | 代码级缺陷和不安全模式 |
| SCA | 依赖与组件清单 | 已知组件漏洞、许可证与供应链风险 |
| 人工测试 | 业务逻辑和上下文 | 越权、流程绕过、组合攻击与影响验证 |
| 威胁规模 | 架构、资产与信任边界 | 设计阶段的风险识别与控制选择 |

因此，Burp Suite DAST 更适合作为持续 AppSec 的一部分，而不是"买一个工具包办所有安全"。

6. 落地前的最小检查清单

在试用或采购前，建议用真实但受控的目标完成验证：

选取一套 JavaScript 较重、带登录和 API 的测试应用；
明确系统所有者授权、允许的主动测试范围和时间窗口；
准备稳定账号、测试数据和可重复部署的环境；
分别运行定期扫描与 CI 触发扫描；
验证扫描结果能否正确关联站点、输出报告并进入问题系统；
用一组已知问题检验覆盖、证据质量和门槛行为；
记录配置成本、扫描耗时、误报处理和复测流程；
再决定部署方式、并发能力、角色权限和授权范围。

动态扫描具有主动交互风险。不要对未授权目标执行测试；对脆弱系统应做好备份、隔离和风险接受。生产环境是否允许主动扫描，应由系统所有者、安全与业务负责人共同决定。

结语

Burp Suite Professional 解决的是测试人员如何看得更细、验证得更深；Burp Suite DAST 进一步回答的是这些能力如何在更多资产、更快发布和更多角色之间持续运行。

规模化持续 AppSec 的核心并不是"扫描次数更多"，而是三件事：目标始终在清单里，结果始终能比较，问题始终回到责任人。

如果团队正在评估相关方案，可进一步查看 $Burp Suite 的版本、授权与适用范围$