ハクソク

世界を動かす技術を、日本語で。

アストラルにおけるオープンソースセキュリティ

31日前原文(astral.sh)

概要

  • Astral は多数の開発者が利用するツールを提供し、 セキュリティ対策 を重視
  • サプライチェーン攻撃 の増加を受け、CI/CDやリリース工程の保護策を公開
  • GitHub Actions を中心にCI/CDワークフローを構築し、独自の厳格なセキュリティルールを運用
  • リポジトリや組織管理 でも多層的な保護策を実施
  • リリース配信 や自動化にも独自のセキュリティ強化策を適用

AstralのCI/CDセキュリティ対策

  • Ruff、uv、ty などの開発を GitHub Actions ベースのCI/CDで推進
  • pull_request_target や workflow_run など危険なトリガーを全組織で禁止
  • pull_request_target 利用ケースは GitHub App やWebhookに移行推奨
  • 全アクションをコミットSHAにピン止め し、zizmorやGitHubの監査ツールで二重チェック
    • 依存アクションも全てハッシュピン を実施し、再現性と安全性を向上
  • アクション内部で バイナリの最新版を取得する等の可変性ギャップ は 手動レビュー で検出
    • ダウンロードURLとハッシュのマッピング で改ざん対策
  • ワークフローとジョブ権限を最小化 し、デフォルトは読み取り専用
  • シークレットの分離管理 （環境ごとのシークレット利用）で被害範囲を限定
  • zizmor や pinact 等のツールを活用した静的解析・自動ピン止め

Astral組織・リポジトリのセキュリティ管理

  • 管理者権限アカウントの最小化、必要なリポジトリのみアクセス付与
  • 強力な2FA必須化 （TOTP以上）、将来的には WebAuthn/Passkeys 限定も検討
  • 全体的なブランチ保護 ：mainの強制プッシュ禁止、pull request経由のみ変更可
    • advisory- *や internal- *等の特定ブランチパターン作成禁止
  • タグ保護 ：リリースデプロイ成功後のみタグ作成可、タグの更新・削除禁止
    • mainブランチ以外からのリリースデプロイ禁止
  • リポジトリアドミンによる保護回避を禁止、全保護策は組織レベルで強制
  • ブランチ・タグ制御ルールセットを公開 し、他プロジェクトの参考用に提供

安全な自動化運用（Automations）

  • GitHub Actionsでは安全に実現できない処理 （第三者PRへのコメントなど）は GitHub App で分離
    • astral-sh-bot を利用し、イベントデータを安全な環境で処理
  • GitHub App開発も通常のソフトウェア同様のセキュリティ意識が必要
    • テンプレートインジェクション等は防げるが、SQLiやプロンプトインジェクション等は要注意
  • GitHub Appでも未信頼コード実行は不可、pull_request等の安全トリガー利用が必須
  • GitHub App開発にはGidgethub等のフレームワークを推奨
    • 小規模プロジェクト向けのGitHub App運用の課題 も指摘
    • Mariatta氏のPythonによるGitHub Appチュートリアル を紹介
    • astral-sh-botのOSS化も予定

リリース配信のセキュリティ（Release security）

  • PyPI、Homebrew、Docker images等の配信経路 にも個別の対策を実施
    • Trusted Publishing の活用で長期認証情報の不要化と乗っ取りリスク低減
    • Sigstoreによるアテステーション生成 でリリース成果物とワークフローの紐付けを証明
      • uv等のリリースで実例公開
    • GitHubのImmutable Releases機能 で公開済みビルドの改ざん防止
      • 過去ビルドのすり替え攻撃への対策
  • 配信経路ごとに最適なセキュリティ策を選択 し、サプライチェーン全体の安全性を向上

このようにAstralは CI/CD、組織管理、リリース、オートメーション の各段階で多層的なセキュリティ対策を実施し、 業界全体の参考となるノウハウ も積極的に公開しています。

Hackerたちの意見

最近のTrivyやlitellmに関する事件を受けて、リリースプロセスを安全にするためのガイドがあるとすごく役立つと思う。ここにあるアドバイスは本当にしっかりしていて実行可能だから、どのチームにも読んで実践してほしいな。サプライチェーンセキュリティの怖いところは、依存関係が安全でない限り、私たちも安全じゃないってこと。使っているプラットフォームが安全でないデフォルトを持っていると、全体のチェーンを安全にするための努力がさらに大変になるんだよね。

ちなみに、実際には記事の著者であるウィリアム・ウッドラフと彼のTrail of Bitsのチームが、PyPIと協力してTrusted Publishingを実装したんだよ。

現在のソフトウェアサプライチェーンの大きな問題の一つは、多くのツールや依存関係が（例えばGitHubのリリースから）期待される著者によって公開されたかどうかの検証なしにダウンロードされていることだよ。だから、私はオープンソースで監査可能、アカウント不要、自己ホスト可能なマルチシグファイル認証ソリューションに取り組んでいるんだ。このマルチシグアプローチは、axiosのような侵害から守ることができるんだよ。興味があったら、https://asfaload.com/を見てみてね。

