Astral 的开源安全实践
内容提要
Astral 分享了其开源工具的安全实践：在 CI/CD 中禁用危险触发器、固定 Action 提交哈希、最小化权限并隔离密钥；组织层面强制强 2FA、保护分支与标签；发布采用可信发布、Sigstore 证明和不可变版本；依赖管理使用 Dependabot、Renovate 并设置冷却期。核心是消除长期凭证、强化发布流程并持续关注依赖风险。
延伸解读
CI/CD 安全：禁用危险触发器与固定 Action 哈希
Astral 在 CI/CD 中全面禁用 pull_request_target 和 workflow_run 等危险触发器，因为这类触发器几乎无法安全使用，且常被攻击者利用。同时，所有 Action 必须固定到具体提交哈希，而非可变的标签或分支，并通过 zizmor 和 GitHub 策略双重检查，防止冒名提交。这些措施提升了工作流的可复现性和封闭性，但文章也指出，哈希固定仅保证内容不可变，无法阻止内容做出可变决策，仍需人工审查。
组织与发布安全：强制强 2FA 与可信发布
Astral 在组织层面强制所有成员使用不弱于 TOTP 的强 2FA，并设置分支和标签保护规则，如禁止强制推送、要求 PR、限制发布标签创建等。发布流程采用可信发布和 Sigstore 证明，消除长期凭证，并利用不可变版本防止构建被篡改。发布环境需至少一名其他成员手动批准，且发布标签在部署成功后才创建，从而增加攻击者需同时攻破多个账户的难度。
依赖管理：冷却期与生态协作
Astral 使用 Dependabot 和 Renovate 管理依赖，并设置冷却期，避免在新版本发布后立即更新，以降低临时被污染依赖的影响。Renovate 支持按组配置冷却期，可对第一方依赖放宽要求。此外，他们与上游项目保持社交联系，贡献安全修复，并与 PyPA、Python 安全响应团队等共享信息。对新增依赖持保守态度，避免二进制 blob，并审查依赖功能，同时通过 OSS Fund 提供资金支持。
Q&A
Astral 在 CI/CD 中禁用了哪些危险的 GitHub Actions 触发器？为什么？
Astral 在整个 GitHub 组织中禁用了 pull_request_target 和 workflow_run 等危险触发器。因为这些触发器几乎无法安全使用，攻击者不断找到滥用方式，且大多数使用场景可以用权限更低的触发器（如 pull_request）替代或直接移除。
Astral 如何确保 GitHub Actions 的不可变性？
Astral 要求所有 action 固定到特定提交哈希（而非可变的标签或分支），并通过 zizmor 的 unpinned-uses 和 impostor-commit 审计以及 GitHub 的“要求 action 固定到完整提交 SHA”策略进行交叉检查。此外，他们还手动审查 action 依赖，以发现并修复不可变性缺口，例如为二进制文件嵌入下载 URL 与加密哈希的映射。
Astral 如何隔离和管理 CI/CD 中的密钥？
Astral 尽可能隔离 GitHub Actions 密钥：不使用组织或仓库级密钥，而是使用部署环境和环境特定密钥。这限制了潜在泄露的影响范围，例如测试或 lint 作业无法访问发布所需的密钥。
Astral 在组织层面采取了哪些安全措施来防止账户和仓库被入侵？
Astral 限制具有管理员等高权限角色的账户数量，强制所有成员使用强 2FA（至少 TOTP），实施组织级分支保护规则（如 main 分支禁止强制推送、必须通过 PR），禁止创建特定分支模式（如 advisory-* 和 internal-*），设置标签保护规则（发布标签需在发布部署成功后才创建，且需手动批准，标签不可更新或删除），并禁止仓库管理员绕过这些保护。
Astral 在发布安全方面采用了哪些技术来防止供应链攻击？
Astral 使用 Trusted Publishing 消除长期注册表凭证，生成 Sigstore 证明以建立制品与工作流的加密链接，使用 GitHub 的不可变发布功能防止构建被篡改，发布时不使用缓存以避免缓存投毒，并通过专用部署环境、双人批准、标签保护规则等保护发布流程。
Astral 如何管理依赖安全？
Astral 使用 Dependabot 和 Renovate 保持依赖更新并通知已知漏洞，同时设置冷却期以避免在新版本发布后立即更新。他们与上游依赖维护者保持联系并贡献安全修复，保守地添加新依赖，避免二进制 blob，并仔细审查依赖功能。此外，他们通过 OSS Fund 提供财务支持。
