安全测试常从漏洞类别入手：今天查跨站脚本，明天测授权，后天检查输入校验。对于复杂业务系统，还有另一条更有生产力的路径：先选一个值得理解的功能，弄清它的正常行为，再探索它在非预期情境下会怎样。

本文整理了 Shilpa Kumari 在 GitHub 博客对 VIP 漏洞赏金研究员 @vaib25vicky 的访谈。该研究员主要关注授权和访问控制。后半部分讨论这种方法在 QA 与 AI 原生质量工程中的应用，不应误读为访谈原话。

原文：How One Bug Bounty Researcher Chooses the Features They Investigate: https://github.blog/security/how-one-bug-bounty-researcher-chooses-the-features-they-investigate/

重视发现质量，而不是提交数量

访谈介绍的 GitHub VIP 项目重视高质量发现，而不是尽可能多地提交报告。原文发表时，VIP 是邀请制项目；严重问题的奖金可能超过 30,000 美元，研究员可获得更快响应，并有机会提前体验部分测试版功能。

访谈列出的邀请门槛是：一个已解决的严重级别问题、两个高危问题、四个中危问题，或七个低危问题。这些是原文发布时对项目的描述，不是当前奖金或资格的保证。

对 QA 团队更可迁移的原则是证据质量：一份能说明真实授权失效、实际影响和复现条件的报告，通常比一堆未经核实的猜测更有用。

先理解功能，再选择漏洞类别

下面五步是本文对访谈内容的归纳，并非研究员提出的正式框架：选择值得研究的功能；亲自使用，弄清正常行为；梳理用户、资源、权限、状态和依赖；思考这个能力在非预期情境下会如何表现；最后反复验证异常，判断它是否构成真实安全问题。

这并不意味着 OWASP 等漏洞分类没有价值。改变的是研究的起点：分类可以帮助提出假设、归类发现，但不必决定每次研究从哪个标签开始。

为什么复杂功能值得研究？

他们会留意看起来复杂、难以理解的功能，再凭经验判断是否值得继续研究。复杂功能通常涉及更多参与者、状态变化和隐含业务规则。比如组织级共享能力，可能同时涉及所有者、成员、外部协作者、管理员、待接受邀请和权限撤销。

复杂不代表一定有漏洞，但值得仔细检查边界。研究会沿着有希望的线索继续一段时间；如果没有新发现，就转向别的功能。这也是时间有限的 QA 团队可以采用的资源分配方式。

受访者也谈到自己的入行经历：大学期间编写项目、深入理解系统并尝试改变系统行为，后来偶然发现漏洞赏金研究，觉得很有意思。因为熟悉 GitHub，便从该平台开始探索；奖金、挑战和团队体验也让这项工作更有吸引力。持续学习的渠道包括在 X 上关注其他研究员、阅读企业安全博客和漏洞复盘，以及浏览 Hacker News 和安全版块；访谈提到的资料有 Google Project Zero、GitHub Security Lab 和 PortSwigger。给入门者的建议是保持耐心：调查很久才遇到值得报告的问题，并不罕见。

从正常使用追到已验证的发现

下面是本文新增的 QA 示例，不是 GitHub 访谈披露的漏洞。

假设一个应用允许用户共享项目报告。先确定预期行为：谁可以创建、查看、分享或导出报告？共享链接何时过期？成员离开组织后会发生什么？然后检查身份、资源归属、状态变化、具体操作和不同入口之间的授权是否一致。

维度需要验证的业务问题可用证据
身份不同角色是否只能查看获准访问的资源？角色权限矩阵与请求结果
归属资源是否在不同组织或租户间隔离？跨租户隔离结果
状态权限撤销或成员移除后，访问是否立即失效？状态变化前后结果与审计日志
操作只读角色是否无法修改或导出受限数据？服务端授权结果
能力组合搜索、导出、批量操作是否与详情页执行同样的授权检查？多入口行为对比

