AI 安全测试能取代 SAST、DAST 和渗透测试吗？

真正有用的问题是，智能体在哪些方面值得信任。我相信它可以扩大审查覆盖面，串联跨文件的线索，生成有针对性的测试，并把难懂的扫描器追踪信息转化为开发人员能理解的修复建议。我不相信它能仅凭路由名称推断公司的授权规则，证明每一道租户边界都可靠，或在没有人说明规则的情况下判断某个奇怪的财务流程是否构成滥用。应把智能体视为分层测试方案中的主动审查者，而不是整套方案本身。

智能体审查是解释器，不是新的测试类别

AI 智能体改变的是收集和理解证据的方式，不会创造新的证据类型。如果它在不运行应用的情况下阅读源代码，做的是更灵活的静态审查。如果它向运行中的目标发送请求，做的是动态测试。如果它探索目标、调整策略并追踪意外行为，它会像渗透测试人员，但相似并不等于拥有测试人员的授权或业务背景。

当供应商声称其智能体“取代扫描器”时，这一区别十分重要。应询问系统实际能观察到什么。它能拿到完整代码库、生成的代码、构建标志、基础设施策略和依赖项锁定文件吗？它能以多个用户身份完成认证，并在每次请求后核验数据库状态吗？它是否知道哪些操作因政策而被禁止，而不仅是界面中没有提供？再精美的解释也无法弥补缺失的输入。

智能体确实擅长关联微弱信号。传统规则可能会标出某个请求参数流向查询构建器。智能体可以检查封装层，发现某个调用点遗漏了租户条件，起草测试请求，并解释为何看似安全的辅助函数在这条路径上并不安全。它也能在值实际经过参数化 API 时排除候选问题。这是更好的分诊，不代表静态或动态分析已经过时。

明确的分界在于审查和验证。审查提出的问题是：“根据我能看到的材料，这个实现看起来是否不安全？”验证提出的问题是：“在给定条件下，这个行为者能否造成被禁止的结果？”AI 能协助两者，但安全门禁应记录它究竟提出了哪一种主张。团队会在两种情况下受损：把言之成理的审查观察升级为已验证的漏洞利用，或把一次失败的漏洞利用尝试当作安全证明。

模型行为还带来另一层区别：能力不等于可重复性。智能体可能在一次运行中发现隐蔽路径，却在模型、提示词、检索索引或工具策略变化后漏掉它。只要结果重要，就应保留提示词、工具权限、检索到的文件、生成的请求和模型标识符。然后把已确认的发现转化为测试，使其通过条件不依赖模型再次想起自己的思路。

SAST 仍负责可重复的源码覆盖

SAST 仍是为大型代码库中每一次变更应用稳定检查的最低成本方式。它可以枚举源点和汇点，强制禁止使用的 API，检查数据流，并报告所分析的准确版本。确定性规则明天也会产生同样的结果，这对需要可审计理由来决定发布通过或失败的门禁很重要。

智能体能补上规则引擎常缺少的上下文。它可以追踪项目特有的封装，带着质疑阅读注释，对比一个处理器与相邻处理器，并为新模式提出查询。它能发现可疑遗漏，例如九个端点都调用 authorizeProject()，第十个却直接加载记录。当生成的代码或陌生框架让标准规则包失效时，它也很有帮助。

但智能体的源码覆盖通常更难证明。上下文窗口、检索排序、被忽略的文件、生成产物和工具超时都可能导致代码未被阅读。要求“审查此代码库中的注入问题”并不能证明每个汇点都被触及。SAST 报告至少能说明分析了哪些文件、规则和版本。智能体在接管强制门禁前，也需要同等的覆盖账本。

NIST SP 800-218 的建议很合理：尽早使用代码分析，并人工验证安全功能和缓解措施。价值来自组合。稳定规则能在每次提交时捕获已知缺陷形态，智能体调查例外情况、编写聚焦的回归测试，并在相同模式反复出现时协助调优规则。因为智能体找到了几个巧妙漏洞就移除 SAST，是用可衡量的广度换取令人印象深刻的个案。

SAST 还能看到运行中的测试可能永远触及不到的代码：错误路径、功能标志、迁移工具、闲置的管理端点和平台特定分支。它无法告诉你部署环境是否启用了这些路径。这种不确定性说明应增加运行时证据，而不是丢弃静态覆盖。

