为开源包发布流程收紧维护者凭据：从抗钓鱼 MFA 到短期令牌与发布审计

包发布常被视为 CI 流水线的最后一步，但它实际连接着开发者账号、源代码仓库、构建环境和包注册平台。一个容易被忽略的假设是：只要启用了多因素认证，发布凭据就安全了。实际上，MFA 主要保护交互式登录；长期有效的令牌、过宽的仓库权限或可被随意触发的发布任务，仍可能让未经授权的代码进入发布流程。

加固应围绕可检查的信任边界展开：谁能登录并触发发布，哪些仓库和工作流可以申请发布权限，流水线凭据能做什么，以及如何从审计记录确认变更经过授权。下面按账号盘点、权限收紧、流水线配置、审计验证和暴露后的处置逐步落实。具体配置名称和能力会因代码托管平台、包注册平台及 CI 系统而异，实施前应以所用平台的文档和当前配置为准。

盘点发布账号与凭据

先列出每个包的发布主体，不要只盘点“维护者账号”。至少记录：

• 包注册平台上的所有者、发布者和自动化账号。
• 代码仓库中能修改发布工作流、保护规则和密钥的人员或团队。
• CI 中可读取的密钥、访问令牌、应用凭据及其用途。
• 发布工作流的触发条件、目标分支、环境和人工审批环节。
• 包的发布方式、回滚或撤回流程，以及负责响应的人员。

为每个凭据补充所有者、权限范围、存储位置、有效期、最后使用时间和轮换责任人。找不到用途或负责人的凭据，应先确认是否仍被流水线使用，再安排停用；不要在未验证依赖关系时直接删除，以免意外中断正常发布。

还要区分人的身份凭据与机器凭据。维护者账号用于登录和管理权限，CI 凭据用于完成特定自动化任务。把二者混用，会让一枚令牌同时跨越多个边界，也会使审计记录难以判断究竟是哪个主体执行了操作。

收紧开发者账号与仓库权限

为所有具有发布、管理或工作流修改权限的账号启用多因素认证，并优先采用抗钓鱼方式，例如基于安全密钥或平台支持的通行密钥机制。不要把短信验证码或一次性验证码视为与抗钓鱼认证等效。若平台支持组织级策略，应先确认其覆盖范围、例外账号及恢复流程，再逐步强制执行。

同时检查账号恢复路径：备用认证器、安全密钥登记、恢复码保管和离职账号回收都属于发布安全的一部分。恢复渠道如果弱于日常登录保护，攻击者可能绕过主要认证方式。为高权限账号保留受控的恢复流程，并记录谁可以批准恢复或重新绑定认证器。

仓库权限应按任务拆分，而不是给所有维护者相同的管理权限。能够审阅代码的人不一定需要修改发布工作流；能够触发发布的人也不一定需要管理组织成员或仓库设置。对默认分支、发布配置和工作流文件设置适当的保护要求，例如审查批准、限制直接推送，并确保保护规则本身不能被同一变更轻易绕过。

执行前先确认当前协作方式：如果项目依赖少数维护者紧急修复，应为例外制定明确的审批、记录和事后复核机制，而不是长期保留不受约束的管理员权限。调整后检查权限清单和保护规则的实际生效状态，并保留变更前后的记录。

配置流水线的短期发布凭据

优先使用包注册平台和 CI 平台共同支持的短期身份凭据机制，让工作流在发布时按需取得权限，而不是把长期令牌保存在仓库密钥中。此类机制通常依赖工作流身份声明与注册平台上的项目绑定关系；必须核对绑定的组织或账号、仓库、工作流及可选环境，避免仅凭“来自 CI”就授予发布权限。

例如，LWN 对 PyPI Trusted Publishing 的报道描述了这样一种流程：项目预先登记可信发布者，工作流在发布时提交身份令牌，平台验证匹配关系后签发短时 API 令牌；该报道提到令牌有效期为 15 分钟。这个案例可用于理解短期凭据的思路，但不能据此假定其他平台具有相同配置、有效期或验证规则。实际落地应参考对应平台的官方文档和当前设置。LWN 对 Trusted Publishing 的报道

