扫描状态回传的独立凭证设计

扫描任务跑完，结果需要出现在合并请求页面上，这一步看似只是发一个状态，实际上经常决定整条流水线的凭证边界。不少团队把回传能力直接挂在扫描器身上：既然它已经能读代码，多给一个写检查状态的权限似乎差别不大。问题在于，这两件事的风险量级完全不同。读凭证泄露意味着源码外流，写凭证泄露意味着有人可以伪造门禁结论、篡改受保护分支的合并条件。把两者放进同一份凭证，等于让一次读取侧的失守直接升级为仓库写入侧的失守。

回传是写入，但不是写代码

状态回传的本质是向仓库平台提交一条与特定提交绑定的检查结论，作用对象是检查项，而不是文件树。因此它的权限模型应当向“发布一条状态”收敛，而不是向“能操作仓库”收敛。合理的做法是让扫描器保持纯只读身份，把回传动作交给 CI 中专门负责发布检查结果的那一步，由该步骤临时取得写入能力。扫描容器本身不持有这份凭证，即使扫描环节被突破，攻击者也拿不到改写检查结论的入口。

这份写入凭证还需要两个约束。其一是作用域，只覆盖目标仓库和对应的检查上下文，不延伸到组织级或其他仓库；其二是生命周期，随单次流水线运行产生、运行结束即失效，避免形成第二份长期有效的共享令牌。长期有效、多人共用、无法对应到具体流水线的回传凭证，实际上就是绕过了只读收敛的后门。

用门禁验证边界是否真的收窄

权限调整后只看任务变绿是不够的。合并请求门禁应当把四件事分开记录：扫描是否完成、扫描覆盖是否完整、检查状态是否正常出现、回传身份是否无法执行额外写操作。前三项验证功能没有退化，第四项验证收敛确实生效。验证写操作拒绝时，应在测试仓库或经批准的安全流程中进行，用回传身份尝试提交代码或修改受保护分支，确认被拒绝，而不是对生产分支做破坏性试探。

审计侧同样值得对照。回传身份的正常使用记录应当只有一类事件：为特定提交发布检查状态。一旦出现其他写操作，或访问了作用域外的仓库，说明权限没有真正收窄，需要先禁用该凭证，再核对受影响的提交与流水线配置。

需要强调的是，分支保护与服务账号权限是互补关系而非替代关系。前者限制代码如何进入受保护分支，后者限制流水线能对仓库做什么。把扫描结果设为必需检查项，比授予扫描器批准或合并权限更安全，也更符合回传这一动作的真实语义。回传凭证的设计目标不是让扫描器“有权限”，而是让它在只拥有发布结论这一项能力的前提下，依然能把结论准确送达。