并非所有内容都适合放进会阻断发布的 SAST 规则。针对被禁用加密原语的精确模式可立即阻断。宽泛的启发式规则，例如授权检查“看上去是否足够接近”，通常应先创建审查任务，直到团队测量其精度。智能体可以通过收集真实示例、反例以及该代码库中常见的封装函数，帮助把启发式规则升级为正式规则。这样既能保持门禁严格，也不会让开发人员学会忽略它。

生成的修复和发现一样需要审查。模型可能在错误层级添加验证来消除污点追踪，捕获异常后以开放状态继续运行，或替换危险调用时改变行为。应针对补丁运行原始验证过程，运行正常的功能测试，并审查建立信任的新控制点。干净的重新扫描只能证明原来的规则不再匹配。

DAST 证明代码库无法揭示的行为

DAST 观察实际运行的应用，包括代理规则、标头、序列化、身份验证中间件、框架默认设置和部署错误。源码审查可以说某个端点似乎受保护。动态测试可以显示，生产路由因网关重写路径而绕过了中间件。

智能体能让动态测试不再那么粗放。向它提供 API 说明、测试身份、允许范围和可随时销毁的环境，它就能构建请求序列，而不是泛滥地发送通用载荷。它能把一个响应中的资源标识符带入下一个请求，刷新会话，比对两个角色，并检查一次写入是否改变了后续读取。有状态流程正是传统 DAST 经常难以处理的地方。

智能体仍需要严格的运行限制。爬虫不知道发送邮件、创建货件或调用付费集成是否安全。测试环境仍可能连接真实服务。应在模型提示词之外定义允许的主机、账户、请求速率、破坏性操作和停止条件，并由运行器强制执行。写一句“避免危险操作”不是控制措施。

对于安全标头、暴露文件、反射输入、常见注入探测和 TLS 配置等成熟检查，应保留传统动态基线。这些检查成本低、可在不同发布之间比较，也容易观察趋势。让智能体把预算花在已认证路径和连续行为上。如果两个系统都覆盖同一个简单探测，保留证据更清晰、波动更小的那个。

DAST 也会带来完整性的错觉，因为它只报告自己触及的内容。应随结果记录路由覆盖、所用身份、功能标志和种子数据。对一个几乎为空的账户进行干净扫描，几乎无法说明某个应用是否安全，因为它的危险分支可能只会在审批、邀请、计费或数据导入后出现。

身份验证设置应有独立证据。记录测试如何获得每个会话，测试环境绕过了哪些第二因素或设备检查，以及令牌的声明和寿命是否与生产令牌相同。手工制作的管理员令牌可带来有用覆盖，但也会跳过需要测试的会话和权限转换。应在报告中清楚标出这些捷径。

动态复测应从保存的请求序列开始，而不是重新启动自主爬取。针对修复后的构建重放已确认的验证过程，确认被禁止的效果已经停止，再改变相邻输入以发现过于狭窄的过滤。之后再让智能体探索。这个顺序区分了“修复阻断了已知漏洞利用”和更广泛的主张，即缺陷类别已经消除。

授权测试需要身份与禁止结果

授权不是“端点曾返回过一次 403”。有用的测试应说明谁在行动、目标对象是什么、尝试了什么操作，以及什么结果必须始终不可能发生。智能体可以生成各种组合，但产品负责人和安全审查者必须提供策略。

OWASP ASVS 要求应用在可信服务层执行访问控制，并对功能和数据应用最小权限原则。我认同服务层要求，但团队经常验证得过于狭窄。他们测试可见的 HTTP 处理器，却忘了后台任务、导出、搜索索引、WebSocket 订阅和直接对象存储 URL。相同策略必须在通往对象的每条路径中都能成立。

一个小型可执行矩阵比模糊地要求“测试 IDOR”暴露得更多。下面的 shell 片段假定有可随时销毁的环境、两个 bearer token，以及一份属于用户 A 的文档。它同时检查状态码，以及 B 的响应中不存在 A 的秘密标记：

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

预期输出为空，退出状态为零。CI 失败时应保留状态码、脱敏后的响应正文、行为者身份、目标所有者、路由和构建版本。不要保留真实凭据或无关的响应数据。

