扩展发布不再长期保存密钥：Trusted Publishing 的信任链要核对哪些环节

简单说，Trusted Publishing 把“在 CI 里存一个长期 PAT（Personal Access Token，个人访问令牌）”换成了“由 CI 平台出示身份，由 Marketplace 验证后签发短期凭证”。密钥不再长期落盘，但信任关系并没有消失，只是从“一串字符串”转移到了几个配置点上。这篇按执行方、身份签发方、信任锚、凭证四个角色拆开，说明哪些环节必须逐个核对，哪些行为本次材料没有覆盖。

本文依据的是 Microsoft for Developers 2026 年 10 月 28 日发布的公告Publish Visual Studio Marketplace extensions securely with Trusted Publishing。公告给出了配置路径与生命周期规则，但没有展开故障排查和审计日志能力，涉及这些部分时下文会明确标注“待核实”。

一、先认清信任链上的四个角色#

材料描述的流程可以归纳为四步：CI/CD 系统向 Marketplace 出示联邦身份；Marketplace 验证 GitHub 的 Trusted Publishing 策略，或 Azure Pipelines 的工作负载身份；发布工具用这个已通过验证的身份发布扩展；全程没有 PAT 需要取出或管理。

把这四步展开，就是四个需要分别核对的角色：

• 执行方：具体哪个 GitHub 工作流，或哪条 Azure Pipelines 作业在发起发布。
• 身份签发方：GitHub 的 OIDC，或经工作负载身份联合（Workload Identity Federation，WIF）由 Microsoft Entra 签发的身份。
• 信任锚：Marketplace 发布者下配置的 Trusted Publishing 策略（GitHub 路径），或发布者上被授予角色的那个身份（Azure Pipelines 路径）。
• 凭证：验证通过后签发的短期令牌。材料明确写了，GitHub Actions 场景下该凭证 15 分钟后过期。

核对顺序建议从上往下走：先确认“是谁在发布”，再确认“Marketplace 凭什么信它”，最后确认“凭证活了多久、用在哪一步”。

二、GitHub Actions：策略字段就是一张白名单#

GitHub 路径的信任锚是发布者下的一条策略。材料给出的字段与填写要求如下，示例值取自官方说明。

这四个字段合起来，实际上定义了“哪一个仓库的哪一个工作流文件有权发布”。由此可以做一个推断：真正决定信任边界的，是这个工作流文件本身的可修改范围——谁能改这个文件、谁能改它引用的脚本，谁就事实上能通过这条链路触发发布。公告没有讨论这一点，它属于阅读配置规则后应当自行补上的核对项，而不是材料给出的结论。

环境字段是可选项。如果工作流已经绑定了 GitHub Environment，把它填进策略，相当于让信任锚多包含一层条件。反过来，如果工作流没有使用环境却填了值，或者使用了环境却留空，具体会出现什么行为——是发布被拒，还是环境约束被跳过——本次材料没有说明，待核实。

三、私有仓库的 48 小时窗口是运维细节，不是安全边界#

公告对 GitHub 策略的生命周期给出了明确规则，并且强调激活行为取决于仓库可见性：

• 私有仓库下新建的策略处于临时激活状态，有效期为 48 小时。
• 在这 48 小时内，第一次成功的令牌交换会让策略永久激活。
• 如果窗口期内没有使用，策略会过期，届时可以重新打开，再获得一个 48 小时窗口。
• 每条策略的状态和最后使用时间，都可以在 Trusted Publishing 页面查看。

这条规则对迁移节奏有直接影响：私有仓库不适合“提前几天建好策略，等着下次发版”。建完策略后要尽快跑一次发布流程，把首次交换完成，否则窗口过期还得重来。

需要收窄的一点是：材料只描述了私有仓库的行为，并说明公开仓库的策略激活方式不同，但没有给出公开仓库的具体规则。如果你的仓库是公开的，请不要直接把 48 小时套用上去，应以官方文档为准，这部分待核实。

四、Azure Pipelines 走的是另一条链路#

