开源世界最脆弱的那根线，Astral想先补上：当CI/CD成了新的安全前线
开源基础设施公司 Astral 最近罕见地把自家的安全实践摊开来讲了。这个名字对普通用户可能不算家喻户晓，但在开发者圈子里，Ruff、uv 这些工具已经是很多人每天都要碰的“空气和水”。空气一旦被污染，后果往往不是一两个 bug，而是整条软件供应链被拖下水。
Astral 选择在这个时间点公开谈安全，显然不是为了做企业形象工程。过去两年，开源生态里最让人不安的，不是某个项目停更，而是大家突然意识到：真正被攻击的常常不是源码本身，而是围绕源码运转的那整套自动化系统——CI、CD、发布脚本、制品仓库、标签、凭证，甚至一条不起眼的 GitHub Actions 工作流。Trivy、LiteLLM 等近期事件让开发者越来越难再对“自动化就是省心”抱有天真想象。Astral 的这篇文章，正是对这种不安的一次正面回应。
当开发工具也开始需要“零信任”
如果说十年前的开源安全问题更多集中在依赖漏洞，比如一个库里埋了个高危 CVE；那么今天，问题已经升级成“谁在构建这个库、谁在发布它、这条流水线中间有没有人偷偷动过手脚”。这就是供应链攻击让人头皮发麻的地方：它不一定修改你的业务代码，却能在你最信任的路径上做文章。
Astral 的核心观点其实很鲜明：开发工具的可信，不该建立在“我们团队很小心”这种道德自觉上，而应该建立在一套默认收紧、可验证、可审计的工程机制上。这个思路很像近几年安全行业里越来越常见的“零信任”理念——不要默认任何环节天然安全，哪怕它来自官方、来自常用平台、来自一个看上去很熟的 Action。
这件事为什么重要？因为 Astral 做的不是小众玩具。Ruff 是 Python 生态中增长极快的静态检查与格式化工具，uv 则正试图重塑 Python 包管理与环境管理的体验。这类工具一旦出问题，受影响的不是单个项目，而是成千上万开发者的本地机器、CI 环境和生产发布流程。换句话说，Astral 自己已经是别人供应链上的一环。它越成功，就越像一个必须被认真保护的“公共基础设施”。
GitHub Actions 很方便，但它的默认安全观念并不友好
Astral 把大量篇幅给了 GitHub Actions，这很能说明问题。今天几乎所有现代开源项目都离不开它：跑测试、做构建、发版本、生成注释、同步状态，全都靠它。但方便的另一面是，GitHub Actions 的许多默认行为，对安全团队来说简直像“门没锁，钥匙还挂在门把手上”。
Astral 最激进、也最值得行业借鉴的一点，是直接在组织层面禁用了 pull_request_target、workflow_run 等高风险触发器。这个决定很有记者看了会点头的现实感：很多平台设计的问题，不是靠“写文档提醒大家小心点”就能解决的，而是应该从机制上减少误用空间。因为攻击者最喜欢的，就是那些“理论上可以安全使用，但实际上 90% 的人都会踩坑”的功能。
它的另一个重点是把 Action 全部钉死到具体 commit，而不是使用 tag 或 branch。对非安全背景的读者来说，这可以理解为：不要相信一个会变动的路标，而要锁定一张不可篡改的地图。更进一步，Astral 还检查这些 commit 是否真对应正式发布状态，防止“冒牌提交”。这已经不是常规意义上的谨慎，而是把供应链攻击中最容易被忽视的灰色地带也纳入了防御范围。
但这里最有价值的，不是“pin 到 SHA”这个结论本身，而是 Astral 诚实承认：这依然不够。因为一个不可变的 Action，也可能在运行时去下载“最新版本”的二进制文件，等于把后门从前门锁死后，又在后窗留了条缝。这种对“不可变性缺口”的提醒特别关键。行业里很多安全文章喜欢给人一种“照着清单做完就安全了”的错觉，Astral 反而说得很清楚：工具只能帮你挡住一部分风险，剩下那部分，仍然需要人工审查、上游协作和持续投入。
真正成熟的安全，不是堆功能，而是控制爆炸半径
Astral 另一套值得点赞的做法，是它没有把安全理解为“尽量不出事”，而是理解为“出了事也别一下炸穿全组织”。这是一种更成熟的防守思路。
比如权限控制上，它默认整个组织只读，再从每个 workflow 顶部开始把 permissions 清空，随后按 job 单独加权限。这种做法的妙处在于，安全边界不是靠开发者记忆，而是靠默认配置强行收口。再比如 secret 隔离，它尽量不用组织级、仓库级通用密钥，而是使用部署环境和环境专属凭证。这样即便某个测试任务被拿下，攻击者也摸不到发布制品所需的关键秘密。
这背后是一个常被低估的原则：权限最小化不是形式主义，而是现代开源项目必须具备的“损失控制能力”。因为现实世界里，没有任何团队敢拍胸脯说自己永远不会被攻破。真正的差别，在于攻击发生后，是只丢一个临时 token，还是直接被拖库、劫持发布、污染历史版本。
Astral 在组织治理层面也做得很细。限制管理员数量、强制更强的 2FA、不允许对 main 分支强推、通过组织级规则保护 tag，甚至禁止仓库管理员绕过这些防线。这些措施听上去有些“繁琐”，但恰恰说明 Astral 对开源维护的理解已经从“写软件”进化到“运营基础设施”。很多项目出事，不是因为核心代码多脆弱，而是因为组织权限太松、流程太随意、临时操作太多。安全事故往往不是黑客一脚踹开大门，而是谁顺手没关窗。
GitHub App 不是银弹，但比把敏感动作塞进工作流里更像样
文章里还有一个很值得展开的判断：有些事情 GitHub Actions 能做，但并不适合安全地做，比如给第三方 PR 自动留言、响应外部事件做高权限操作。Astral 的解决办法，是把这些任务迁移到独立的 GitHub App，也就是 astral-sh-bot。
这是一个很典型的“把高风险操作从混杂环境里剥离出来”的工程取向。GitHub Actions 最大的问题之一，是代码、事件数据和凭证常常混在同一个上下文里，开发者一不小心就会给攻击者创造模板注入、权限误用之类的机会。GitHub App 至少能把这三者拆得更开一些，减少“意外跑偏”的概率。
不过 Astral 没有神化这种模式。它也明确提醒：App 只是换了一个更可控的执行环境，不等于天生安全。App 同样可能有 SQL 注入、提示词注入，或者别的逻辑缺陷。这个表态我觉得很难得，因为它把安全讨论拉回到了工程现实，而不是产品宣传。没有银弹，只有更少耦合、更少默认信任、更少“这应该没事吧”的侥幸。
这里也暴露出一个行业矛盾：大型项目可以自己开发和托管 GitHub App，小团队和个人维护者却未必有这个预算和精力。于是，平台的不安全默认值，最后往往是最缺资源的人在承担代价。Astral 文章里对这一点其实含蓄地表达了不满：如果 GitHub Actions 的安全短板需要靠大公司和成熟项目自建外挂来弥补，那平台本身显然还有很长的路要走。
发布安全正在成为开源项目的新分水岭
很多人以为安全做到仓库和 CI 就差不多了，但 Astral 把视线继续拉到了发布环节：PyPI、crates.io、NPM、Homebrew、Docker 镜像，都是供应链上的关键节点。代码没被改，不代表用户最终安装到机器里的东西就一定没问题。
Astral 采用 Trusted Publishing，把向仓库发布软件包这件事，尽量从“长期保存一串秘密凭证”变成“基于身份和工作流临时授权”。这几乎是近几年开源发布安全里最关键的进步之一。因为太多包被劫持，根源不是代码仓库失守，而是 CI 里的 token 泄露、维护者账号被盗，或者一个用了很久没人轮换的发布密钥静静躺在某个角落。
它还使用 Sigstore 证明发布产物与具体工作流之间的可验证关联，并启用 GitHub 不可变发布功能，防止事后替换已发布构建。这听起来很技术，但本质上回答的是一个朴素问题：你下载到的那个二进制文件，到底是不是开发团队按原定流程真正构建出来的，还是某个中间人临时塞进去的“替身”？近期 Trivy 事件之所以让圈内震动，就是因为攻击者瞄准的正是 tag、release 这类大家平时默认可信的地方。
从行业视角看，Astral 这套做法最值得称道的地方，不是“全都做到了”，而是它把“发布可信”从一句品牌口号，变成了可以被验证、被约束、被追责的技术事实。未来开源项目之间的差距，可能不只体现在 star 数和性能 benchmark 上，还会体现在你是否敢公开自己的安全链路，是否愿意让别人审视你的构建与发布过程。
这也引出一个值得思考的问题：安全会不会让开源门槛越来越高？答案恐怕是会，而且已经在发生。强安全实践需要时间、工具、流程纪律，甚至需要专门的人来维护。对明星项目来说，这是成熟的代价；对个人维护者来说，可能是沉重负担。行业接下来要解决的，不只是推广最佳实践，更是把这些实践产品化、平台化、低成本化。否则，开源生态会慢慢分化成“有能力自保的大项目”和“暴露在风里雨里的小项目”。这不是我们乐见的未来。