└

もしかしたら理解できてないかもしれないけど、リリースアテステーションの目的って、リリースが著者によって作られたことを認証することじゃないの？

└

全体的に見て、これは正しいアプローチだと思うし、こういうのが必要なんだよね。ただ、コードやあなたの製品が見えないから、どう思えばいいのかわからないな。

└

期待される著者によって公開されたという検証なしに。誰が著者であっても、自動ツールを使ってコードの各行を監査することをお勧めするよ。

NixやGuixを再発見するために人々がどれだけのことをするか、全然理解できないよ。

└

でも、そのつながりが見えないんだけど？

└

ハッシュピンニングや「マップルックアップファイル」（ロックファイル）についての段落を読んで、思わずため息が出ちゃった。

└

Windowsで動かないなら、完全な代替にはならないね。

オープンソースエコシステムはかなり進化して、レジリエンスを証明してきたよね。そして、信頼はどのエコシステムにとっても重要な部分であり続けるけど、サードパーティのコードをサンドボックス化するためのツールやプラクティスを急いで改善する必要があると思う。プロジェクト作業でuvに遭遇するたびに、提唱される利点は異なるPythonバージョンでプロジェクトを実行しやすくし、サードパーティの依存関係の衝突を避けることなんだ。基本的にはpyenv + venv + スピードって感じ。それを聞くと背筋が寒くなるよ。だって、みんながサンドボックスなしでホストマシン上でこれらの異なるツールを動かしているってことを意味するから。

└

うーん、必ずしもそうじゃないよ。Dockerの中でuvを使うことが多いけど、結構便利なんだよね。

Astralの人がこれを見ていたら教えてほしいんだけど、このレベルの努力でどうやってGithubへの依存を管理してるの？上流とのソーシャルコネクションやPyPAとも繋がってるけど、もしGithubがハッキングされたりバグがあったりして、依存している設定が変わったらどうするの？

これはすごくいい概要だね。他のオープンソースプロジェクトにとっても役立つリソースだと思う。

世界中で、署名されたパッケージのコミットから署名されたレビュー、そしてマルチ署名の決定論的アーティファクトにフルソースからブートストラップされたuvのバイナリは、私たちstagexのチームメンバーが作ったものだけだよ。すべてのキーは、25年前からの信頼のウェブに結びついたメンテナによって保持されている地理分散型スマートカードにある。5000以上のキーがあるよ。https://stagex.tools/packages/core/uv/ たまに個々のメンテナがstagexでパートタイムで働けるクライアントには感謝してるけど、プロジェクトとしては今までに50ドルの寄付が1回だけあった（ありがとう）。なんでほとんど無給のボランティアハッカーたちが、OpenAIよりもサプライチェーンセキュリティにもっと力を入れてるんだろう。イライラする。

└

なんでほとんど無給のボランティアハッカーたちが、OpenAIよりもサプライチェーンセキュリティにもっと力を入れてるんだろう。無給のボランティアハッカーは、自分の仕事を無料で提供してるし、OpenAIみたいな会社がその仕事を使うためのライセンスもあるからね。OpenAIはお金を稼ぎたいだけ。無料で手に入るものに、なんで時間やお金を使う必要があるの？

└

署名付きレビューには何を使ってるの？

└

なんでほとんど無給のボランティアハッカーたちが、OpenAIよりもサプライチェーンセキュリティにもっと力を入れてるんだろう。買収は数週間前に起こったばかりじゃなかった？もしOpenAIが彼らに強制的にビルドプロセスを変えさせてたら、もっと心配になると思うけど。この記事が彼らがずっとやってきたことを説明してるって言ってるなら、ちょっと証拠がないと無理があるよね。親会社にこのプロセスを帰属させる理由がよくわからない。もちろんOpenAIには批判すべき点がたくさんあるし、君の技術的な主張については立場を取らないけど、こういう言い方はちょっと不誠実に感じるな。

└

プライベートジェットは自分で燃料を補給するわけじゃないよね。

ハッシュを使ったバージョンピンニングと、ワークフロー内のバイナリ依存関係のためのマップルックアップに関する段落を読んで、ソフトウェアエンジニアは常にnixpkgsやflakesの劣悪なバージョンを再発明する運命にあるんだなって思った。Nixが好きなわけじゃないけど、落とし穴や変なところがたくさんある。でも、デフォルトで不変性と再現性を提供してくれるから、サプライチェーン攻撃がニュースになるたびに、他の人たちがこのことを基本から再発見しなきゃいけないことを忘れちゃうことがある。

└

悪いバージョンのnixpkgsとflakesって、静的にコンパイルされたバイナリとハッシュピンのこと？それはNixよりも前からあったよね :-)

GitHubのCIについてはあまり経験がないんだけど、もしこれが安全に使うために必要なステップの正確な説明なら…実際には安全に使えることはないと思う。Microsoftのクラウドエンジニアリングをバックエンドで信頼しても、これは特権や隔離の基本原則すら守っていないシステムに見えるんだけど、なんでこれの上に「サプライチェーンセキュリティ」を構築しようとするのか理解できない。