然后每次改变一个维度：读取与更新、直接 ID 与搜索、有效成员资格与已撤销成员资格、正常路由与导出、用户令牌与服务令牌。智能体能高效生成并运行这些用例。人工必须审查矩阵是否符合策略，以及 404、403、空结果还是经过脱敏的对象才是预期结果。否则智能体可能会为业务认定为泄露的行为叫好。

负面证据需要谨慎处理。被拒绝的更新仍可能通过响应时间、错误文本或版本计数器泄露对象是否存在。被拒绝的读取可能增加浏览次数，或写入包含秘密元数据的审计记录。应先决定允许哪些副作用，再进行断言。只检查响应的安全测试可能漏掉有用的枚举通道或破坏性写入。

还要测试会话期间的策略变化。将用户移出项目、转移所有权、禁用账户或收窄服务角色，然后复用旧令牌并保持连接。预期撤销时间必须来自产品策略。“最终会生效”无法测试，立即撤销也未必必要，但团队必须选定时间上限，并在 API 请求、排队工作、下载和实时订阅中验证它。

租户隔离会在显而易见的请求路径之外失效

租户隔离需要在存储、缓存、队列、搜索、文件、分析和管理边界进行测试。常见失败不是主列表端点中缺少 tenant_id，而是某条辅助路径在复制、索引、缓存或导出数据时没有携带租户上下文。

先准备两个刻意包含相似记录、但各自带有醒目标记的租户。使用不同用户、不同会话，并在架构允许时使用不同服务凭据。覆盖创建、读取、更新、删除、列表、搜索、导出、导入、附件访问、通知投递和后台处理。每次操作后，都检查用户可见响应和持久状态。被拒绝的请求若仍排入跨租户任务，就是失败。

智能体很有帮助，因为它能在各层中追踪标识符，并生成让人感到繁琐的排列组合。它能发现缓存键只用了 document_id，而数据库查询同时使用 tenant_id 和 document_id。它还可以比较导出工作器和交互式处理器，并追问为何只有一个设置了行级上下文。这些都是高价值的审查动作。

但它也会作出危险假设：名称意味着边界。名为 getTenantDocument 的函数可能接受来自请求的任意租户参数。数据库策略可能存在于迁移中，却没有应用到新表。搜索过滤器可能在计算结果数量后才生效，从而泄露另一个租户的活动。验证必须检查实际强制执行的条件，然后尝试跨租户读写。

不要让智能体通过阅读它所测试的同一份代码来创建自己的判定标准。预期访问权限应来自与产品需求一同维护的独立策略表。如果实现和测试都误解了同一规则，它们会完全一致，同时仍在暴露数据。

异步路径需要延迟断言。以租户 A 的身份触发导出、通知、缩略图或索引任务，在工作器运行前改变所有权或成员资格，然后检查结果落在何处。应决定工作器使用请求时捕获的权限，还是在执行时重新检查当前权限。对特定操作而言，两种选择都可能正确，但意外混用会造成泄露和损坏的审计线索。

管理工具应使用独立身份并断言日志。支持访问本来就可能跨越租户边界，因此简单规定“不同租户必须失败”并不正确。应测试操作员是否具备所需角色和工单上下文，是否遵循面向客户的策略，访问是否会过期，以及审计事件是否识别操作员而非冒充客户。

业务逻辑需要一个关于滥用的故事

业务逻辑测试从一个被禁止的故事开始：用户通过以无效顺序或组合执行有效操作，获得了本不该得到的价值、权限或状态。通用漏洞标签太弱。测试人员需要知道邀请、审批、配额、退款、额度、所有权转移和取消应如何相互作用。

OWASP Web Security Testing Guide 建议测试人员尝试跳过工作流步骤、重复功能、伪造请求、改变时序和滥用有效功能。其较早的业务逻辑介绍直言，扫描器自动化无法提供应用特有的知识或创造力。现代智能体改进了自动化，但没有消除知识鸿沟。模型可以建议优惠券可能被重复使用，但在有人说明规则前，它无法知道重复使用是促销还是欺诈。

为智能体提供包含允许状态转换和不变量的状态模型。对于审批流程，一个不变量可以是：“请求者不能批准自己的付款，即使在所有权转移后也不能。”然后要求它生成涉及角色变更、重复请求、取消、重试、并发和过期会话的序列。智能体能探索远多于人工手动执行的序列。

