苹果漏洞赏金收紧后，如何提高报告通过率？

苹果在 AI 功能集中上线后对漏洞赏金提交做了一次比较明显的收口。这里的“收口”不只是提交入口变化还包括评审时对复现步骤、影响范围、设备版本和 AI 相关组件的考察都比以前严格。如果你一直把 Apple Security Bounty 当作兼职测试目标或者正准备第一次提交漏洞报告这个变化会直接影响你的通过率和回款时间。比起功能列表和新版文档我更建议你先理解一个事实苹果这类厂商的漏洞赏金计划从来不是“提交就有钱”而是“在授权范围内证明漏洞存在、危害可衡量、复现成本可控”。AI 功能兴起之后攻击面从传统系统组件扩展到模型工具链、用户数据流转和端侧推理漏洞报告的数量和复杂度同时上升。这时候厂商选择限制提交不是不欢迎漏洞而是要把评审资源集中在高价值报告上。对提交者来说真正要解决的不是“为什么被拒”而是“怎么在更严格的规则下提交一份评审愿意放行的报告”。下面按一条可复用的流程拆开讲。1. 先搞清楚苹果漏洞赏金计划现在卡在哪里1.1 计划本身并非新手零门槛Apple Security Bounty 覆盖范围很广包括 iOS、iPadOS、macOS、watchOS、visionOS以及 iCloud、Apple ID、网络服务等。不同于通用 SRC 平台的“随便挖”它要求研究者在苹果规定的范围内测试并且对漏洞严重性有自己的打分逻辑。很多人第一次提交就卡在“我发现的这个问题到底算不算漏洞”这个判断上。AI 热潮带来的变化是新增了大量与模型交互、数据标注、端侧推理、用户提示词处理相关的组件。这些组件在正式发布前可能已经经过一轮内部安全 review但外部研究者仍能从接口逻辑、权限校验、数据隔离、输出过滤这些角度发现新问题。只是这类问题通常比单纯的越权更难评估因为你不仅要证明“能调接口”还要证明“这个调用会造成实际资产影响”。1.2 提交量被压缩后评审更看重复现效率和资产价值“Caps Bug Bounty Submissions”这句话在实操里最常见的表现是单个账号的提交次数、同批次报告数量、以及相同漏洞形态的重复报告开始被限制。我见过不少研究员把同一个逻辑问题拆成五个入口提交结果不仅没拿到额外奖励还被判定为重复报告。厂商不是不理解多入口危害而是更希望你把五个入口合并成一条完整调用链说明影响范围。因此第一个要调整的思路是不要用“多提交多个漏洞”来对冲不确定性。评审更愿意看到一份说明“一个根因多处触发最终影响某类用户数据”的报告而不是五份各自缺背景的零散提交。1.3 很多人都被“提交窗口”卡住了提交窗口不是指某个固定时间段而是指你的测试活动是否覆盖到目标当前支持的最新版本。苹果的漏洞赏金政策里很多漏洞只对特定系统版本有效。如果你在一台停留在 iOS 16 的设备上复现了一个已经被 iOS 17 修复的问题报告基本无效。AI 功能相关组件更新更快甚至会出现小版本差异导致复现失败的情况。你在报告里必须写明测试设备、系统版本、App 版本、网络环境以及是否在最新版本下复现。2. 提交前先确认授权范围和测试边界2.1 授权边界是最容易翻车的初始条件合法漏洞研究的前提是授权。苹果的公开漏洞赏金计划给了研究者一定范围但并不是无限攻击授权。你只能在计划描述的范围内针对自己的设备、账号和测试流量做验证不能尝试越权获取他人数据不能大规模扫描苹果基础设施更不能直接用真实用户账号做测试。AI 功能上线后有些研究者会尝试用特殊提示词诱导模型输出敏感内容这属于功能测试需要特别注意样本数据不要包含真实个人信息。我的建议是任何涉及用户数据、身份认证、支付信息的测试都要先构造受控的测试账号和测试数据。不要为了一步复现就随意使用真实账号否则即使你是出于善意也可能触发安全响应团队的反感。2.2 明确设备、版本和目标组件提交一份 AI 相关漏洞报告前先列一个环境清单测试设备型号和存储版本操作系统版本包括是否 betaApp 名称和具体版本输入数据大小和格式测试网络环境普通 Wi-Fi、蜂窝网络或本地代理是否涉及端侧模型、云端推理或混合架构不要小看这些信息。很多时候报告被退回不是因为漏洞不存在而是因为评审无法用同一环境复现。尤其是 AI 功能的输出带有随机性你提供“触发词”还不够最好能说明输入顺序、上下文长度和采样参数。如果涉及第三方模型服务还要写清楚调用链路。2.3 越界测试会带来什么后果越界测试可能让报告直接作废甚至影响账号资格。比如你发现一个仅限内部调用的管理接口但没有授权证据就去测试这已经不是“漏洞研究”而是“未授权访问”。正确的做法是先确认该接口是否在漏洞赏金覆盖范围内如果不在不要继续深入。你可以把这个信息作为“潜在风险点”在报告里描述而不是实际调用。AI 相关系统更容易出现类似问题。很多服务前端看不出来后端可能接入了内部模型管理平台如果你通过修改请求头访问到不应暴露的管理功能正确的提交方式是记录现象后立即停止测试而不是继续枚举接口。3. 高通过率漏洞报告的材料清单和写法3.1 苹果评审关注哪几个点根据我过往的提交经验评审看报告的顺序大致是先看标题和严重性再看复现步骤最后补充验证证据。如果标题写不清实际影响复现步骤又缺少关键参数哪怕漏洞本身很严重评审也会优先标记为“待补充信息”而不是直接受理。具体来说评审看重清晰的问题描述不要只写某个函数存在缺陷可以稳定复现的最小操作集越长越容易失败影响范围包括受影响用户、数据类型和业务组件实际危害而不是理论风险修复建议哪怕只是方向性建议3.2 报告模板和字段我习惯用固定模板整理漏洞报告避免遗漏信息。以下字段供参考字段内容说明标题一句话说明漏洞类型和影响对象例如“AI 接口权限校验缺失导致用户对话记录可被越权读取”环境设备、系统版本、App 版本、网络条件前置条件测试账号、订阅状态、文件类型、输入长度、上下文要求复现步骤编号列表每一步尽量可执行影响分析数据泄露、越权操作、服务不可用、模型输出污染等严重性判断按照计划要求或 CVSS 思路给出你的判断缓解建议你认为应该在哪里增加权限检查、输入过滤或输出限制附件截图、抓包记录、演示视频、日志不要只给一个视频链接。评审通常没有时间看完整个视频你应该在正文里写清楚关键时间点并把最关键的执行命令或请求放在文字里。视频只是辅助证据。3.3 演示视频怎么做更有效苹果的漏洞赏金提交经常要求演示视频但很多研究者录的视频只有 20 秒无法证明前置条件。我通常这样录先展示测试设备版本、时间日期避免后续争论环境问题。再用不超过 15 秒演示前置条件比如登录一个测试账号、准备一个特殊文件。之后进入关键复现过程建议把输入框的操作放慢一点停顿几秒。最后展示结果包括数据回显、错误信息或屏幕变化。不要剪辑掉报错信息。报错本身也是线索评审反而会通过报错类型判断根因。4. 批量提交被“cap”时先做这五件事4.1 去重与合并同类项当你准备提交一批漏洞时先做一次根因去重。十个现象完全可能是同一个根因只是不同入口。合并同类项之后再判断每条报告的证据是否独立。如果证据独立、影响不同可以分开提交如果只是同一个越权逻辑在不同页面上重复出现最好合并成一条。这样做的另一个好处是评审不会认为你在刷量。刷量是“cap”提交量后最常见的不合格理由甚至会导致账号被冻结。4.2 按严重性排序不按发现顺序很多人在提交时习惯把最早发现的漏洞放在前面这是错误做法。评审处理的是队列如果你的前几条报告都是低危高危及严重问题的排期会被推迟。正确做法是先提交严重性最高、复现最稳定、影响范围最明确的报告再提交中低危问题。如果时间有限优先提交以下类型可导致他人账号数据泄露的漏洞可绕过认证或授权校验的漏洞可被利用于远程代码执行或设备完全控制的漏洞可影响 AI 用户隐私数据隔离的漏洞4.3 提交节奏和窗口苹果的漏洞赏金计划在收到大量提交后评审处理时间会变长。如果你在同一天提交二三十条很容易触发风控。我建议把提交节奏打散按严重性分级分几天提交并且每次提交后观察回复时间。如果前一条还在“待确认”后一条同类型报告不要立刻跟进等评审确认后再调整后续报告。这里还有一个实际细节不要在同一封邮件里放多个漏洞也不要把多个报告压缩成一个附件。平台通常更认可每条报告独立提交方便分配 ID 和追踪状态。确实需要补充关联时在报告中引用前一条 ID 即可。4.4 失败请求的重试策略提交失败或上传超时很多人会立刻重复点击提交按钮结果导致同一报告被创建多次。评审看到重复报告会直接关闭甚至降低后续报告的优先级。正确做法是先等 5 到 10 分钟刷新状态看看是否已经创建。如果确定失败再重新提交一次。上传视频文件时需要特别注意文件大小和格式。很多平台限制单个附件视频太大就压缩画质或截取关键片段。不要为了追求高清把视频传到外部链接评审不一定愿意点击外部链接。4.5 建立自己的提交台账对于长期做苹果漏洞研究的人来说台账是刚需。每次提交都要记录报告 ID、漏洞根因、影响组件、复现参数、提交日期、当前状态、评审结论、最终奖励。没有台账你很难判断哪类报告通过率高哪些组件是评审感兴趣的方向哪些问题连续失败。台账可以用表格也可以用本地脚本。我的做法是每个季度导出一份统计通过率、驳回原因和平均耗时用来调整下个季度的研究方向。5. 常见驳回原因和排查链路5.1 先看驳回类型再改报告苹果评审在驳回时不一定写得很详细但通常会在状态里给出原因关键词。常见驳回类型包括驳回原因实际含义对应处理Duplicate重复报告找根因合并或补充差异点Out of scope不在范围内检查目标组件和版本Not reproducible无法复现补全环境参数和稳定复现步骤False positive误报重新验证问题是否真实成立Insufficient information信息不足补充附件和关键请求内容驳回不等于漏洞无效很多时候只是提交时没有把信息组织好。5.2 先从复现步骤看起当我的报告被标记为无法复现时我会先复制自己的复现步骤在另一台同版本设备上原样执行一遍。最容易出问题的地方是输入文本中包含空格、换行或特殊字符复制时丢失前置账号状态没有写清楚网络代理仍开着导致请求路径与评审环境不同依赖本地模型缓存而评审环境没有缓存如果本地可以复现但评审端无法复现我会把关键请求参数、响应头和日志时间戳补进报告。5.3 再看版本、日志和设备状态AI 相关的功能经常依赖服务器端配置。同一 App 在 iOS 17.4 和 iOS 17.5 上的行为可能不同因为云端模型版本不一致。你复现成功不代表评审环境也能复现所以报告中最好写明“云端组件版本不确定但客户端行为在固定版本上可复现”。如果报告被驳回优先检查是否使用开发者设备或 beta 系统正式版可能存在差异是否开启某些隐私保护功能如“限制追踪”或“本地模型开关”是否在低功耗模式下执行导致部分后台任务被中断是否使用代理或抓包工具这可能改变 TLS 指纹5.4 最后看规则理解偏差有时候报告本身没问题但没有命中苹果当前关注的漏洞类别。例如苹果可能更关注 Web 层面和数据隐私而不是某个 UI 排版问题。遇到这种情况不要反复提交同样内容而是等新的政策解释或目标范围调整后再提交。也可以通过其他安全平台提交但要注意授权范围是否一致不要跨平台重复提交同一个漏洞可能引发纠纷。6. 长期做法把漏洞研究流程从“碰运气”变成“可复用”6.1 固定研究目标做纵深分析苹果生态非常大AI 功能也分散在系统各个层面。与其今天测 Siri明天测照片后天测浏览器不如固定一个方向做纵深分析。比如专注研究“AI 功能如何访问用户相册数据”可以覆盖权限提示、数据缓存、端侧模型推理、iCloud 同步、日志记录等多个环节。纵深分析更容易发现真正有影响的漏洞链。相比多个孤立的低危问题一条完整攻击链往往能拿到更高奖励。固定方向后你的背景知识也会逐渐积累提交报告时更容易准确写清影响。6.2 建立信号与噪音过滤AI 功能输出本身具有一定随机性不是所有异常结果都是漏洞。我一般会把“异常输出”分成三类功能性错误比如回复格式错误通常是模型问题不是安全问题权限类问题比如未授权用户能获取他人数据这是安全漏洞过滤绕过比如通过特殊提示词绕过安全限制需要看是否影响实际用户在提交前就建立一个简单的过滤清单可以大大减少无效报告。你可以在每次测试后记录“现象、复现概率、是否属于权限或数据边界问题”再决定是否深入。6.3 与厂商沟通时的表达方式如果你的报告进入“补充信息”阶段后续沟通要简洁、客观、克制。不要在邮件里写“这个问题非常严重你们必须马上修复”这无助于加速评审。更好的方式是直接列出问题复现条件、影响范围和可能的修复方向。如果评审要求补充日志尽快提供脱敏后的日志。不要把包含个人信息的原始数据直接附上。脱敏时注意保留时间戳和错误代码只隐藏账号 ID、邮箱等敏感字段。如果评审认为某个问题不在范围内你可以礼貌追问一句“是否可以通过其他授权渠道继续验证”不要纠缠。6.4 不依赖单一渠道的应急策略苹果漏洞赏金是重要反馈渠道但不是唯一渠道。如果计划提交量受限或者某个问题长期没有反馈可以考虑通过苹果产品安全反馈邮箱、系统自带“报告问题”入口或者参加官方安全研究设备项目来补充。不同渠道对信息要求不同但报告质量仍然是核心。我个人更建议把漏洞研究当作长期建设的项目而不是一次“冲业绩”。每次提交后保存好测试脚本、请求样例和复现视频形成自己的漏洞知识库。即使某次报告被驳回下一轮迭代时还能复用这些材料。踩过几次之后我发现很多问题不是 bug 不存在而是提交方式和边界理解没有跟上规则变化。把环境确认、证据组织、去重排序和沟通节奏做扎实即使苹果收紧了提交通道你依然能在有效提交中获得稳定回报。