在开源生态系统中，供应链安全已成为开发团队不可忽视的核心议题。Astral 作为 Ruff、uv 等 Python 工具链的核心维护者，近期公开了其安全审计与防护实践，为行业提供了极具参考价值的工程化范本。这些实践不仅涵盖 CI/CD 流程的加固，还包括依赖管理、发布机制以及组织层面的安全治理，形成了一套多层次的防御体系。

CI/CD 流程的安全加固

Astral 的开发流程高度依赖 GitHub Actions 以维持 Ruff、uv 和 ty 的迭代速度，但其团队清醒地认识到 GitHub Actions 存在安全默认值不足的问题。近年来 Ultralytics、tj-actions、Nx 等项目相继遭受供应链攻击，均源于 GitHub Actions 的常见漏洞如 pwn requests。针对这一风险，Astral 实施了一系列硬性约束。

首要措施是在组织层面全面禁止危险触发器。Astral 明令禁止 pull_request_target 和 workflow_run 这两类触发器，原因在于它们几乎无法安全使用，攻击者持续发现滥用方式。对于确实需要向第三方 PR 提交评论的场景，Astral 建议使用 job summaries 或完全放弃该功能，转而采用独立运行的 GitHub App 来处理此类任务。在权限控制方面，Astral 在组织级别默认使用只读权限，每个工作流以 permissions: {} 开头，仅在必要时逐个扩展 Job 级别的权限。Secrets 管理则通过部署环境（deployment environments）实现环境级别的隔离，测试或 linting 任务无法访问发布所需的凭证。

工作流依赖的安全性同样得到充分重视。Astral 要求所有 Action 必须固定到具体提交而非标签或分支，并使用 zizmor 的 unpinned-uses 和 impostor-commit 审计工具配合 GitHub 自身的策略进行双重验证。这一措施确保了工作流的 hermeticity 和可复现性，即使攻击者试图通过篡改依赖 Action 实现入侵，也会被静态分析工具拦截。

发布流程的多层防护

发布环节是供应链攻击的高发区，Astral 为此构建了由多层防护组成的发布安全机制。在发布到 PyPI、crates.io 和 NPM 等包仓库时，优先使用 Trusted Publishing 技术，该方法消除了对长期凭证的依赖，从根本上降低了凭证泄露导致的风险。对于二进制文件和 Docker 镜像，Astral 生成基于 Sigstore 的密码学 attestation，在工件与构建工作流之间建立可验证的链接，用户可据此确认所下载的 uv 或 Ruff 来自官方构建流程。

在发布控制层面，Astral 采用双人审批机制：发布环境的激活必须由至少一名其他特权成员批准。这意味着攻击者需要同时 compromise 两个账户才能发布恶意版本。标签保护规则同样严格：只有在发布部署成功后才允许创建 release 标签，且标签一旦创建即不可修改或删除。结合 GitHub 的 immutable releases 功能，任何事后替换发布物的企图都会被阻止 —— 这正是近期 Trivy 攻击中所使用的技术变体。

依赖漏洞的检测与响应

依赖安全是供应链风险的重要组成部分。Astral 使用 Dependabot 和 Renovate 保持依赖更新并接收漏洞通知，但其在基础上引入了冷却期（cooldown）机制。新版本发布后不立即更新依赖，而是等待一段时间以观察是否存在临时性 compromise—— 这是攻击者常利用的时间窗口。Renovate 支持按分组配置冷却期，Astral 对第一方依赖放宽限制，对第三方依赖保持严格控制。uv 本身也内置了依赖冷却支持。

在依赖引入策略上，Astral 持保守态度：尽量避免新增依赖，优先消除现有依赖，尤其关注引入二进制 blob 的依赖和不需要的功能特性。这种 "最小依赖" 原则显著缩小了攻击面。同时，Astral 与上游依赖项目保持紧密联系，不仅报告安全漏洞，还协助改进其 CI/CD 和发布流程的安全性。例如团队近期为 apache/opendal-reqsign 贡献了安全加固修复。

可落地的工程参数

基于上述实践，以下参数可供类似团队参考实施：工作流权限默认使用只读即 permissions: {}；依赖冷却期建议设为 3 至 7 天；发布审批需至少 1 名额外成员批准；Action 必须固定到完整 SHA 而非标签；组织层面强制要求 TOTP 及以上强度的双因素认证。

在监控层面，建议集成 zizmor 和 pinact 等静态分析工具定期审计工作流配置，监控发布部署环境的触发频率，检查依赖变更的异常模式。这些措施共同构成了供应链安全的可视化能力。

Astral 的实践表明，开源安全并非单一技术方案可解决，而是需要在 CI/CD、发布、依赖和组织治理等多个维度建立纵深防御。对于维护关键基础设施的开源项目而言，这些工程化的安全实践具有重要的借鉴意义。

资料来源：本文主要参考 Astral 官方博客《Open source security at Astral》（https://astral.sh/blog/open-source-security-at-astral）。