本篇文章更新時間：2026/04/10
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
開源工具也需要「零信任」：Astral 的安全實踐全解析
編輯前言：這篇文章源自 Astral 的官方分享〔Open source security at Astral〕。Astral 的工具像 Ruff、uv、ty 是無數開發者日常倚賴的基礎建設，他們如何抵禦供應鏈攻擊、確保開源版本可信？這篇文章給了我非常完整的實務框架。以下整理我最核心的收穫。
核心觀點 (Key Takeaways)
- Astral 認為 CI/CD 是安全核心，而非風險來源，但 GitHub Actions 的預設安全性其實很弱。
- 他們強調 移除長期存在的憑證，改以 Trusted Publishing、短期憑證或環境隔離。
- 安全不只技術，更是 組織治理、依賴管理、流程設計 的綜合工程。
深入解析
Astral 的出發點很務實：既然 Ruff、uv 等工具已成為社群的基礎建設，他們就必須做到比一般專案更高的安全標準。他們分享的不是理論，而是一套「在大型專案中真的可行」的安全策略。
原文指出：「GitHub Actions has poor security defaults」，這裡完全擊中痛點。
以下是讓我印象最深的幾項實作：
1. 禁用危險的 GitHub Actions 觸發事件
Astral 全組織禁用 pullrequesttarget、workflow_run 等高危險事件。他們的態度很簡單：
這些事件太容易被攻擊者利用，因此「不用比用更安全」。
若真的需要（例如 PR 留言），他們轉向 GitHub App，以一個隔離的執行環境處理敏感操作。
2. 所有 Actions 必須固定到 Commit SHA
不是 tag、不是 branch，而是 不可變的完整 SHA。並且使用 zizmor、GitHub Policies 雙重交叉檢查。
這做法直接提高可重現性，也縮小供應鏈攻擊面。
3. 極度嚴格的權限最小化
他們同時從三個層級去做：
- Org 層級預設只讀
- workflow 標準是
permissions: {} - job 若需要才升級
這讓攻擊者即使突破一層，也很難橫向擴散。
4. Release 流程多重安全閘道
Astral 的發行流程遠比一般開源專案嚴格：
- Trusted Publishing（避免長期存活的 Registry Token）
- Sigstore attestations（確保「誰」產生了 artifact）
- Release 需兩人批准
- 透過專屬 deployment environment 隔離敏感操作
- Tag 保護，避免攻擊者直接製造惡意版本
他們的目標很明確：不要讓任何單一帳號能夠單獨發行新版本。
5. 對依賴的高度警覺
Astral 對第三方依賴的態度非常務實：
- 使用 Renovate/Dependabot 維持更新
- 避免即刻升級（以免踩到被攻擊的新版本）
- 儘量減少不必要的依賴
- 貢獻回 upstream 提升整體供應鏈安全
這種「不要當生態系最軟的那一環」的心態，值得所有開源維護者參考。
筆者心得與啟發
整篇文章讓我最大的感觸是：供應鏈攻擊已經不是「大公司才需要擔心」的事了。只要你的專案被人使用，就會變成攻擊者的跳板。而 Astral 的策略展示了三個很實用的思考方向：
- 把 CI/CD 當成安全堡壘來經營，而不是只是跑測試的地方。 這其實顛覆了很多開發者的習慣。
- 流程與權限設計比技術更重要。 很多攻擊都不是 0-day，而是疏於管理或過度授權。
- 安全是團隊文化，而不是文件裡的規範。 Astral 願意禁用 GitHub Actions 的「方便功能」，就是文化的展現。
如果你維護開源專案、企業內部工具，或想降低供應鏈風險，這篇文章提供了一個非常可操作的清單。對我而言，文章最有價值的不是單一技巧，而是背後的精神：
能移除的權限就移除，能隔離的流程就隔離，能自動化的安全檢查就自動化。
這不是追求百分之百無敵，而是讓攻擊者的成本高到不值得出手。