难点在于 HTTP 响应之外的后果。两个并发兑换请求可能都返回成功，之后的对账才会撤销其中一个。取消操作可能停止可见任务，却未撤销已签名下载。邀请人在失去访问权限后才接受邀请，可能产生孤立成员资格。测试必须观察账本、队列、对象权限和后续状态，而不只是状态码。

人工测试人员的价值在于质疑既定模型。他们会问支持人员能否组合原本无害的功能，操作员能否影响自己的审计记录，或某个“已过期”对象是否能通过另一条通道继续使用。智能体会在获得的目标和工具范围内工作。人能发现目标遗漏了业务中最危险的部分。

依赖项风险不止于易受攻击的版本

依赖项测试包含四个独立问题：有哪些包，已知版本是否带有已报告漏洞，构建是否获得了预期产物，以及应用是否实际暴露了易受攻击行为。软件组成分析（SCA）和来源控制比单纯的对话式审查更可靠地回答前三个问题。

在清单存在后，智能体很有用。它可以检查如何调用依赖项，判断受影响函数是否可达，寻找补偿性控制，并起草包含回归测试的升级补丁。它还可以标出没有漏洞标识符的高风险包行为，例如安装脚本获得网络访问权限，或新库在环境中接收到秘密信息。

不要要求模型回忆当前漏洞数据。应向它提供带时间戳的公告源、已解析的锁定文件和构建产物清单。模型记忆不是漏洞数据库，包清单也不能证明实际发布了什么。SLSA 来源证明提出了相关区别：来源描述产物在何时、何地、如何生成，不声明产物安全。

可达性可以降低分诊优先级，但不应消除责任。功能标志会变化，死代码可能复活，间接依赖项也会以意想不到的方式被调用。应记录为何延期某项发现、评估了哪个版本和调用路径，以及什么事件应重新打开它。智能体可以维护这套推理，确定性清单则监测触发事件。

包名也会造成身份陷阱。名称符合预期的依赖项可能来自错误的注册表，锁定文件可能指向可变位置，构建步骤也可能下载清单中没有的代码。应检查已解析的来源、哈希、生态系统支持时的签名，以及构建网络访问。智能体可以解释差异，但构建系统必须强制规定接受哪些来源。

升级并不自动意味着安全改动。安全版本可能改变解析、授权默认设置或序列化方式，从而破坏应用。应针对公告生成最小复现，在隔离分支中应用升级，并运行安全验证和功能测试。由此得到的证据能支持决策，模型说新版本“应该兼容”则不能。

误报是证据设计问题

一项发现只有带有主张、证据、影响和可复现路径，才值得开发人员投入时间。AI 生成的报告常常看似完整，却缺少其中一项。流畅的修复文本会让薄弱证据更不易被察觉。

应要求每项智能体发现说明被分析的版本和环境、受影响组件、攻击者前提条件、跨越的安全边界、观察到或推断出的结果、复现步骤和不确定性。把推断出的源码发现与已执行的漏洞利用明确区分。如果智能体无法运行应用，它应在发现中说明，而不是把限制藏在扫描级别的注释里。

接着采用简单的处置词汇：已确认、很可能、需要上下文、无法复现、已接受风险或已修复。“误报”应指安全主张错误，而不是团队不认可严重程度或决定延期处理。混淆这些决定会破坏反馈。如果每张不想要的工单都得到同一个标签，智能体就无法了解哪条规则失败了。

AI 可以通过聚类重复追踪、检查净化器和修复后复测来减少噪声。它也可能把一个微弱怀疑扩写成十个貌似有说服力的变体。应按根本原因和边界去重，而不是按 URL。一个被八个端点使用的缺失所有权检查，是一个工程缺陷，暴露点有八处。

按类别和测试来源跟踪精度。如果智能体生成的跨站脚本报告通常有效，而其竞争条件主张很少能复现，就应以不同方式处理它们。不要用一个分数衡量无关的缺陷类型。门禁应依据证据和策略失败，而不是依据模型的置信度形容词。

责任归属让闭环完成。每项已接受的发现都需要一位负责修复的人员或团队、预期的复测方法，以及另一位测试人员能运行的保留验证过程。如果报告只存在于智能体对话中，它会随着对话、模型或供应商的变化而消失。证据能脱离产生它的工具而留存，安全工作才会持久。