**隐藏按钮不是授权控制。**界面里没有操作入口，不代表服务端会拒绝未授权请求。所有安全测试都必须限定在明确授权的环境和范围内，绝不访问真实第三方数据。

把风险假设和已验证发现分开。

谈到 AI 时，受访者认为它能节省时间、提高效率，但仍需要人来引导，还把 AI 比作一辆很快的车，强调再快的工具也需要可靠的驾驶者。

延伸到 QA 实践，AI 可以协助总结功能文档、提出边界问题、整理假设和准备证据。这些是本文补充的用法，不是受访者的原话。AI 仍不能让未经验证的假设自动变成事实。

要把状态区分清楚：

  • 风险假设：根据设计或已观察行为推测可能存在的问题。
  • 未确认异常：观察到意外结果，但仍需排除环境、配置或业务规则的影响。
  • 已验证发现：在授权范围内可以稳定复现，并有清楚的预期与实际差异及影响证据。

访谈中的原则很直接：**没有亲自验证过的漏洞，不要提交。**AI 生成的 QA 报告和安全测试用例也适用同样的要求。

测试 AI 功能仍离不开熟悉的安全思路。研究员认为，测试方式或许要稍作调整，但许多重要问题依然是常见类型：授权失效、护栏薄弱，或系统能力被忽略。理解功能并运用已有的 Web 安全知识，仍然很有价值。

AI 辅助提示框架。

你是安全测试设计助手，只能在明确授权的测试范围内工作。
输入：功能说明、角色与权限矩阵、状态变化、API 契约。
请总结预期行为和授权边界，从身份、资源归属、状态、入口和能力组合提出风险假设，说明依据与信息缺口，并建议人工检查及预期证据。不得把假设写成已确认漏洞。

把已确认发现转成回归覆盖

本节是本文对访谈方法的工程应用，不是研究员直接提出的主张。

对高风险功能，可以用一张研究卡片记录业务目的、角色、敏感资源、授权边界、生命周期状态、外部依赖、已知异常和未证实假设。目标是让团队延续对功能的理解，而不是为了留文档而留文档。

确认的问题应保留原始失败证据和修复后验证结果，再沉淀为分层回归资产：单元测试验证复杂权限规则、策略判断和状态变化；接口或服务测试验证服务端授权、对象归属、权限撤销和错误路径；端到端测试覆盖涉及角色变化与用户反馈的关键流程；人工探索补足角色、入口和生命周期事件之间尚未覆盖的组合。自动化脚本显示绿色，本身还不足以证明风险已经覆盖。

QA 技能或智能体可以执行一套受控循环：理解 → 提出假设 → 验证 → 记录 → 学习。它们可以读取需求、API 契约、代码和权限模型，生成有事实依据的假设，并整理复现条件和证据；但验证应由获授权的测试人员负责，敏感操作需要人工批准。明确由谁确认发现、接受风险和对外提交。生成的测试还要检查断言质量：它必须验证授权义务，而不是只看请求是否成功返回。

从一个边界清晰的探索开始

选择一个包含多个角色或状态变化的功能，在授权测试环境中开展短时探索。先梳理正常路径和角色/状态矩阵，再验证少数高价值假设。结束时把观察结果标记为已确认、已排除或仍待调查。将可复现的问题变成回归测试，再决定继续深入还是转向其他功能。

不要只用“发现了几个漏洞”衡量一次探索。即使没有发现问题，团队也可能因此更清楚授权模型，积累可复用测试数据，并更了解系统边界。

这次访谈对 QA 实践的启发。

这场访谈给 QA 的启发，不只是一组安全技巧，还包括一种研究顺序：先理解功能，再挑战它的假设；让 AI 加快思考，但让证据决定结论。

从功能出发的安全探索能让质量工程超越按漏洞类别逐项打勾，进一步理解业务能力及其滥用边界。它补充系统化安全测试，而不是取代它。

参考资料

安全测试白盒测试背靠背测试本地化测试边界测试
分享