快速摘要：Shannon 是一款开源的全自动 AI 渗透测试工具，它能像真正的黑客一样，自动对你的 Web 应用发起攻击，并且只报告那些被"实锤"验证过的真实漏洞。 它基于多智能体（Multi-Agent）架构，将渗透测试拆解为侦察、分析、利用、报告四大阶段，在 XBOW 安全基准测试中取得了 96.15% 的成功率。如果你正在用 AI 编程工具快速出活，却担心代码安全跟不上开发节奏，这个项目值得认真研究。往下看，莫潇羽@无忆研习社 会为你做一次从原理到实操的完整拆解。
一、为什么我们现在比以往更需要自动化渗透测试
过去两年，AI 编程工具的爆发让软件开发的速度有了质的飞跃。从 Claude Code 到 Cursor，再到各类 Copilot 插件，开发者们可以在几小时内完成过去可能需要一周才能搞定的功能模块，甚至连单元测试都能自动生成。对于追求快速迭代的团队来说，这无疑是巨大的效率提升。
但硬币总有两面。代码产出速度上去了，安全验证的节奏却没跟上。绝大多数组织的渗透测试仍然停留在"一年做一两次"的状态——请外部安全团队来做一轮评估，出一份报告，然后开发团队花几周时间修补。问题在于，在这两次测试之间的三百多天里，团队可能已经上线了几百个新功能、修改了数千行代码，而其中任何一行都可能引入新的安全隐患。
这种"开发在飞奔，安全在慢走"的不对称状态，造成了一个巨大的安全窗口期。在这个窗口期内，任何一个被忽略的输入验证缺失、任何一个权限检查的疏忽、任何一个不安全的 API 端点暴露，都可能成为攻击者的突破口。更值得关注的是，AI 编程工具生成的代码虽然功能上通常没有问题，但它们并不总是把安全性放在第一位——毕竟，AI 模型在生成代码时的优化目标是"让代码能运行"，而不是"让代码无法被攻破"。这意味着随着 AI 辅助编码的普及，代码库中潜在的安全隐患可能反而在悄然增多。
传统的安全解决方案在面对这个问题时显得力不从心。静态代码分析工具（SAST）虽然可以集成到持续集成流水线中，但它们的扫描基于规则匹配，误报率往往很高，开发团队常常被海量的告警淹没，真正重要的安全问题反而容易被掩盖在噪声中。动态扫描工具（DAST）需要应用处于运行状态才能测试，而且受限于爬虫算法的能力，很多需要复杂交互才能触达的功能（比如多步骤的表单提交、需要登录后才能访问的页面）往往无法被有效覆盖。手动渗透测试虽然效果理想，但耗时长，不可能跟上持续部署的节奏。
莫潇羽在 无忆研习社（www.wuyi.wiki）长期关注开源安全工具的发展，这次要给大家深入拆解的 Shannon 项目，正是为了填补这个安全缺口而生的。它的核心理念很简单：既然你在用 AI 写代码，那就也用 AI 来攻击你的代码——在真正的攻击者动手之前。
如果用一个形象的比喻来说：用 AI 写代码的开发团队是负责建设的"蓝队"，而 Shannon 就是专门负责找漏洞、搞破坏的"红队"。蓝队和红队的对抗演练，在传统网络安全领域早已是标配，但过去这些工作几乎完全依赖人工，门槛和成本都不低。Shannon 的出现，意味着这种红蓝对抗开始进入全自动化阶段，开发者不再需要等待年度安全评估，而是可以随时、按需地对自己的应用发起一次完整的安全检查。
二、Shannon 到底是什么
Shannon 是由 Keygraph 团队开发并开源的一款全自动 AI 渗透测试工具。它的项目地址位于 GitHub（https://github.com/KeygraphHQ/shannon），采用 AGPL-3.0 开源协议发布。
用官方的话来概括：Shannon 是一个全自主的 AI 渗透测试员，它的任务就是在别人之前攻破你的 Web 应用。
这里有几个关键词值得注意。
第一个是"全自主"。 你只需要一条命令就能启动整个渗透测试流程。从打开浏览器、登录应用、浏览页面、构造攻击载荷、执行漏洞利用，到最后生成一份完整的安全报告，全程不需要人工干预。它甚至能自动处理双因素认证（2FA/TOTP）和 OAuth 等复杂的登录流程——这些在传统自动化扫描器面前往往是巨大的障碍。
第二个是"实际漏洞利用"。 这是 Shannon 和市面上绝大多数安全扫描工具最本质的区别。传统扫描器的工作方式通常是基于规则匹配或模式识别，发现"疑似有问题"就标记一个告警。但这种方式会产生大量的误报（False Positive），开发团队往往要在一堆告警中大海捞针，筛选出真正有威胁的那几个。Shannon 的策略完全不同——它遵循"没有成功利用，就不写进报告"的原则。一旦怀疑某个点存在漏洞，它不是简单地告诉你"这里可能有问题"，而是真刀真枪地去构造攻击代码、执行 SQL 注入、尝试绕过身份验证，把攻破的证据直接甩出来。
第三个是"白盒测试"。 Shannon Lite（开源版本）是一个白盒渗透测试工具，这意味着它需要访问你的应用源代码。它会同时分析源代码（静态分析）和运行中的应用（动态测试），将两者的信息结合起来，做出更精准的攻击判断。
三、Shannon 的核心架构：四阶段多智能体协同
Shannon 的技术架构是整个项目最值得深入理解的部分。它模拟了人类渗透测试专家的思维逻辑，把整个测试过程拆解为四个清晰的阶段，每个阶段由专门的 AI Agent（智能体）负责执行。整个系统基于 Anthropic 的 Claude Agent SDK 构建，通过一个编排器（Orchestrator）来协调多个 Agent 的工作。
下面我们逐个阶段来看。
3.1 第一阶段：侦察（Reconnaissance）
侦察阶段是整个渗透测试的起点，目标是全面摸清目标应用的"底细"，建立一张完整的攻击面地图。
在这个阶段，Shannon 会同时做两件事情：
源代码分析：Shannon 会读取你提供的应用源代码仓库，分析其中的技术栈组成（比如使用了什么框架、什么数据库、什么中间件），识别所有的 API 端点、路由配置、认证机制，以及数据流向。
外部工具探测：与此同时，Shannon 会调用一系列专业的安全侦察工具来从"外部"视角收集信息。这些工具包括：
- Nmap：网络端口扫描的经典工具，用来探测目标服务器开放了哪些端口和服务
- Subfinder：子域名发现工具，用来枚举目标域名下的所有子域
- WhatWeb：Web 应用指纹识别工具，用来识别目标使用的具体技术和版本
- Schemathesis：API Schema 测试工具，用来对 API 接口进行自动化模糊测试
浏览器自动化探索：Shannon 内置了浏览器自动化能力，会像真实用户一样打开浏览器，在目标应用中进行点击、表单提交、页面跳转等操作，记录每一个交互行为和响应，从而将代码层面的分析与实际运行时的行为关联起来。
侦察阶段完成后，Shannon 会输出一份详细的攻击面地图，包含所有发现的入口点、API 端点、认证机制和技术栈信息。这份地图将作为后续分析和攻击阶段的基础输入。
3.2 第二阶段：漏洞分析（Vulnerability Analysis）
进入第二阶段后，Shannon 会根据侦察结果，并行启动多个专门化的 AI Agent，每个 Agent 负责一类特定的漏洞类型。
目前 Shannon Lite 已经覆盖的漏洞类型包括：
- 注入攻击（Injection）：包括 SQL 注入、命令注入等。Agent 会追踪用户输入是如何一步步传递到数据库查询或系统命令执行的，寻找可以被利用的注入点。
- 跨站脚本攻击（XSS）：Agent 会分析哪些用户输入会被反射或存储到页面中，并尝试构造能够在浏览器中执行的恶意脚本。
- 服务端请求伪造（SSRF）：Agent 会寻找应用中存在的服务器端 HTTP 请求，尝试操控这些请求去访问内部网络资源。
- 身份验证与授权失效（Broken Authentication/Authorization）：Agent 会检查登录流程、会话管理、权限控制等环节，尝试绕过认证或越权访问其他用户的数据。
这些分析 Agent 并行运行，各自独立工作，这样可以大幅缩短总体测试时间。每个 Agent 都会结合源代码的上下文信息来制定自己的分析策略——这也是白盒测试相比黑盒测试的优势所在。
3.3 第三阶段：漏洞利用（Exploitation）
这是 Shannon 最具特色的阶段，也是它和传统扫描器拉开差距的关键。
在分析阶段发现的每一个潜在漏洞，都不会直接写进报告。Shannon 会为每个漏洞假设启动专门的利用 Agent，这些 Agent 的任务是：真正地去攻击它，证明它确实可以被利用。
举个例子，如果分析 Agent 发现某个 API 端点的输入参数存在 SQL 注入的可能性，利用 Agent 就会实际构造 SQL 注入的攻击载荷（Payload），通过浏览器或命令行工具向目标发送请求，观察返回结果是否证实了注入的存在。如果注入成功——比如返回了数据库中的敏感数据——那么这个漏洞就被"实锤"了，Agent 会记录下完整的攻击过程和证据。
如果某个漏洞假设在多次尝试后无法成功利用，Shannon 就不会将其纳入最终报告。这种"不利用成功就不报告"的策略，从根本上消除了误报的问题。
这个阶段同样支持并行处理。多个利用 Agent 可以同时对不同类型的漏洞发起攻击尝试，进一步提升测试效率。
3.4 第四阶段：报告生成（Reporting）
最后一个阶段是将所有验证通过的漏洞整理成一份专业的渗透测试报告。
报告 Agent 会汇总侦察数据和所有成功的漏洞利用证据，清除其中的噪声和无关信息。最终输出的报告包含以下内容：
- 每个已确认漏洞的详细描述
- 漏洞的严重等级评估
- 完整的攻击重现步骤
- 可直接复制使用的概念验证代码（Proof of Concept）
- 修复建议
这种报告格式对于开发团队来说非常友好——拿到报告后，可以直接按照 PoC 复现问题，然后针对性地修复，不需要再花时间去验证漏洞是否真实存在。
四、Shannon 的实战表现
理论说得再好，终归要看实际效果。Shannon 在多个业内知名的漏洞靶场上进行了测试，结果相当亮眼。
4.1 OWASP Juice Shop 测试结果
OWASP Juice Shop 是由 OWASP（开放式 Web 应用安全项目）维护的一个故意设计了大量漏洞的 Web 应用，是安全工具评测中最常用的靶场之一。
Shannon 在对 Juice Shop 的单次自动化测试中，发现了超过 20 个高危漏洞。其中包括：
- 通过注入攻击实现了完整的身份验证绕过，并成功从数据库中导出了全部用户数据
- 通过注册流程的逻辑缺陷，成功创建了管理员账户，实现了完整的权限提升
- 发现并利用了多个不安全的直接对象引用（IDOR）漏洞，可以访问和修改任意用户的私有数据和购物车
- 发现了服务端请求伪造（SSRF）漏洞，能够进行内部网络侦察
4.2 Checkmarx c{api}tal API 测试结果
c{api}tal 是 Checkmarx 公司专门设计的一个包含 OWASP API 安全风险 Top 10 漏洞的 API 靶场。
Shannon 在测试中发现了近 15 个严重和高危漏洞，最终实现了对应用的完全攻陷。具体来说：
- 通过在一个隐藏的调试端点中绕过命令黑名单，成功执行了 root 级别的命令注入
- 发现并利用了一个遗留的未修补 v1 版本 API 端点，实现了完整的身份验证绕过
- 通过批量赋值（Mass Assignment）漏洞，将普通用户提升为管理员
- 正确识别了应用中 XSS 防护做得到位的部分，零误报
4.3 OWASP crAPI 测试结果
crAPI 是 OWASP 推出的另一个现代化 API 漏洞靶场。Shannon 在测试中发现了超过 15 个严重和高危漏洞：
- 使用多种高级 JWT 攻击手法（包括算法混淆、alg:none 注入、弱密钥注入）成功绕过了身份验证
- 通过注入攻击实现了完整的数据库攻陷，从 PostgreSQL 数据库中导出了用户凭据
- 成功执行了 SSRF 攻击，将内部认证令牌转发到了外部服务
4.4 XBOW 基准测试成绩
XBOW 是一个包含 104 个故意设计的漏洞应用的开源安全基准测试。Shannon Lite 在这个基准测试的"无提示、源代码可见"版本上取得了 96.15% 的成功率（104 个挑战中成功了 100 个）。
作为对比，此前在 XBOW 原始基准测试上，领先的 AI Agent 和专业人类渗透测试人员在黑盒模式下的成功率大约在 85% 左右。需要说明的是，Shannon 的测试条件（白盒、无提示清洁版）和此前的测试不完全一致，所以不能简单直接对比，但这个数字仍然展示了 Shannon 在源代码级深度分析方面的强大能力。
五、动手实操：从安装到跑完第一次渗透测试
接下来，莫潇羽@无忆研习社 带大家走一遍 Shannon 的完整实操流程。即便你是安全领域的新手，按照下面的步骤也能顺利跑起来。
5.1 环境准备
Shannon 通过 Docker 容器运行，所以你需要先确保本地安装了 Docker。
安装 Docker：如果你还没有安装 Docker，可以访问 Docker 官方网站（https://docs.docker.com/get-docker/）按照你的操作系统选择对应版本下载安装。macOS 用户安装 Docker Desktop 即可；Linux 用户通过包管理器安装。
获取 API Key：Shannon 基于 Claude Agent SDK 构建，运行时需要调用 Anthropic 的 API。你需要在 Anthropic 控制台（https://console.anthropic.com）注册账号并获取 API Key。
5.2 克隆项目并配置
打开终端，执行以下命令：
# 克隆 Shannon 仓库
git clone https://github.com/KeygraphHQ/shannon.git
# 进入项目目录
cd shannon接下来配置 API Key。你有两种方式可以选择。
方式一：通过环境变量
export ANTHROPIC_API_KEY="你的API密钥"
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000方式二：通过 .env 文件
# 复制示例配置文件
cp .env.example .env然后编辑 .env 文件，填入你的配置：
ANTHROPIC_API_KEY=你的API密钥
CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000其中 CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000 这个配置是推荐设置的，它可以防止在生成长报告时出现令牌限制的问题。
5.3 启动渗透测试
一切就绪后，只需要一条命令就能启动测试：
./shannon start URL=https://你的应用地址 REPO=/path/to/你的源代码这里有两个必需参数：
URL：你的 Web 应用的访问地址（注意是正在运行的应用地址）REPO：你的应用源代码在本地的路径
Shannon 会自动构建 Docker 容器、启动工作流，并返回一个 workflow ID。整个渗透测试过程在后台运行。
5.4 监控测试进度
测试过程中，你可以通过以下命令实时监控进度：
# 查看实时工作日志
./shannon logs
# 查询特定工作流的进度（将 ID 替换为实际返回的工作流 ID）
./shannon query ID=shannon-1234567890Shannon 还提供了一个 Web 界面用于详细监控。启动后，你可以在浏览器中访问 http://localhost:8233 来查看 Temporal Web UI，这里可以看到每个阶段的详细执行状态。
5.5 查看测试报告
测试完成后，所有结果会保存在 ./audit-logs/{主机名}_{会话ID}/ 目录下。目录结构如下：
audit-logs/{主机名}_{会话ID}/
├── session.json # 会话指标和元数据
├── agents/ # 每个 Agent 的执行日志
├── prompts/ # 提示词快照（用于可重现性）
└── deliverables/
└── comprehensive_security_assessment_report.md # 最终的综合安全评估报告最终的安全评估报告是一份 Markdown 格式的文件，包含了所有被"实锤"确认的漏洞详情、严重等级、重现步骤和 PoC 代码。
5.6 停止 Shannon
# 停止所有容器（保留工作流数据）
./shannon stop
# 完全清理（删除所有数据）
./shannon stop CLEAN=true5.7 自定义输出目录
如果你想指定报告的输出路径，可以在启动时添加 OUTPUT 参数：
./shannon start URL=https://你的应用地址 REPO=/path/to/源代码 OUTPUT=./my-reports5.8 使用配置文件（进阶）
对于需要进行认证测试的场景，Shannon 支持通过 YAML 配置文件来定义登录流程。这在测试需要登录才能访问的功能时非常有用。
首先，复制示例配置文件：
cp configs/example-config.yaml configs/my-app-config.yaml然后根据你的应用情况编辑配置。以下是一个典型的配置示例：
authentication:
login_type: form
login_url: "https://你的应用.com/login"
credentials:
username: "test@example.com"
password: "yourpassword"
totp_secret: "LB2E2RX7XFHSTGCK" # 如果应用启用了双因素认证
login_flow:
- "在邮箱输入框中输入 $username"
- "在密码输入框中输入 $password"
- "点击'登录'按钮"
success_condition:
type: url_contains
value: "/dashboard"
rules:
avoid:
- description: "跳过注销功能的测试"
type: path
url_path: "/logout"
focus:
- description: "重点测试 API 端点"
type: path
url_path: "/api"配置文件中有几个值得注意的要点：
登录流程定义（login_flow）：你可以用自然语言描述登录步骤，Shannon 的 AI 会理解并执行这些操作。这比传统工具通过 CSS 选择器定位元素的方式灵活很多。
TOTP 支持：如果你的应用启用了双因素认证，只需在配置中填入 TOTP Secret，Shannon 会在测试过程中自动生成验证码。
规则配置（rules）：你可以指定 Shannon 应该避免测试的路径（比如注销功能，以免测试过程中被踢出登录态）和重点测试的路径。
使用配置文件启动测试：
./shannon start URL=https://你的应用.com REPO=/path/to/源代码 CONFIG=./configs/my-app-config.yaml六、测试本地应用的注意事项
如果你要测试的是运行在本地的应用（比如 localhost:3000），需要注意一个技术细节：Shannon 运行在 Docker 容器内部，容器中的 localhost 指的是容器自身的网络命名空间，而不是你的宿主机。这是 Docker 网络隔离机制导致的，初学者经常在这里踩坑。
解决方法是使用 host.docker.internal 来替代 localhost：
./shannon start URL=http://host.docker.internal:3000 REPO=/path/to/源代码这个地址在 Docker Desktop（macOS / Windows）中可以直接使用。Linux 用户可能需要额外配置 Docker 网络，或者在 docker run 命令中添加 --add-host=host.docker.internal:host-gateway 参数。如果你使用的是 docker-compose，也可以在服务配置中添加 extra_hosts 来实现相同的效果。
如果你的本地应用监听在某个特定的网络接口上（比如只监听 127.0.0.1），可能还需要将其修改为监听 0.0.0.0，这样 Docker 容器才能通过宿主机的 IP 地址访问到应用。
关于多仓库应用的处理
在实际项目中，很多现代 Web 应用采用前后端分离的架构，前端代码和后端代码可能位于不同的 Git 仓库中。Shannon 的 REPO 参数期望接收一个包含所有应用代码的目录路径。对于这种多仓库的情况，官方推荐的做法是将所有相关仓库克隆到同一个父目录下：
# 创建一个统一的代码目录
mkdir /path/to/my-app
cd /path/to/my-app
# 克隆所有相关仓库到这个目录下
git clone https://github.com/your-org/frontend.git
git clone https://github.com/your-org/backend.git
git clone https://github.com/your-org/api-gateway.git然后在启动 Shannon 时，将 REPO 指向这个父目录：
./shannon start URL=http://host.docker.internal:3000 REPO=/path/to/my-app这样 Shannon 就能同时分析前端和后端的源代码，获得更全面的攻击面视图。
关于 Linux 用户的权限问题
在 Linux 系统上，如果你遇到了权限相关的错误（比如无法写入输出文件），可能需要使用 sudo 来运行 Shannon 命令，或者确保你的用户账户已经被添加到了 docker 用户组中。可以通过以下命令将当前用户添加到 docker 组：
sudo usermod -aG docker $USER添加后需要重新登录终端才能生效。
另外还有一个关键提醒，莫潇羽@无忆研习社 必须重点强调一下：Shannon 执行的是真实的攻击操作，会对目标应用的数据产生不可逆的修改（比如创建新用户、修改数据、删除记录等）。所以：
- 绝对不要在生产环境运行 Shannon
- 始终在本地开发环境或专门的测试环境中进行测试
- 测试前最好对数据库做一个快照或备份，以便测试后恢复到干净状态
- 确保你对测试目标拥有明确的授权
- 如果可能的话，使用一份独立的测试数据库，避免测试数据污染开发数据
七、深入理解 Shannon 覆盖的漏洞类型
为了帮助不太熟悉安全领域的读者更好地理解 Shannon 的能力范围，这里对它目前覆盖的四大类漏洞做一些展开说明。这些漏洞类型都属于 OWASP Top 10（Web 应用安全十大风险）中的高危项目。
7.1 注入攻击（Injection）
注入攻击是 Web 安全领域最经典也最危险的漏洞类型之一。它的原理是攻击者通过在用户输入中嵌入恶意代码，使得后端系统将这些输入当作指令来执行。
最常见的是 SQL 注入。举个简化的例子：如果一个登录接口直接将用户输入拼接到 SQL 查询中，攻击者就可以通过输入特殊构造的字符串来绕过密码验证，甚至直接读取整个数据库的内容。
命令注入的原理类似，只不过注入目标从数据库查询变成了操作系统命令。如果应用在某些功能中需要调用系统命令（比如文件处理、网络工具调用等），而没有对用户输入做严格过滤，攻击者就可能通过注入来执行任意系统命令。
Shannon 的注入 Agent 会从源代码层面追踪数据流——用户输入从哪里进来，经过了哪些处理，最终到达了哪个数据库查询或命令执行点——然后构造针对性的攻击载荷进行验证。
7.2 跨站脚本攻击（XSS）
XSS 攻击的核心是让浏览器执行攻击者注入的 JavaScript 代码。根据注入方式的不同，XSS 可以分为反射型（用户点击恶意链接时触发）、存储型（恶意脚本被存入数据库，其他用户访问时触发）和 DOM 型（在前端 JavaScript 处理过程中触发）。
XSS 的危害包括窃取用户的 Cookie 和会话信息、冒充用户执行操作、重定向到钓鱼页面等。
Shannon 的 XSS Agent 会分析应用中哪些用户输入最终会被渲染到页面上，然后尝试注入各种 XSS 载荷来验证是否能成功执行。
7.3 服务端请求伪造（SSRF）
SSRF 是一种利用服务器端 HTTP 请求的漏洞。当应用需要根据用户提供的 URL 去获取资源时（比如图片下载、网页预览、Webhook 回调等），如果没有对 URL 做严格校验，攻击者就可以操控这个请求去访问内部网络中的敏感服务，比如云服务的元数据接口、内部管理后台、数据库服务等。
在云原生架构越来越普及的今天，SSRF 的危害被进一步放大，因为很多云服务的元数据接口（如 AWS 的 169.254.169.254）可以通过 SSRF 被直接访问，从而泄露敏感的凭据信息。在 OWASP Top 10:2025 版本中，SSRF 已经被合并到了排名第一的"访问控制失效"类别中。
7.4 身份验证与授权失效（Broken Authentication/Authorization）
这类漏洞涵盖的范围比较广，包括但不限于：
- 弱密码策略和暴力破解防护缺失
- 会话管理不当（会话固定、会话劫持）
- JWT（JSON Web Token）实现缺陷
- 越权访问（水平越权和垂直越权）
- 多因素认证绕过
- 密码重置流程缺陷
Shannon 的认证 Agent 会从多个角度探测认证和授权机制的薄弱环节。从前面的测试结果中可以看到，它成功绕过了多种 JWT 实现、发现了 IDOR（不安全的直接对象引用）漏洞、利用了批量赋值漏洞提升权限等。
八、Shannon 与传统安全扫描工具的区别
为了帮助大家更清晰地理解 Shannon 的定位，莫潇羽@无忆研习社 在这里做一个详细的对比分析。不同类型的安全测试工具各有所长，理解它们之间的差异有助于你选择最合适的工具组合。
传统静态分析工具（SAST），如 SonarQube、Semgrep、Checkmarx 等，它们的工作方式是扫描源代码中的模式匹配，找出"看起来有问题"的代码片段。比如，SAST 工具会检查代码中是否存在直接将用户输入拼接到 SQL 查询中的写法，如果发现了就标记一个告警。这类工具的优点是速度快、可以集成到 IDE 和 CI/CD 流水线中做到实时反馈，但缺点也很明显——误报率高是最大的痛点。很多被标记的"问题"在实际运行环境中可能根本无法被触发，因为可能有其他层的防护（比如 WAF、输入过滤中间件等）在阻止攻击。开发团队长期被大量误报困扰后，容易产生"告警疲劳"，反而对真正的安全问题变得麻木。
传统动态扫描工具（DAST），如 OWASP ZAP、Burp Suite、Acunetix 等，它们的工作方式是向运行中的应用发送各种测试请求，通过观察应用返回的响应来判断是否存在漏洞。比如，DAST 工具会在表单的输入框中尝试提交各种 SQL 注入载荷，然后检查返回页面中是否出现了数据库错误信息。这类工具的优点是能发现运行时的真实问题，不依赖源代码。但缺点在于：首先，没有源代码的上下文信息，它无法理解应用的内部逻辑和数据流，只能"黑盒"地试探；其次，测试覆盖率受限于爬虫能发现