若平台暂不支持短期凭据，应将长期令牌视为过渡方案：只授予完成上传所需的最小范围；限制可读取该密钥的工作流与仓库；避免在日志、制品、错误信息和构建参数中暴露令牌；设置可执行的轮换周期和失效处置责任人。发布凭据不应被普通测试任务、外部贡献者可控制的工作流或不受信任的拉取请求读取。

发布工作流还应固定发布输入，明确目标分支、版本来源、构建步骤和触发条件。仅在工作流中增加审批按钮并不能替代权限核查：如果同一人员可以任意修改工作流、批准发布并管理凭据，审批并没有形成独立控制。

验证发布路径与审计证据

配置完成后，用一次受控的测试发布验证实际权限，而不是只检查设置页面。测试应在非生产包、测试环境或平台支持的安全演练方式中进行，并确认以下结果：

• 未绑定的仓库或工作流无法取得发布凭据。
• 非发布任务无法读取或申请发布权限。
• 受保护分支之外的变更不能绕过预期审查直接发布。
• 发布成功后，能从记录中关联操作者、提交、工作流运行和目标包版本。
• 失败路径不会把凭据写入日志、构建制品或可被其他任务读取的位置。
• 回滚或停用凭据的步骤已验证，且不会误删仍在使用的正常发布配置。

发布审计应覆盖账号登录、认证方式或恢复信息变更、成员与角色调整、仓库保护规则变化、密钥创建和删除、工作流修改、发布触发及包版本变更。为这些事件设定负责人和告警处置路径。对于自动化事件，日志应尽可能保留工作流身份、仓库、提交和运行记录之间的关联；如果平台提供的日志无法支持这种关联，应记录这一可见性缺口，并通过 CI 运行记录或变更审查补足。

告警策略应关注异常登录、认证方式或恢复设置变化、权限提升、发布工作流文件变更、凭据新增，以及与常规流程不符的发布行为。不要只依赖失败登录告警：合法账号被盗用后，攻击者也可能使用正常的认证流程。定期抽查告警是否送达、是否有人处置，并保留调查记录。

这些控制能够降低凭据滥用和未经授权发布的风险，但不能单独阻止所有软件供应链攻击。受信任的维护者账号、构建依赖、运行环境或上游组件仍可能被攻破，因此还要结合代码审查、依赖治理、构建隔离和发布后监控。

凭据疑似暴露后的轮换与恢复

发现令牌泄露、异常登录或未经授权的工作流变更时，先按事件处置，不要只删除一条密钥记录。保留相关登录、权限、CI 运行和发布记录，记录时间范围与受影响对象，避免在调查完成前清除关键证据。

随后按影响范围执行：

1. 暂停可疑发布工作流，撤销或禁用相关令牌，并检查是否存在未授权的备用凭据。
2. 核查维护者账号、恢复方式、组织成员、仓库权限和发布配置是否被修改；必要时收回会话或重新验证高权限账号。
3. 对照提交记录和包版本，判断是否有未经授权的源码、工作流或发布产物变更；按项目既定流程通知用户、标记风险版本或撤回发布。
4. 修复受影响配置后，重新签发最小权限凭据，并验证只有预期仓库和工作流能够使用。
5. 执行一次受控复测，确认旧凭据确已失效、正常发布路径可用，并记录处置人、证据、影响判断和后续改进项。

如果轮换会中断紧急修复或正常发布，应先明确临时发布窗口和审批人，再切换凭据；不要为了维持发布速度而让旧凭据长期并存。完成恢复后，复核最初的账号、权限、流水线和审计清单，确认问题不只是“换了一枚令牌”，而是相应的信任边界和审计路径也已经恢复到可验证状态。