Astralのオープンソースセキュリティ戦略
(astral.sh)- 世界中の開発者が利用する Ruff、uv、ty などのツールを開発するAstralは、すべての製品において セキュリティと信頼性 を中核的な価値として維持している
- 近年の サプライチェーン攻撃の増加 に対応し、ビルド・配布・リリースの全工程における セキュリティ強化のための内部手法 を公開した
- GitHub ActionsベースのCI/CDでは、ハッシュ固定、最小権限、秘密情報の分離 などの多層的な保護体制を適用している
- リリース段階では、Trusted Publishing、Sigstore attestations、Immutable Releases などによって 配布の完全性 を確保している
- Astralはこのようなアプローチを通じて、オープンソースエコシステム全体のセキュリティ水準向上 と 持続可能な防御体制の構築 を目指している
Astralのオープンソースセキュリティへのアプローチ
- Astralは、世界中の数百万の開発者が利用する Ruff、uv、ty などのツールを開発しており、これらのツールの セキュリティと信頼性 を中核的な価値として維持している
- 最近では Trivy や LiteLLM のハッキング事例など、サプライチェーン攻撃が増加していることを受け、Astralは自社ツールとビルド・配布プロセスの安全性を保証するための内部セキュリティ手法を公開した
- 利用者、オープンソースメンテナー、CI/CDシステム開発者のいずれも参照できる セキュリティのベストプラクティス を共有している
CI/CDセキュリティ
- AstralはGitHub Actionsベースの 広範なCI/CDワークフロー を通じて開発と配布を自動化し、それをセキュリティの重要な構成要素として活用している
- ローカル環境ではなく、制御され観測可能な環境 でビルドとテストが実行されるようにしている
- GitHub Actionsの デフォルトのセキュリティ設定が脆弱 である点を認識し、次のような強化策を実施している
pull_request_target、workflow_runなどの 危険なトリガーを全面的に禁止- すべてのアクションを 特定のコミットハッシュ（SHA） に固定し、impostor commit かどうかを相互検証
- zizmorの
unpinned-uses、impostor-commit監査ツールとGitHubポリシーを併用 - ハッシュ固定が不可能な間接依存アクションまで含めて、依存グラフ全体をハッシュ固定
- ハッシュ固定だけでは十分でないため、手動レビューによって不変性の欠陥を検出 し、必要に応じて上流プロジェクトと協力して修正している
- 例: バイナリのダウンロードURLとハッシュを対応付けて 不変の状態で組み込み
- ワークフロー権限は デフォルトで読み取り専用 に制限し、各ジョブ単位で必要最小限の権限のみを付与している
- GitHub Secretsは 環境ごとに分離されたデプロイ環境変数 として管理し、テスト・lintジョブがリリース用秘密情報へアクセスできないようにしている
- 補助ツールとして zizmor（静的解析）と pinact（自動ハッシュ固定）を使用している
リポジトリおよび組織のセキュリティ
- Astral組織内では 管理者権限アカウント数を最小限 に抑え、ほとんどのメンバーは必要なリポジトリに対してのみ読み書き権限を持つ
- すべてのメンバーに 強力な二要素認証（2FA） を要求し、最低でも TOTP相当以上 の認証方式を用いている
- GitHubがフィッシング耐性のある方式（WebAuthn、Passkeys）のみを許可する場合は、直ちに移行する予定
- ブランチ保護ルール を組織全体に適用
mainブランチでは強制プッシュを禁止し、すべての変更はPR経由でのみ可能advisory-*、internal-*など特定のブランチパターンの作成を禁止
- タグ保護ルール によって、リリース配布成功後にのみタグを作成可能
- タグの変更・削除は禁止、
mainブランチからのみリリース可能
- タグの変更・削除は禁止、
- リポジトリ管理者であっても保護ルールを回避できず、すべての保護は組織レベルで強制される
- Astralはこうしたルールセットを gist として公開しており、他プロジェクトでも参考にできる
自動化
- GitHub Actionsでは、サードパーティPRへのコメント投稿など一部の作業を安全に実行できない
- Astralはそのために astral-sh-bot GitHub App を用い、Actionsの外部でイベントを安全に処理している
- GitHub Appは同じイベントデータを受信するが、コードとデータが分離された環境 で実行される
- ただし、Appも 機密性の高い認証情報を取り除くわけではない
- SQLi、プロンプトインジェクションなどの脆弱性が存在し得るため、一般的なソフトウェアと同等のセキュリティ水準で開発する必要がある
- Appを使うことがそのまま 非信頼コード実行の安全性保証 を意味するわけではない
- GitHub App方式は セキュリティ面では有利だが複雑性が増す
- Appの開発・ホスティングが必要で、個人開発者や小規模プロジェクトには負担となる
- Python向けの Gidgethub フレームワークが開発を簡素化する
- Astralは astral-sh-botをオープンソースとして公開する計画 であり、参考資料として Mariattaのチュートリアル を推奨している
リリースセキュリティ
- AstralのツールはGitHubのほか、PyPI、Homebrew、Dockerイメージ など多様なチャネルで配布されている
- サプライチェーン攻撃を防ぐため、次のような対策を実施している
- Trusted Publishing を使用してレジストリ認証情報を排除
- Sigstoreベースのattestations を生成し、ビルド成果物とワークフロー間の 暗号学的な結び付きを保証
- GitHubの Immutable Releases 機能によって公開後の改変を防止
- ビルドキャッシュを使用しない ことでキャッシュ汚染攻撃を遮断
- リリース工程は 専用のデプロイ環境（deployment environment） で分離
- リリース環境の有効化時には 別のチームメンバーの承認が必要 であり、単一アカウント侵害による悪意あるリリースを防止
release-gate環境と GitHub Appベースの承認中継 により多段階承認を維持- タグはリリース成功後にのみ作成可能
- スタンドアロンインストーラー（standalone installer） は内蔵チェックサムでバイナリ完全性を検証
- リリース後のドキュメント、バージョンマニフェスト、pre-commitフック更新などは 専用ボットアカウントと細分化されたPAT で実施
- 今後は macOS・Windows向けコード署名 の追加を予定
依存関係のセキュリティ
- Astralは Dependabot と Renovate を使って依存関係の更新と脆弱性通知を管理している
- クールダウン（cooldown） 期間を設け、新規リリース直後の更新を遅らせることで、一時的なサプライチェーン攻撃リスクを緩和している
- Renovateはグループごとのクールダウン設定をサポートしており、自社依存関係には緩和を適用
- 主要な上流プロジェクトと 継続的な協力およびセキュリティ貢献 を行っている
- 例: apache/opendal-reqsign のCI/CDセキュリティ強化に貢献
- Python Packaging Authority、Python Security Response Team などと協力し、セキュリティ情報を共有している
- 新しい依存関係の追加は慎重に検討 し、不要な依存関係の削減を進めている
- 特に バイナリブロブを含む依存関係を避け、不要な機能を無効化
- OSS Fund を通じて中核的なオープンソースプロジェクトへ資金提供している
結論と重要な教訓
- オープンソースセキュリティは 技術的問題と社会的問題が複合したもの であり、継続的な対応が必要
- Astralが強調する主要原則
- CI/CDの限界を認識 し、避けられない場合はGitHub Appなど外部隔離方式を使う
- 長期認証情報の排除と最小化、Trusted PublishingとOIDC認証の活用
- リリースプロセスの強化、承認・タグ・ブランチルールおよびImmutable Releaseの適用
- 依存関係への認識を維持 し、ツールと協力を通じて上流プロジェクトのセキュリティもともに強化
- Astralはこれらの手法を継続的に評価・改善し、攻撃者の行動変化に合わせて防御体制を進化 させていく予定
脚注の要約
- PyPIの PEP 740 はattestationsのアップロードを許可しているが、現在のAstralのTrusted Publishing実装とは互換性がなく、適用は保留中
- インストールスクリプト内のチェックサムは
curl ... | bashで直接実行する場合には効果が限定的だが、CI/CD内でのベンダリング時には有用
1件のコメント
Hacker Newsのコメント
GitHubのCIを安全に使うには、あまりに多くの手順を踏まなければならないように思う
こういう構造では、セキュアに運用するのは不可能だと思う
権限分離や隔離といった基本原則すら守られていないシステムの上にサプライチェーンセキュリティを積み上げるのは無理があるという印象
ただ、設定があまりに繊細で、スケーラブルなアプローチには見えない。デフォルトがもう少し安全寄りになれば、かなり良くなると思う
記事を読み終えると、この複雑さ自体がこの領域の本質的な問題なのかもしれないとも感じる
ほとんどは不変リリースをサポートしておらず、サポートしていても新しいバージョンを自動で引っ張ってくる構造なので攻撃に弱い
本当に安全にするには、検証済みの依存関係を固定バージョンで自前のレジストリに管理する必要があるが、それはGoogleクラスでないと難しい
私たちのチームが作った stagex のuvバイナリは、世界で唯一、完全なソースブートストラップと複数署名された決定論的アーティファクトでビルドされている
25年もののWeb of Trustと、5000個以上の鍵で結ばれたスマートカードベースの署名体系を使っている
それなのに、こうしたサプライチェーンセキュリティをボランティアのほうが熱心にやっているのはもどかしい
OpenClawのようなツールが鍵や秘密を漏えいさせる作りでも、ユーザーはそれを使い続ける
あなたは攻撃面を減らそうとしているが、市場はむしろ広げている
ボランティアがいなければDebianのようなプロジェクトも存在しない。不満を言うより、より良い結果で競争すべきだ
結局のところ第三者がビルドした成果物を提供しているわけで、脅威モデルが何なのか明確ではない
uvのすべてのビルドは固定された解決結果から行われ、署名付きアーティファクトを提供している。別のアイデンティティ集合で署名されたコミットの価値は不明瞭だ
OpenAIがわざわざ費用をかけてサプライチェーンセキュリティを強化する理由はない
技術的な批判は理解できるが、このタイミングでOpenAIの責任にするのは無理があると思う
参考までに、PyPIのTrusted PublishingはWilliam WoodruffとTrail of Bitsのチームが一緒に実装したもの
Astralのチームに聞いてみたい。ここまで努力しながら、なおGitHub自体に大きく依存している状況をどう管理しているのだろうか
GitHubが侵害されたり、バグで設定が変わったりしたらどう対応するのか？
オープンソースエコシステムは回復力が高いが、サードパーティコードのサンドボックス化は依然として不十分だ
uvを使うたびに、複数のPythonバージョンを簡単に管理できる利点が強調されるが、そのぶんホストマシン上で隔離なしに実行されることを意味するので不安になる
現在のサプライチェーンの大きな問題は、多くのツールや依存関係が出所の検証なしにダウンロードされていることだ
そこで私は、オープンソースのマルチシグファイル認証ソリューションである asfaload を開発中だ
axiosのような事故を防げる構造になっている
GitHub ActionsをコミットSHAで固定しても、そのアクションが別の依存関係を引っ張ってくるなら依然として危険だ
本当の解決策は、CIパイプラインでコードを直接所有するか、フォークして自前で保守することだ
すべてのアクションを監査し、可変の依存関係があれば修正または置き換える（Astral所属です）
スタック全体を自前で管理するのが最も安全だが、現実的ではない
ハッシュ固定は、ほとんど無償で得られるセキュリティ強化策だ
結局は、どこまで信頼するのかを明確に認識することが重要だ
最近のTrivyやlitellmの件を見ると、リリースプロセスのセキュリティガイドは本当に必要だ
この記事の助言は実践的で、すぐ適用できる
サプライチェーンセキュリティの核心は、私たちが依存するプラットフォームのデフォルト設定がどれだけ安全かにかかっている
素晴らしい概要だ。他のオープンソースプロジェクトにとっても有用な参考資料になりそうだ
私はPython CLI兼再利用可能なワークフローツールである
repomaticをメンテナンスしているこの記事のセキュリティ慣行の大半をデフォルトで含めている
目標は、セキュリティがデフォルトになる環境を作ることだ
この記事を読んで、フォークPRの承認ポリシー検査を追加した
詳しくは GitHubリポジトリ を参照