用途
Security Bounty Hunter 适用于以实际漏洞发现、负责任披露或赏金提交为目标的场景，而不是宽泛的安全最佳实践审查。当需要扫描仓库中可被利用的漏洞、准备 Huntr、HackerOne 或类似平台的赏金提交，或进行“这个问题真的能拿到赏金吗”而非“这在理论上是否不安全”的分诊时，可以使用该技能。
主要能力
该技能倾向于关注远程可达、用户可控的攻击路径，并丢弃平台通常以信息性或超出范围为由拒绝的模式。
范围内模式包括：
- 通过用户可控 URL 的 SSRF（CWE-918），典型影响为内网访问、云元数据窃取。
- 中间件或 API 守卫中的认证绕过（CWE-287），典型影响为未授权账户或数据访问。
- 远程反序列化或上传到 RCE 的路径（CWE-502），典型影响为代码执行。
- 可达端点中的 SQL 注入（CWE-89），典型影响为数据外泄、认证绕过、数据破坏。
- 请求处理器中的命令注入（CWE-78），典型影响为代码执行。
- 文件服务路径中的路径遍历（CWE-22），典型影响为任意文件读写。
- 自动触发的 XSS（CWE-79），典型影响为会话窃取、管理员失陷。
通常应跳过的模式包括：仅本地、无远程路径的 pickle.loads、torch.load 或同类调用；仅 CLI 工具中的 eval() 或 exec()；完全硬编码命令上的 shell=True；单独存在的缺失安全响应头；无利用影响的通用限流抱怨；需要受害者手动粘贴代码的自 XSS；不属于目标计划范围的 CI/CD 注入；以及演示、示例或仅测试代码。除非项目另有说明，这些通常属于低信号或超出赏金范围。
使用方式
工作流程如下：
- 先检查范围：项目规则、SECURITY.md、披露渠道与排除项。
- 寻找真实入口点：HTTP 处理器、上传、后台任务、webhook、解析器与集成端点。
- 在有用时运行静态工具，但仅将其视为分诊输入。
- 端到端阅读真实代码路径。
- 证明用户控制能够到达有意义的汇聚点。
- 用尽可能小的安全 PoC 确认可利用性与影响。
- 起草报告前先检查是否重复。
示例分诊循环：
semgrep --config=auto --severity=ERROR --severity=WARNING --json
随后手动过滤：丢弃测试、演示、fixture、vendored 代码；丢弃仅本地或不可达路径；只保留具有明确网络或用户可控路由的发现。
报告结构：
Description
[漏洞是什么以及为何重要]
Vulnerable Code
[文件路径、行范围与一小段代码片段]
Proof of Concept
[最小可工作的请求或脚本]
Impact
[攻击者能达成什么]
Affected Version
[测试的版本、提交或部署目标]
适用场景
适用于对仓库进行可赏金漏洞扫描、准备赏金平台提交、对已有发现进行“是否值得提交”的分诊，以及需要以远程可达性和用户可控性为核心判断标准的漏洞验证工作。
限制
提交前需通过质量门：代码路径可从真实用户或网络边界到达；输入确实由用户控制；汇聚点有意义且可利用；PoC 有效；问题未被公告、CVE 或开放工单覆盖；目标确实在赏金计划范围内。该技能不适用于宽泛的最佳实践审查，也不保证任何发现一定符合特定赏金计划的范围或获得赏金。