Google Developers Japan

最近、世界のオープンソース ユーザーを震撼させるソフトウェア攻撃が話題になっていますが、そのような攻撃の多くは、サプライ チェーンの不完全性に起因しています。つまり、ビルドサーバーに侵入した攻撃者は、悪意のあるソースファイルを使って侵害したビルド プラットフォームに悪意のあるアーティファクトを注入し、信頼されたビルダーをバイパスして悪意のあるアーティファクトをアップロードします。

こういった攻撃は、配信されるアーティファクトが想定されるソフトウェアの制作元によるものでないことを検知する仕組みがあれば、防ぐことができたはずです。しかし、これまでは、ソフトウェア アーティファクトがいつ、どこで、どのように生成されたかがわかる検証可能な情報（来歴と呼ばれる情報）を作成するのは困難でした。この情報があれば、ユーザーはアーティファクトをソースまでさかのぼって検証したり、使用するソフトウェアについてのリスクベースのポリシーを作成したりできます。現在、来歴の生成は広くサポートされてはおらず、既存のソリューションでは、ビルドプロセスを Tekton Chains などのサービスに移行しなければならない場合もあります。

このブログ投稿では、偽造できない来歴を生成する新手法について説明します。この手法では、分離に GitHub Actions ワークフローを、正当性の証明に Sigstore の署名ツールを利用します。この手法を使うと、GitHub ランナーを利用するプロジェクトで SLSA 3（4 つある SLSA「レベル」の 3 つ目で、数字が大きいほど信頼性が高い）を実現でき、アーティファクトが正当で信頼できるものであることをユーザーに対して証明できます。

来歴

SLSA（「Supply-chain Levels for Software Artifacts」）は、ソフトウェア アーティファクトのサプライ チェーン レベルを表すフレームワークで、開発サイクル全体でプロジェクトの完全性を維持するためのものです。ユーザーは、リリースされたソフトウェアの最終製品をソースまでさかのぼることができます。高い SLSA レベルを実現することで、アーティファクトがデベロッパーの意図したものであることを示す信頼性が向上します。

このブログ投稿では、ビルドの来歴に注目します。ビルドの来歴は、ユーザーにとって重要なビルド情報を提供します。たとえば、誰がリリース プロセスを実行したのか、このビルド アーティファクトは悪意のある改ざんに対して保護されているか、といった内容です。ソースコードの保護方法を表すソースの来歴については、今後のブログ投稿で触れたいと思いますので、ご期待ください。

偽造できないビルド来歴を生成する Go プロトタイプ

改ざんできないビルドの証拠を作成し、ユーザーがそれを検証できるようにするには、以下のことが必要です。

1. ビルドプロセスから来歴生成処理を分離する
2. ワークフローに干渉するメンテナから分離する
3. 来歴の検証時にビルダーの身元を確認できる仕組みを提供する

最初の 2 つのポイントに記述されている分離を行うことで、ユーザーは来歴が忠実に記録されたものであるという信頼を得ることができます。これが保証されたエンティティを、信頼されたビルダーと呼びます。

私たちの Go プロトタイプは、3 つの課題すべてを解決します。加えて、ビルドは信頼されたビルダーの中で行われます。これは、ビルドで SLSA 3 の一時性要件と分離要件が達成されていることを示す保証になります。

機能の仕組み

信頼されたビルダーは、次の手順で作成します。信頼されたビルダーは、ビルドとメンテナの干渉から分離された環境で来歴を生成するために必要になります。

ステップ 1: GitHub ランナーで再利用可能なワークフローを作成する

GitHub の再利用可能なワークフローを利用すると、メンテナの呼び出し元ワークフローとビルドプロセスの両方から分離した仕組みを実現できます。このワークフローで Github Actions を使い、それぞれのジョブについて仮想マシン（VM）の新しいインスタンス（これをランナーと呼びます）を作成します。別の VM を作成することで、信頼されたビルダーに必要な分離を実現します。その結果、複数の異なる VM によってプロジェクトがコンパイルされ、SLSA の来歴が生成されて署名されます（下の図を参照）。

GitHub にホストされたランナーでワークフローを実行することで、実行するコードが実際に意図したワークフローであることが保証されます。セルフホストのランナーでは、この点は保証されません。このプロトタイプでは、ワークフローで定義された厳密なコードを実行するために、GitHub を利用しています。

