Ruff・uvを手がけるAstralが公開したオープンソースセキュリティ戦略の全貌
(astral.sh)Astralは、世界中で何百万人もの開発者が依存するツール（Ruff、uv、ty）を開発しており、最近のTrivyとLiteLLMのサプライチェーン侵害事件を受けて、自社のセキュリティ実践を公開した。対象読者は3つの層だ。ユーザー、他のオープンソースメンテナー、CI/CDシステムの開発者。
1. CI/CDセキュリティ
GitHub Actionsのセキュアなデフォルト設定は脆弱で、Ultralytics・tj-actions・Nxなどの侵害事例はいずれもpull_request_targetのような危険なトリガーに起因していた。Astralの対応方針は次のとおりだ。
危険なトリガーを全面禁止
pull_request_targetやworkflow_runなど、安全に使うことがほぼ不可能なトリガーを組織全体で禁止する。多くのプロジェクトはこのトリガーが必要だと考えているが、実際には権限の低いpull_requestトリガーや単純なワークフローログで十分なケースがほとんどだ。
アクションのコミットハッシュ固定（Hash Pinning）
タグやブランチ（変更可能）ではなく特定のコミットSHAに固定し、そのコミットが実際のリリース状態と一致するかを相互検証して「なりすましコミット」を防ぐ。zizmorとGitHub自体のポリシーを併用し、間接的に呼び出されるネストされたアクションまで含めてすべてハッシュ固定を適用する。
最小権限の原則
組織レベルでデフォルト権限を読み取り専用に設定し、すべてのワークフローはpermissions: {}で始め、ジョブ単位で必要な権限だけを追加する。シークレットも組織・リポジトリレベルではなくデプロイ環境ごとに分離し、テストジョブがリリース用シークレットにアクセスできないようにする。
2. リポジトリおよび組織のセキュリティ
管理者や高権限アカウントの数を最小限に抑え、組織メンバーの大半には必要なリポジトリへの読み書き権限だけを与える。2FAはGitHubのデフォルト（方式は問わない）より強いTOTP以上を必須とし、今後はWebAuthn・パスキーのみを許可する方向で強化する計画だ。
mainブランチには強制プッシュ禁止・プルリクエスト必須の保護ルールを適用し、リリースタグはデプロイ成功後にのみ作成できるようにしている。特に、リポジトリ管理者であってもこれらのルールを迂回できないよう、組織レベルで強制している。
3. 自動化（GitHub App活用）
サードパーティーPRへのコメント投稿のように、GitHub Actionsでは安全に実行できない作業はastral-sh-bot GitHub Appに分離する。ただしGitHub Appにも脆弱性がないわけではなく、信頼できないコードの実行が必要な場合は必ずpull_requestトリガーを使うべきだと強調している。
4. リリースセキュリティ
PyPI・crates.io・NPMには、長期資格情報なしでデプロイできるTrusted Publishingを利用し、バイナリやDockerイメージにはSigstoreベースの証明（attestation）を付与して、リリースアーティファクトとワークフローの暗号学的な結び付きを提供する。
GitHubのイミュータブルリリース（immutable releases）機能を使って公開済みビルドの事後改ざんを防ぎ、リリースビルド中のキャッシュ利用を禁止してキャッシュポイズニング攻撃を防ぐ。
リリースプロセス自体も二重に保護される。リリース環境の有効化には、組織内の別の権限を持つメンバー少なくとも1人による手動承認が必要だ。つまり悪意あるリリースを行うには、強力な2FAで保護されたアカウント2つを同時に侵害しなければならない。
5. 依存関係のセキュリティ
DependabotやRenovateで依存関係の更新と既知の脆弱性通知を管理しつつ、新しいリリース直後には即時更新しない「クールダウン（cooldown）」ポリシーも併用する。一時的に侵害された依存関係の影響を最小化するためだ。uvにはこの機能が組み込まれている。
Python Packaging Authority（PyPA）やPython Security Response Teamなど隣接するプロジェクト・ワーキンググループとの社会的なつながりを維持し、pipに報告された問題がuvにも影響するような場合に情報を共有している。新しい依存関係の追加には保守的に臨み、バイナリブロブを含む依存関係は避け、不要な機能は無効化する。
依存しているプロジェクトの持続可能性のため、OSS Fundを通じた資金面での貢献も続けている。
重要な推奨事項の要約
Astralが強調する4つの重要原則は次のとおりだ。CI/CDの限界を認識し、安全に実行できない作業は思い切って諦めるかGitHub Appに分離すること、長期資格情報は可能な限りなくし最小範囲に分離すること、デプロイ環境・承認・不変タグなどでリリースプロセスを強化すること、依存関係ツリー全体の健全性を継続的に把握すること。
示唆
PyPIやサプライチェーンセキュリティに深く関わる立場から見ると、この記事は単なるセキュリティガイドを超え、オープンソースエコシステム全体の信頼構造をどう設計するかについての実践例だ。特にTrusted Publishing・クールダウンポリシー・二重承認のリリースプロセスは、規模のあるオープンソースプロジェクトなら参考になる。
まだコメントはありません。