3个Skills把密钥盘点、轮换、撤销串成一条测试流水线

安全团队常见的一句话是：“这批Token应该没人用了。”问题在于，应该不是证据。一个旧PAT可能埋在CI变量、个人脚本、Runner缓存、Agent环境或某个半年前没人维护的仓库里。贸然删除会打断发布，不删又留下长期入口。

GitHub在9月21日发布企业凭据库存导出能力，目标是让企业看到凭据资产并支持治理。对测试团队来说，真正的难点不是导出CSV，而是把“发现—确认—轮换—撤销—验证”做成可回归流程。

先把一把密钥拆成五个事实

不要只记录名称。至少需要凭据类型、非秘密标识、所有者、最近使用时间、授权范围、来源系统、预计过期时间和轮换状态。任何字段缺失，都应该进入unknown，而不是默认安全。

一个Agent任务可能读取仓库变量、调用部署工具、访问包仓库。测试要断言它只能拿到本任务需要的凭据，并且Trace里能解释每次使用原因。

def assert_credential_use(event, task):
    assert event["credential_scope"] <= task["allowed_scopes"]
    assert event["secret_value_exposed"] is False
    assert event["reason"] in task["approved_reasons"]

轮换不能只测“新钥匙能用”

完整轮换包含：创建新凭据、灰度验证、切换引用、撤销旧凭据、验证旧凭据失败、确认缓存和副本同步失效。最容易漏的是最后两步。

准备一个教学流水线，故意让旧Token出现在三个位置：CI变量、测试脚本和本地缓存。轮换后分别触发任务，预期新Token成功、旧Token全部拒绝，且错误日志不打印完整值。

如果旧Token仍能调用某个API，不要只说“撤销失败”，要定位授权来源：组织授权、应用安装、缓存代理或另一个同名凭据。凭据库存的价值就在于把这些影子入口找出来。

用“使用证明”决定能否删除

没有使用记录不等于没人使用。可能是日志没采集、调用走了缓存，或者系统时钟错误。删除前应进入观察窗口：对每次潜在调用记录身份、目标资源、结果与业务任务ID；对高风险凭据可先降权，再观察是否有失败任务。

删除策略可分层：无授权、过期且无使用证明的直接清理；有历史使用但当前无调用的先禁用；生产发布凭据要求负责人确认和回滚方案。所有删除都要幂等并可审计。

Agent场景要测“最小可用权限”

让Agent完成退款、发包、部署三个不同任务。退款Agent不应看到npmToken；发包Agent不应读取生产数据库；部署Agent不应获得用户个人SSH目录。即使模型判断“这样更容易完成任务”，也必须被策略拒绝。

再测试失败后的行为：凭据过期、权限不足、服务超时。合格Agent应该停下来请求人工处理，而不是从环境里寻找另一把未声明的钥匙。

CI门禁和回归集

把凭据治理规则写进CI：新增高权限凭据必须有所有者和过期时间；PR不能把秘密写进日志和构建产物；轮换后旧凭据回放必须失败；权限变更要关联审批。

回归集不应只放静态扫描样本，还要放真实失败轨迹的脱敏版本：某次Agent越权、某次旧Token仍能调用、某次轮换打断发布。每次策略或平台升级后重新回放。

传统测试能力在这里很有用：状态机验证生命周期，契约测试验证授权范围，故障注入验证撤销与恢复，数据脱敏保证审计本身不泄密。

测试工程师能留下什么资产

不要只交一张凭据清单。至少交付资产字段规范、轮换状态图、最小权限矩阵、旧凭据失效用例、异常恢复报告和审计查询模板。

凭据治理最后要回答的不是“我们有多少把钥匙”，而是“每把钥匙为什么存在、谁负责、什么时候失效、失效后如何证明”。当Agent开始替人执行真实操作，这套证明能力会比单纯增加扫描工具更值钱。

一次可落地的验收顺序

建议把回归拆成四层，而不是一次性把所有风险塞进一个大脚本。第一层验证库存导出是否完整：随机抽取组织、仓库、应用和Runner，核对导出结果与权限系统中的事实数量；第二层验证生命周期：新建、启用、降权、撤销、过期每个状态都能被记录，并且重复执行不会产生第二把不可追踪的凭据；第三层验证业务行为：用真实但脱敏的退款、发包、部署任务回放调用；第四层才是Agent行为，检查它面对403、超时和缺失凭据时是否停下。

可以给每个用例加上 credential_id、task_id、trace_id 和 expected_state。这样失败后不需要翻几百行日志，而是能回答“哪把钥匙、被哪个任务、在什么状态下使用、预期应该发生什么”。这就是从Outcome Evaluation升级到Behavioral Evaluation：结果是否完成只是一个信号，过程中的权限边界和失效证据才是质量结论。

发布门禁也不要写成“扫描数量为0”。更可靠的规则是：高权限凭据必须有负责人；撤销后回放调用必须失败；失败轨迹不得出现秘密值；Agent不得通过未声明工具取得替代凭据；异常恢复必须有人工确认。任一高风险断言失败，流水线即使功能测试全绿也不能放行。