分诊期间也要重视隐私。源代码、请求正文、日志和数据库样本可能含有凭据或客户数据。应尽量减少提供给智能体的内容，对保留的记录脱敏，把测试数据与生产数据分开，并将组织批准的数据处理规则应用于模型提供商及其工具。更好的检测能力不能成为把整个生产事故复制进不受控提示词的理由。

人工渗透测试检验测试本身的假设

熟练的渗透测试人员会在应用与测试简报相矛盾时改变计划。这正是智能体尚未取代的部分。人会访谈负责人，澄清模糊规则，注意到运营捷径，请求另一个身份，并决定何时值得针对异常行为展开更长的实验链。

人也要对不完整证据下的判断负责。他们能区分技术上可能的操作和可信的攻击路径，向管理层和工程师解释复合失败，并在利用可能损害数据时协商安全的验证方式。自主智能体必须在操作人员设定的边界处停止。如果它悄悄扩张边界，它就成了另一项安全风险。

这并不表示每次发布都需要一周的外部测试。应在人为变更和后果交汇处采用人工测试：新的授权模型、租户架构、支付或额度流程、管理平面、敏感集成、重大迁移或公开发布。基于风险安排更广泛的定期工作，并复测严重修复。常规发布仍需要自动化覆盖。

向测试人员提供智能体输出、SAST 追踪、DAST 覆盖、架构说明、测试账户和未解决的假设。智能体可处理侦察和重复变体，测试人员则追查意外行为。这能提升人工时间的产出，而不假装人工已不再必要。

要警惕按发现数量衡量的“自主渗透测试”说法。十个熟悉的注入发现，不等于一条已证明的路径穿过角色分配、过期授权和导出存储。应按测试过的边界、证据质量和受到质疑的重要假设来评估工作。

在测试开始前就要确认谁负责清理。测试账户、上传的文件、排队消息、临时角色和修改过的功能标志都可能在扫描后继续存在。人工负责人应批准破坏性验证过程，保持与运营团队的联系，并确认恢复完成。智能体可以执行清理脚本，却无法判断无法解释的生产状态是否可以安全删除。

好的测试人员还会报告哪些内容无法测试。缺少移动端构建、无法获得的角色、速率限制、第三方回调和不稳定环境都会降低保障程度。智能体往往会绕过障碍继续工作，并呈现已完成的路径。最终报告必须突出排除项，避免把干净结果误解为完整覆盖。

用多种证据建立一道门禁

正确的方案会为每种方法分配职责，并让其输出汇聚到同一组安全要求。SAST 用于确定性的源码模式和广泛变更覆盖。SCA 和来源证明用于依赖项和构建事实。DAST 用于已部署行为和基线运行时检查。智能体用于连接证据、探索已认证流程、创建测试和改进分诊。人工负责定义策略、质疑业务假设，以及调查高后果变更。

这样，发布策略就可以足够具体。当确定性的高严重性规则匹配未经批准的路径、必需的授权不变量失败、出现跨租户标记，或已确认的漏洞利用仍未关闭时，应阻断构建。对不确定的智能体发现，应根据暴露程度设定审查期限。不要让模型自报的置信度决定生产是否发布。

应让证据可移植。以团队无需依赖智能体即可检查的格式导出发现、生成的测试、请求记录、工具版本、版本号、身份、覆盖情况和处置结果。这对审计、事故复盘、供应商变更，以及模型更新改变行为的普通一天都很重要。

对于通过聊天创建的应用，同样需要这种分离。Koder.ai 可以生成 Web、服务器和移动应用并导出其源码，但生成的软件仍需要明确的安全要求，以及针对已部署结果的独立测试。快速创建让清晰的门禁更有价值，因为架构和代码都可能迅速变化。

让智能体持续运行，但把它最好的发现升级为确定性的回归测试。每个已确认的授权绕过都应成为一条策略用例。每个租户泄露都应在失败边界加入一项不变量。每条嘈杂规则都应获得记录在案的处置结果。随着时间推移，智能体应让测试系统比它刚接手时更精确。

不要问哪一种单一工具获胜。应问每一项重要主张是否拥有独立证据：代码路径已被审查，已部署行为经过实际测试，业务规则来自负责人，并且在失败会造成伤害的地方有人质疑过假设。如果其中一行为空，AI 生成的“全部正常”也无法填补它。