KubeCon NA 2021、ソフトウェア開発工程のタンパリングを防ぐSLSAを解説

KubeCon/CloudNativeCon NA 2021から、2021年10月12日にプレカンファレンスとして行われたSupplyChainSecurityConのセッションを紹介する。これは「An Overview on SLSA」と題されたセッションで、プレゼンターはGoogleのTom Hennen氏とVMwareのJoshua Lock氏だ。

SLSAの概要を紹介するセッション

動画のURL：An Overview on SLSA

SLSAは「Supply-chain Levels for Software Artifacts」の略で、ソフトウェア開発から本番環境でのデプロイメントまでのステップ全体を攻撃者から守るためのフレームワーク、もしくは準拠するべきガイドラインと言えるだろう。プロジェクトとしてはThe Linux Foundationによってホストされている。

従来、セキュリティを高めるためにインフラストラクチャーを守るファイアウォールやプロセス間通信を暗号化するmTLS、ポリシーを用いたアクセスを制御など、さまざまな手法で攻撃からIT資産を守るための努力が行われてきた。しかしSLSAはソフトウェア開発から実装までのプロセスに注目して、どの段階でも「確実に真正であること＝第3者によって破壊されていないこと」を実証することで、すべてのプロセスが意図された通りに開発、ビルド、パッケージ、デプロイされたことを確認するためのフレームワークだ。

SLSAの前身は、Binary Authorization for Borg（BAB）と呼ばれる成果物に対する強制適用チェックシステムである。BorgはGoogle社内のコンテナオーケストレーションツールであり、Kubernetesの前身と言えるものだ。BABはGoogle社内のデベロッパーによるインサイダーリスクを解消するためのものである。詳しくは以下のGoogleのブログを参照されたい。

GoogleがSLSAを紹介するブログ：Introducing SLSA, an End-to-End Framework for Supply Chain Integrity

BABについて：Binary Authorization for Borg: コードの出所を確認してコード ID を実装する方法

ソフトウェアサプライチェーンにおける攻撃されるポイントを例示

このスライドでは、コードを開発するデベロッパーによるビルドのプロセスを経てパッケージ化された成果物が、最終的に利用されるまでに8つのポイントで攻撃が行われる可能性があるとして、すべてのプロセスにおいて成果物を攻撃から守る必要があることを解説している。

SLSAは4つのレベルでソフトウェアサプライチェーンに対する攻撃（ここではタンパリングと称されている）から守ることを目的としている。ビルドプロセスにおけるドキュメント化が必須となるレベル1から、ソースコードのレビューを2者によって受ける必要があるレベル4まで、守るべき項目はさまざまだ。

Googleのセキュリティブログから引用。SLSAの4つレベルの概要

同じ内容がSLSA.devという公式サイトにも掲載されている。

SLSA公式サイト：Security levels

4つのSLSAの概略説明

ここから「Provenance（来歴）」と「Attestation（証明）」という目新しい言葉が出てくるが、それぞれ成果物がどのように生成されたのかを確認することがProvenance、シグネチャーなどで認証した結果がAttestationと覚えておけば良いだろう。

in-totoで利用されるサプライチェーンの記述を例に説明

このスライドではCNCFのサンドボックスプロジェクトであるin-totoを例に、makefileに対してサプライチェーンとして必要な情報を追加する設定ファイル、SLSAでは「レイアウト」と呼ばれるコメント付きのJSON記述による設定を解説している。

SLSAがソフトウェア開発から実装までの全体のプロセスを対象にしていることは、次のスライドでも理解できる。ここではソースコードを生成する段階とそれをビルドしてパッケージ化する段階に分けて、それぞれに信頼の境界が発生することを解説した。

各プロセスに信頼の境界が存在することを解説

その上で攻撃もしくは脅威と言っても良いかもしれないが、タンパリングを起こすモノを「グレムリン」と称して、どのような状況において脅威が発生するのか、それをSLSAがどうやって防ぐのかを解説するフェーズに移った。

この例ではビルドの段階で阻害要因（グレムリン）が発生

このスライドではコンテナレジストリーから悪意のあるコードが追加される脅威に対して、SLSAのポリシーエンフォーサーが食い止めるという例を紹介している。

ソースコード管理システムに対して悪意のあるコードを止めるSLSA

ここで紹介されたスライドでは「具体的に何をしなければいけないのか？」についての解説はされていないが、プロセス全体を見通して何が行われているのかを可視化し、すべての段階でデジタルシグネチャーによる証書を要求するという作業が発生することだけは確かだ。

SBOM（Software Bill of Materials）にはSPDXとCycloneDXが存在している。一方SLSAではその実装であるin-totoが存在感を増しているが、健全なオープンソースコミュニティとなるためには、競争相手となるプロジェクトが必要かもしれない。周辺のツールの充実やCI/CDへの組み込み、監査の手法など、これからエコシステムの拡大とともにユースケースが拡がることを期待したい。

in-totoの公式ページ：A framework to secure the integrity of software supply chains

CNCFのサンドボックスプロジェクトページ：https://www.cncf.io/projects/in-toto/

SLSAの開発に参加を呼びかけるスライド。踊っているのはサルサ？

SLSAへの参加を呼びかけるページ：https://slsa.dev/getinvolved