这是最容易配错的地方。公告写得很直接：Azure Pipelines 使用带 WIF 的 Azure DevOps 服务连接，而不是 GitHub 那种 Trusted Publishing 策略；文中还特别提醒，不要为 Azure Pipelines 在 Marketplace 的 Trusted Publishing 页面创建策略。

Azure Pipelines 的核对项是另外三项：

1. 配置一个使用工作负载身份联合的服务连接，可以被 Microsoft Entra 应用注册加服务主体支撑，也可以由托管身份支撑。
2. 把这个身份添加到 Visual Studio Marketplace 发布者下，并授予 Contributor 角色。
3. 把发布步骤配置为使用该 WIF 服务连接。

对比一下两条路径的信任锚，性质并不相同：GitHub 侧锚定的是“仓库 + 工作流文件”这组字符串，Azure 侧锚定的是“某个 Entra 身份 + 它在发布者上的角色”。因此两套核对清单不能互相套用。尤其是 Azure 路径，发布权限直接取决于发布者上被授予 Contributor 的身份名单，这份名单本身就是需要定期复核的对象。

五、15 分钟凭证能管住什么#

材料给出的唯一具体时长是：GitHub Actions 场景下，Marketplace 签发的临时凭证 15 分钟后过期。

合理的理解是：它缩短的是凭证一旦泄露后的可用时间窗口，让“长期密钥躺在 CI 变量里”这个风险点消失。但它不改变“谁有权发起交换”这一判断——那条判断仍然由策略字段和发布者角色决定。这一点属于基于机制的解释性推断，公告本身只陈述了凭证有效期这一事实。

另外，公告没有说明排队等待、失败重试对凭证签发与过期的影响。如果发布作业存在长时间排队，这部分行为待核实。

六、从 PAT 迁移的核对顺序#

公告对 GitHub Actions 的迁移路径给了明确步骤，关键点是先验证、后删除。文中建议保留 PAT，直到第一次 Trusted Publishing 运行验证成功；成功后再删掉不再使用的 secret，以免它被其他工作流步骤意外调用。

1. 为该仓库与工作流创建 Trusted Publishing 策略。
2. 在发布 job 上添加 id-token: write 权限。
3. 把发布命令改为使用 OIDC。
4. 运行工作流，确认 OIDC 发布成功。
5. 确认成功后，从工作流与仓库 secret 中移除 Marketplace PAT。

下面这段只示意材料中明确提到的权限项。完整的发布步骤（包括 vsce 的 OIDC 用法）公告指向 Visual Studio Code 文档中的专门指南，本文不代为编写，也未执行验证。

# 未执行的示例：仅示意材料明确提到的权限声明
permissions:
  id-token: write   # 发布 job 需要 OIDC 令牌签发权限

Azure Pipelines 的迁移顺序不同：先配置 WIF 服务连接和发布者身份，再把发布步骤改为使用该连接，成功之后再移除 PAT，且不需要在 Marketplace 创建策略。

还有一点值得注意：材料说明基于 PAT 的发布方式继续可用，可以按自己的节奏采用 Trusted Publishing。这意味着迁移不是强制性的紧急切换，但也意味着“未迁移的流水线”仍是一条需要单独记账的长期密钥路径。

七、清单之外，建议自己补的几项#

• 发布者上的 Contributor 名单：Azure 路径下这直接等同于发布权限，GitHub 路径下也需要知道还有谁可以手动发布。
• 策略的“最后使用时间”：页面提供这项信息，可用于确认预期内的工作流是否真的在用它。
• 工作流文件的可写范围：如前所述，这是 GitHub 路径下实质的信任边界，属于推断，但值得纳入复核。
• 旧 PAT 的残留副本：公告只提到工作流与仓库 secret，其他位置是否存在副本需要自行排查。
• 策略变更记录与更细的审计日志：本次材料只提到策略状态与最后使用时间，是否有更完整的审计能力待核实。

Trusted Publishing 消除的是“长期密钥需要保存和轮换”这一类风险，但它把责任转移到了配置的精确性上：字段填错、环境留空、Azure 路径误建策略、迁移后忘删旧 PAT，任何一种都会让这条链路的实际安全性与预期不一致。把它当成一次性的配置任务，不如当成一份需要定期对照的清单。