# Src Workflow

> 通用企业 SRC 工作流技能。只要任务涉及企业 SRC、授权范围确认、测试规则梳理、资产盘点、被动信息收集、空间测绘结果整理、导出归类、漏洞挖掘准备，或在授权范围内推进实际挖掘与记录，就应优先使用这个技能。它适合多厂商、多项目、长期复用的 SRC 场景，尤其适合需要先确认范围与规则，再结合官方资料、被动来源、导出文件和本地笔记推进工作的任务。

- Skill: `openaisec/src-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add openaisec/src-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openaisec/src-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: openaisec (https://skillmd.com/u/openaisec)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openaisec/src-workflow

---


# src-workflow

这个技能用于处理 **企业 SRC 场景下的通用工作流**：
- 确认授权范围与测试规则
- 梳理资产、业务线和公开入口
- 利用官方资料和被动来源补充线索
- 处理空间测绘平台或其他外部来源的导出文件
- 为后续漏洞挖掘、记录、汇总和持续跟进建立稳定底稿

核心边界只有一条：**仅在明确授权范围内执行。**

## 额外安全铁律

在任何测试、验证、复现或挖掘过程中，默认只做**低影响、可回退、非破坏性**操作。

绝对不要擅自执行这类动作：
- 删除、修改、覆盖、提交、确认、解绑、下单、支付、发货、取消、上传、清空、重置
- 批量写入、批量调用、批量触发
- 任何可能改变真实业务数据、账号状态、订单状态、资金状态、库存状态、权限状态的动作
- 任何可能影响业务可用性、稳定性、完整性的动作

如果验证漏洞需要触发上述任一敏感操作，必须先停下并明确向用户汇报：
- 要做什么操作
- 为什么需要做
- 可能影响什么
- 有哪些更低影响替代方案

在用户明确确认前，不得继续执行。

如果执行过程中出现以下情况，也必须立刻汇报，而不是自行推进：
- 怀疑某一步会产生真实写操作或状态变化
- 怀疑会接触真实隐私数据、资金数据、订单数据、内部管理数据
- 怀疑会影响生产环境用户、司机、商家、企业客户或后台人员
- 发现需要登录后提交、保存、删除、修改、审批、调用敏感接口才能继续验证

默认优先选择：只读、最小化、单次、可观察、不改变状态的验证路径。

## 一、什么时候用这个技能

当任务涉及以下任一场景时，应优先使用本技能：
- 企业 SRC 范围确认
- 测试规则、奖励规则、提交流程整理
- 资产盘点、业务归类、入口梳理
- 子域、站点、接口、App/H5、小程序、后台入口线索收集
- 被动信息源整理与交叉验证
- 空间测绘平台结果导出、下载、离线归类
- 授权范围内的漏洞挖掘准备
- 授权范围内的实际漏洞挖掘过程记录与信息整理
- 本地资产清单、作战表、笔记、报告模板的维护

不要把它理解成“只会信息收集”的技能。它覆盖的是 **SRC 任务从准备、梳理、发现、分类到持续记录的整条工作链**。

## 二、先建立上下文，不要直接开做

开始任务后，先检查当前项目里是否已经有**总推进表 / 作战表**。如果没有，应优先创建一份，再开始推进；如果已经有，就先更新它，再决定这轮做什么。

总推进表应按“平台 × 阶段”管理，不按零散发现管理。默认至少包含：平台、当前阶段、奖励/价值判断、竞争压力、验证成本、已确认入口、业务面进度、高价值目标、候选漏洞、报告草稿、下一步动作、阻塞项。

后续每完成一轮工作，都先写回总推进表，再写回资产底稿或其他专题文件。这样可以避免同时推进多个 SRC 时状态发散。

开始任务后，先读当前项目里已有的本地资料，再决定怎么推进。

优先查找并读取这些类型的文件：
- 活动规则
- SRC 范围说明
- 测试规范 / 评级标准
- 已有资产清单
- 历史笔记
- 导出摘要
- 报告模板
- 上一轮整理结果

目标不是“读得越多越好”，而是先回答这几个问题：
- 本次授权范围是什么
- 哪些资产明确在范围内，哪些只是线索
- 当前已有的资产树到哪里了
- 这一轮任务是补资产、做分类，还是直接推进漏洞挖掘

如果用户给了很少信息，也先从当前目录里的本地文档、说明文件、已有表格和笔记补上下文。

## 三、工作流总顺序

默认按这个顺序推进：

1. 确认授权范围与测试规则
2. 建立或更新当前项目的资产树
3. 从官方资料提取公开入口与业务映射
4. 结合被动来源补充线索
5. 必要时做导出、下载、离线分类
6. 输出待跟进目标和记录结果
7. 把关键信息写回本地资料

不要一上来就沉进某个平台的海量结果里。先把“范围、优先级、已有成果”看清楚，能减少很多无效工作。

## 四、先确认什么：范围、规则、边界

先从本地资料或官方资料中提炼出：
- 授权范围
- 不在范围内的内容
- 测试规则与限制
- 奖励、评级、提交流程
- 时间窗口
- 是否区分核心业务 / 一般业务 / 边缘业务

优先级不要只按截止时间排。默认综合这几个维度判断：
- 奖励强度（翻倍、等级系数、证书/积分价值）
- 竞争压力（热门项目是否更容易被其他白帽抢先）
- 验证成本（是否容易低影响复现、是否需要复杂前置条件）
- 业务价值（登录、支付、订单、后台、开放平台等是否集中）
- 用户明确偏好（如果用户指定先打哪家，应直接提高优先级）
- 截止时间（只作为一个维度，不应单独决定排序；只有接近截止时才显著加权）

这一阶段的输出应至少包括：
- 一份明确的范围摘要
- 一份优先级判断（写清为什么这样排）
- 一份需要谨慎对待的边界项列表

如果授权范围不清晰，不要主观扩展。先把它写成“待确认线索”，后续再结合官方映射补证据。

## 五、官方资料永远优先

在做被动收集或漏洞挖掘之前，先把官方资料过一遍。

优先看的页面或资料类型：
- 官方 SRC 首页
- 官方范围说明
- 公告 / 帮助中心 / FAQ
- 品牌官网
- 产品页 / 下载页 / 联系页
- 开放平台 / 开发者页面
- 登录页 / 注册页 / 后台入口线索
- 招聘页 / 合作页 / 服务页
- App 下载页 / H5 页面 / 小程序线索页

官方资料的价值在于：
- 确认业务归属
- 确认品牌和主域映射
- 找到正式入口
- 提供后续被动收集的关键词和种子域名

先用官方资料建立“入口树”，再补“暴露面树”。这比一上来只看空间测绘结果更稳。

## 六、什么时候用 web-access

凡是涉及网络访问、网页浏览、动态页面、登录态复用、导出操作、文件中心下载、页面交互，都应优先调用 **`web-access`**。

它适合承担这些任务：
- 打开并浏览官方站点 / SRC 站点
- 处理动态渲染页面
- 使用用户当前 Chrome 的登录态
- 操作空间测绘平台、文件中心、导出页面
- 浏览需要点击、翻页、展开、截图的页面

本技能负责“判断应该做什么、按什么顺序做、产出什么记录”，`web-access` 负责“浏览器里怎么实际操作”。

### 使用 web-access 前的原则
- 先检查它的依赖环境是否可用
- 优先用用户现有 Chrome 登录态，不额外污染环境
- 不要关闭用户原有 tab
- 操作完成后关闭自己创建的后台 tab

如果 CDP 或浏览器调试没连上，先处理环境问题，不要在失败状态下反复重试同一动作。

## 七、被动来源怎么组合

在官方资料之外，按需组合这些被动来源：
- 空间测绘平台
- 搜索引擎
- 证书透明度日志
- 官方页面里的 JS / HTML / 静态资源
- 公开品牌资料
- 公开下载页
- 公开招聘 / 帮助 / 开放平台资料
- 公开可见的导出数据或历史整理文件

这些来源的用途不同：
- 官方资料：确认映射和归属
- 空间测绘：发现公开暴露面
- 搜索引擎：补入口、标题、历史痕迹
- 证书透明度：补域名 / 子域名线索
- JS / HTML：补资源域、接口路径、站点结构线索

不要把任何单一来源当成最终真相。多个来源交叉验证后再决定写入哪一层清单。

## 八、空间测绘平台的通用用法

空间测绘平台适合作为第一层暴露面发现工具，但不要让它主导全部判断。

### 1. 先决定查询对象
优先围绕这些对象展开：
- 已确认授权的根域
- 官方映射到的品牌域
- 官方确认的业务域
- 已知正式入口相关域名

### 2. 先决定导出策略
不要总是一把梭全量导出。更推荐按用途分桶：
- 主 Web 入口
- 业务关键词入口
- API / 接口类入口
- 登录 / SSO / 后台类入口
- 预发 / 测试环境线索
- 静态 / 日志 / 监控 / 埋点线索

如果结果很多，先导第一轮样本，再让模型离线分类；不要把浏览器页面当成长期工作区。

### 3. 导出后不要停在“任务创建成功”
通用流程是：
1. 在平台里发起导出
2. 进入文件中心或导出记录页
3. 确认任务状态为已完成
4. 再点击下载
5. 去本地下载目录定位文件

“导出”与“下载”通常不是同一步，很多平台都会拆开。记得走完整条链路。

## 九、下载和导出文件怎么处理

### 1. 先定位文件
优先从常见下载目录或用户指定目录定位：
- `Downloads`
- 当前项目目录
- 用户明确提供的路径

优先用：
- `Glob` 找 `*.xlsx` / `*.csv` / `*.json`
- `Bash` 查看目录内容

### 2. 先看结构，再决定处理方式
不同格式适合不同策略：

#### `xlsx`
- 优先用现成库读取
- 如果环境里没有相关库，可用 Python 标准库把 xlsx 当 zip 包解析
- 先抽头部字段和样本行，不要先全量灌进上下文

#### `csv`
- 先看表头、编码、分隔符
- 再做去重、分类和统计

#### `json`
- 先看顶层结构
- 再抽目标字段
- 必要时转成更适合人工和模型阅读的摘要文件

### 3. 离线处理时至少抽这些字段
- host / domain
- url
- ip
- port
- title
- status
- service / protocol
- 组织 / ICP / 证书主体 / ASN 等归属线索
- 页面类型或响应类型线索
- 原始来源

### 4. 离线分类时必须补的标签
- 是否在授权范围内
- 正式 / 预发 / 测试 / 待确认
- Web / H5 / API / 静态 / 日志 / 监控 / 后台线索
- 业务归类
- 是否高价值入口
- 是否值得继续跟进

## 十、怎么做信息梳理和优先级判断

离线分类不是为了“看起来整齐”，而是为了让下一步挖掘更快。

优先标这些高价值线索：
- 登录 / SSO
- 账户与资料修改
- 订单 / 交易 / 支付
- 优惠券 / 积分 / 发票
- 司机端 / 用户端 / 商家端 / 企业端
- 开放平台 / 开发者入口
- 管理后台 / 内部系统公开入口
- API 网关 / 业务接口入口

同时要单独标出这些低确定性对象：
- 带 `pre` / `stg` / `test` / `dev` / `uat` / `beta` 的主机
- 仅显示默认页、错误页、欢迎页的主机
- 403 / 404 / 页面失效 / 占位页
- 无法确认业务归属的站点

这些不一定没价值，但应该进入“待复核”层，而不是直接当成核心目标。

## 十一、如何把信息写回本地资料

每完成一轮工作，都要把结果沉淀到本地，不然下一轮还会重复走一遍。

默认优先维护一份**总推进表 / 作战表**，按“平台 × 阶段”统一记录，而不是把状态散落在多份零散笔记里。

推荐至少包含这些列：
- 平台
- 当前阶段
- 奖励/价值判断
- 竞争压力判断
- 验证成本判断
- 已确认入口
- 已整理导出
- 业务面进度
- 高价值目标
- 候选漏洞
- 报告草稿
- 下一步动作
- 阻塞项

优先维护这几类文件：
- 总推进表 / 作战表
- 资产底稿
- 导出摘要
- 待复核清单
- 报告模板 / 记录模板
- 当轮工作纪要

写回时重点记录：
- 新增了哪些资产或入口
- 哪些已经确认在范围内
- 哪些只是线索
- 哪些适合下一轮继续跟进
- 当前处于哪个阶段，下一阶段的进入门槛是否满足
- 使用了哪些证据来源

如果项目里已经有现成文件，就更新现有文件；不要轻易平行创建一堆新文档。

## 十二、当任务已经进入挖掘阶段

如果用户不是要你“整理资料”，而是已经开始在授权范围内推进漏洞挖掘，也继续沿用这个技能的框架。

这时你的重点变成：
- 先快速确认目标是否在授权范围内
- 确认该入口属于哪条业务线
- 判断它属于正式、测试还是待确认环境
- 把观察到的入口、参数、角色、流程记录下来
- 按漏洞大类去扩验证思路，而不是被单一线索绑定
- 把发现写进本地清单或笔记，方便后续复盘与报告

进入实际挖掘阶段时，默认优先围绕这些大类展开低影响验证：
- 未授权访问
- 越权 / 横向越权 / 纵向越权
- 鉴权边界问题
- 业务接口暴露与敏感功能未受保护
- 用户/账号/手机号/订单等枚举类问题
- 订单、支付、优惠券、发票、资料修改等高价值业务流程中的参数信任问题
- CORS、调试开关、错误回显、环境泄露等可辅助深入的线索
- source map / 调试面 / 环境信息泄露（作为辅助突破口，不应默认当成主洞终点）

### 常见高价值业务面

进入实战阶段后，不要只盯“漏洞名”，更要按 **业务面 × 权限面 × 数据流 × 状态流** 去打。默认优先覆盖这些面：
- 认证与登录：密码登录、短信登录、扫码登录、找回密码、换绑、SSO、OAuth/SAML/OpenID
- 账户与个人中心：资料、实名、联系人、地址、司机/商家资料、隐私设置
- 权限与角色体系：角色、菜单、按钮、接口、组织/部门/租户/城市隔离
- 订单 / 交易 / 状态流：下单、接单、取消、补差价、确认、退款、开票、结算
- 支付 / 余额 / 券 / 积分 / 发票：支付单、钱包、账单、优惠券、积分中心、开票链路
- 开放平台 / 开发者平台：应用列表、密钥、回调、文档、授权、沙箱、网关
- H5 / 小程序 / 活动页 / 微前端：活动码、模板码、场景参数、调试参数、业务 API 根
- 管理后台 / 内部系统：用户、角色、组织、订单、地图、监控、配置、审批、导出
- 文件上传 / 下载 / 导出 / 附件：文件详情、下载、导出记录、任务列表、OSS 路径
- 消息通知 / 回调 / Webhook：短信、邮件、推送、业务回调、签名校验、重放防护
- 搜索 / 查询 / 列表 / 枚举：自动补全、分页、详情、模糊查询、对象遍历
- 配置 / 环境 / 调试 / 错误处理：source map、debug 参数、错误回显、feature flag、环境域名

### 常见高价值漏洞方向

围绕上面的业务面，默认优先问这些问题：
- 哪些对象本不该被当前身份读取，却可以被查询到？
- 哪些对象本不该被当前身份操作，却能通过改参数或换角色边界触达？
- 是否存在“前端传什么，后端就信什么”的参数信任问题？
- 状态流里是否存在跳步、重复执行、并发竞争或角色错位？
- 列表、详情、搜索、导出、附件、回调这些“看起来普通”的面，是否藏着未授权或越权？

### 低影响挖掘时的常用切入角度

默认优先做这些动作，而不是直接冲高风险操作：
- 看登录前后同一接口的响应差异
- 看同对象 / 他对象 / 空参数 / 异常参数的差异
- 看 query、body、header 里的 userId、orderId、roleId、tenantId、appId、fileId、couponId、invoiceId 等对象标识
- 看 callback、redirect_uri、state、ticket、scene、activityCode、templateId、env、debug 等关键参数
- 看“详情 / 列表 / 预览 / 校验 / 配置获取 / 导出任务详情”这些只读接口
- 看同一业务在用户端、司机端、商家端、企业端、后台端之间的对象绑定是否一致

不要把 source map、调试参数、错误信息回显这类线索本身当成唯一目标。它们更重要的作用通常是：帮助你定位真实业务接口、角色边界、隐藏页面和可继续验证的高价值功能面。

优先把它们当成**突破口**，再继续打：
- 未授权
- 越权
- 鉴权边界
- 参数信任
- 枚举
- 高价值状态流

也就是说：本技能既适合“准备阶段”，也适合“边挖边整理”的阶段。

## 十三、推荐输出结构

完成一轮后，优先输出这几类结果：

1. 本轮新增资产 / 主机 / 入口
2. 正式 / 预发 / 测试 / 待确认分类
3. 高价值目标待复核清单
4. 已写回哪些本地文件
5. 下一步建议做什么

如果用户要简练版，就只说：
- 这轮新增了什么
- 哪些最值得继续
- 下一步建议往哪走

## 十四、一个稳定的执行模板

当收到新的企业 SRC 任务时，默认按这个模板推进：

1. 读当前项目的规则、范围、清单、笔记
2. 提炼授权范围、优先级和边界
3. 看官方站点 / SRC / 公告 / 品牌页 / 帮助中心
4. 建立当前轮次的入口树
5. 按需调用 `web-access` 访问外部站点或平台
6. 按需使用空间测绘、搜索引擎、CT 等被动来源补线索
7. 必要时做导出、下载、离线分类
8. 标记高价值入口和待复核对象
9. 更新本地资料
10. 给出简洁结论和下一步建议

## 十五、汇报风格

保持执行型、简洁、可落地。

优先用这种表达：
- “我先确认范围和现有清单，再补公开入口。”
- “我先用官方资料建立业务映射，再看被动来源补线索。”
- “导出已经完成，下一步转离线分类。”
- “这批结果里高价值入口不多，预发主机我单独标了。”
- “我已把新增线索写回本地资产底稿。”

不要把它写成抽象方法论。它是一份 **长期可复用的企业 SRC 通用工作流手册**。