--- title: "Astral 开源安全审计实践：Ruff 与 uv 的供应链安全工程流程" route: "/posts/2026/04/09/astral-open-source-security-audit/" canonical_path: "/posts/2026/04/09/astral-open-source-security-audit/" canonical_url: "https://blog2.hotdry.top/posts/2026/04/09/astral-open-source-security-audit/" markdown_path: "/agent/posts/2026/04/09/astral-open-source-security-audit/index.md" markdown_url: "https://blog2.hotdry.top/agent/posts/2026/04/09/astral-open-source-security-audit/index.md" agent_public_path: "/agent/posts/2026/04/09/astral-open-source-security-audit/" agent_public_url: "https://blog2.hotdry.top/agent/posts/2026/04/09/astral-open-source-security-audit/" kind: "research" generated_at: "2026-04-10T19:18:13.998Z" version: "1" slug: "2026/04/09/astral-open-source-security-audit" date: "2026-04-09T00:00:00+08:00" category: "security" year: "2026" month: "04" day: "09" --- # Astral 开源安全审计实践：Ruff 与 uv 的供应链安全工程流程 > 深入解析 Astral 如何通过 CI/CD 安全强化、依赖漏洞检测与修复机制，保障 Ruff 与 uv 等核心工具的供应链安全。 ## 元数据 - Canonical: /posts/2026/04/09/astral-open-source-security-audit/ - Agent Snapshot: /agent/posts/2026/04/09/astral-open-source-security-audit/index.md - 发布时间: 2026-04-09T00:00:00+08:00 - 分类: [security](/agent/categories/security/index.md) - 站点: https://blog2.hotdry.top ## 正文 在开源生态系统中，供应链安全已成为开发团队不可忽视的核心议题。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）。 ## 同分类近期文章 ### [Rust 供应链攻击防御策略：从真实事件到可落地参数](/agent/posts/2026/04/11/rust-crates-supply-chain-security-strategies/index.md) - 日期: 2026-04-11T03:05:28+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 分析 crates.io 近年供应链攻击真实案例，提取 Cargo.lock 版本固定、CI 验证、审计工具配置等可落地防御参数。 ### [WireGuard Windows 内核驱动签名困境：微软 Partner Center 账户停用技术分析](/agent/posts/2026/04/11/wireguard-windows-kernel-driver-code-signing-microsoft-partner-center/index.md) - 日期: 2026-04-11T00:25:59+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 深度解析 WireGuard Windows 版面临的微软代码签名停用问题，涵盖内核驱动签名机制、EV 证书要求与兼容性解决方案。 ### [CPU-Z与HWMonitor供应链沦陷：恶意二进制分发机制深度分析](/agent/posts/2026/04/10/cpuz-hwmonitor-supply-chain-malware-analysis/index.md) - 日期: 2026-04-10T23:25:52+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 硬件监控工具CPU-Z与HWMonitor遭遇供应链攻击，分析恶意二进制分发机制与用户系统渗透路径，提供可落地的检测与防御参数。 ### [CPU-Z/HWMonitor 供应链投毒事件工程复盘：签名校验失效与二进制审计自动化实践](/agent/posts/2026/04/10/supply-chain-malware-cpuid-binary-audit/index.md) - 日期: 2026-04-10T22:50:31+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 深度剖析 CPUID 供应链恶意软件事件的工程根因，聚焦签名校验局限、依赖链渗透路径与二进制审计自动化落地方案。 ### [FBI如何通过iOS通知缓存提取已删除Signal消息：技术原理与防护参数](/agent/posts/2026/04/10/fbi-ios-notification-signal-message-recovery/index.md) - 日期: 2026-04-10T20:01:48+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 分析FBI利用iOS通知系统缓存提取已删除Signal消息的技术机制，并给出可操作的隐私防护配置参数。