再利用可能なワークフローでは、メンテナから干渉を受ける可能性もなくなります。この仕組みがない場合、メンテナがビルダーに干渉するようなワークフローを定義する可能性があります。再利用可能なワークフローを扱う唯一の方法は、呼び出し側のワークフローに公開される入力パラメータを使うことです。そのため、メンテナが環境変数、ステップ、サービス、デフォルトによって情報を改変することはできなくなります。

この手法では、いずれかのジョブ（ビルドステップなど）が、別のジョブ（来歴ステップ）によって使われる他のアーティファクトを改ざんする可能性をなくすため、信頼されたチャンネルを使ってデータの完全性を維持しています。ジョブ出力を使ってハッシュを送信し（サイズ制限があるため）、そのハッシュを使って信頼されていないアーティファクト レジストリを通して受け取ったバイナリを検証します。

ステップ 2: OpenID Connect（OIDC）を使って外部サービス（Sigstore）に対してワークフローの身元を証明する

OpenID Connect（OIDC）は、ウェブの ID プロバイダ（Google など）で広く使われている標準で、サードパーティに対してユーザーの身元を証明します。現在の GitHub のワークフローは、OIDC をサポートしています。ワークフローが実行されるたびに、ランナーは GitHub の OIDC プロバイダからの一意な JWT トークンを生成できます。このトークンには、ワークフローの身元に関する検証可能な情報が含まれています。たとえば、呼び出し元リポジトリ、コミットのハッシュ、トリガー、現在の（再利用可能な）ワークフローのパスと参照などです。

ワークフローは、OIDC を使って Sigstore の Fulcio ルート認証局に対して自身の身元を証明します。Sigstore は、外部の検証サービスとして振る舞います。Fulcio は、ランナーで生成された一時的な署名鍵を証明する短命の証明書に署名し、それをワークロードの身元と結びつけます。来歴への署名記録は、Sigstore の透明なログ管理サービスである Rekor で保持されます。この署名証明書を信頼性アンカーとして使うと、ユーザーが来歴の正当性や来歴が偽造できないことを検証できます。来歴は、信頼されたビルダーの中で作成されている必要があります。

検証

ユーザーは、以下の手順でアーティファクトと署名された来歴を検証できます。

1. 対応する Rekor ログエントリを検索し、署名を検証する
2. 署名証明書から信頼されたビルダーを抽出し、その身元を確認する
3. 来歴情報が想定されるソースとビルドと一致することを確認する

詳しくは、公式リポジトリの実例をご覧ください。

ユーザーは、以上の手順を経ることで、信頼されたビルダーによって来歴で示されたコミットのハッシュから生成されたバイナリであるという保証を得ることができます。来歴に含まれる情報が偽造できないことは確かなので、ビルドの「レシピ」を信頼することができ、ソースまでさかのぼってアーティファクトの正当性を追跡することもできます。

補足 : 鍵なし署名

この手法には、追加のメリットがあります。それは、メンテナが署名に使う暗号鍵の管理や配布をする必要がないため、鍵の管理という悪名高い難題を回避できることです。OIDC プロトコルでは、ハードコードされた長期間有効なシークレットを GitHub に格納する必要はないため、不適切な鍵管理によって SLSA の来歴が無効になるという問題が起きる可能性はありません。バイナリ アーティファクトがしかるべき来歴を生成した信頼されたビルダーでビルドされたことは、OIDC を利用するだけで検証できます。

次のステップ

SLSA フレームワークを活用すれば、大規模環境でソフトウェアのサプライ チェーンの完全性を確実に保証できることが実証されています。このプロトタイプから、人気の CI/CD システムの最新機能やオープンソースのツールを使えば、考えられている以上に簡単に高い SLSA レベルを実現できることがわかります。改ざん防止（SLSA 3 以上）に対応したビルドサービスの採用が増えれば、オープンソース エコシステムはより充実し、現在のサプライ チェーンにおける簡単に悪用できる脆弱性を 1 つクローズすることにつながります。

ぜひこの機能を試し、採用することをおすすめします。また、プロジェクトへの改善要望も歓迎します。フィードバック、コメント、提案は、slsa-github-generator-go と slsa-verifier のプロジェクト リポジトリからお送りください。これから数週間のうちに、v1 を正式リリースする予定です。

今後の投稿では、安全なリポジトリ設定を証明する偽造できないソース来歴を追加する方法や、他のビルド ツールチェーンやパッケージ マネージャなどで同じ手法を使う方法について紹介したいと思います。お楽しみに！

Reviewed by Eiji Kitamura - Developer Relations Team