OpenSSFがソフトウェアのサプライチェーンセキュリティのための仕様「SLSA(サルサ)」のVersion 1.0を公開

こんにちは、吉田です。今回は、Open Source Security Foundation(OpenSSF)が4月19日に公開した「Supply-chain Levels for Software Artifacts」(SLSA、「サルサ」と発音)のVersion 1.0について紹介したいと思います。

【参照】OpenSSF Announces SLSA Version 1.0 Release
https://www.linuxfoundation.org/press/openssf-announces-slsa-version-1.0-release

SLSAとは

SLSAはコミュニティの専門家の合意により確立された、ソフトウェアのサプライチェーンセキュリティのための仕様を提供するOpenSSFのプロジェクトです。SLSAのフレームワークはセキュリティの厳格さを示す一連のレベルに整理されており、ソフトウェアが改ざんされておらず、ソースコードまで安全に追跡できることが証明できるように設計されています。SLSAはサプライチェーンのセキュリティ言語で、ソフトウェアの現状とセキュリティ体制を成熟させる方法の特定に役立ちます。

SLSAは、これらのことを実現するために、以下のものを提供します。

• ソフトウェアサプライチェーンのセキュリティに関する共通語彙(ごい)
• 消費する成果物(ソースコード、ビルド、コンテナイメージなど)の信頼性を評価することで、上流の依存関係を評価する方法
• 自社ソフトウェアのセキュリティを向上させるための実践的なチェックリスト
• NISTセキュアソフトウェア開発フレームワーク(SSDF)において、大統領令で今後定められる基準への準拠に向けた取り組みを測定する方法

SLSAが必要な理由

SolarWinds社やCodecov社に対するような著名な攻撃は、サプライチェーンの完全性の弱点を露呈しました。また、コードそのものだけでなく、コードがソフトウェアシステムに組み込まれるまでの複雑なプロセス、つまりソフトウェアのサプライチェーンにおける複数のポイントに固有のリスクが存在することも明らかになりました。このような攻撃は増加の一途をたどり、一向に減る気配がないため、ソフトウェアのサプライチェーンを強化するための普遍的な枠組みが必要となっています。

脆弱性の検出やソースコードの解析のためのセキュリティ技術は不可欠ですが、それだけでは十分ではありません。ファジングや脆弱性スキャンが完了した後でも、意図せず、あるいは内部脅威や侵害されたアカウントからコードに変更が加えられることがあります。コード改変のリスクはソースから構築、パッケージング、配布に至るまで、一般的なソフトウェアサプライチェーンの各リンクに存在します。サプライチェーンに弱点があれば、実行したコードが実際にスキャンしたコードであるかの信頼性が損なわれます。

SLSAは、ソースからバイナリまでのコードの取り扱いを追跡する自動化をサポートし、ソフトウェアのサプライチェーンの複雑さに関係なく、改ざんから保護するように設計されています。その結果、SLSAはソースコードに行われた分析とレビューが、ビルドと配布プロセスの後に消費されるバイナリにも適用されると仮定できる信頼性を向上させます。

SLSAの仕組み

SLSA v1.0リリースでは、SLSAのレベル要件をそれぞれがビルド、ソース、依存関係などのソフトウェアサプライチェーンの1つの領域に焦点を当てる複数のトラックに分割するという概念的な大幅な変更が行われました。以前は単一のトラックでしたが、この新しい分割によりユーザーにとってSLSAの導入が容易になります。SLSA v1.0は現状ではBuildトラックのみから構成されていますが、将来のバージョンではソースコードの管理方法など、ソフトウェアサプライ チェーンの他の部分をカバーするトラックが追加される予定になっています。

各トラック内でレベルが上がるにつれて、セキュリティ対策が強化されます。レベルが高いほどサプライチェーンの脅威に対してより高いセキュリティを保証できますが、その分導入コストも高くなります。現在、SLSA Buildトラックはレベル1から3までを含みますが、将来の改訂でより高いレベルを可能にすることを想定しています。

このトラックとレベルを組み合わせることで、ソフトウェアが特定の要件を満たしているかどうかを簡単に説明できるようになります。例えば、ある成果物がSLSA Build 3を満たしていると言うことは、そのソフトウェア成果物が、業界のリーダーたちが特定のサプライチェーンの侵害から保護すると合意した一連のセキュリティ慣行に従って構築されたことを、ワンフレーズで示すことになります。

これらは、オープンソースプロジェクトの管理者でも企業でも、エンドユーザーがソフトウェアサプライチェーンに関連するリスクをより深く理解し、軽減し、最終的にはより安全で信頼性の高いソフトウェアを開発するのに役立つと考えて良いと思います。

SLSAはどのようなメリットをもたらすか

SLSAのメリットは、さまざまな観点で説明できます。

• ソフトウェア生産者(ソフトウェアベンダーや同じ会社内で使用するファーストパーティコードを作成するチームなど)
  SLSAを使用すると消費者に至るまでのサプライチェーンに沿った改ざんを保護してインサイダーリスクが軽減され、作成したソフトウェアが意図したとおりに消費者に届けられるという信頼性が高まります。オープンソースプロジェクトとエコシステムの場合、SLSAはリリースに改ざんされていないソース コードと依存関係が含まれていることを実証するためのフレームワークを提供します。オープンソースプロジェクトの多くはボランティアにより運営されているため、既存のプロジェクトにSLSAを簡単に追加するツールが利用可能です。
• ソフトウェア消費者(オープンソースパッケージを使用する開発チーム、ベンダーソフトウェアを使用する政府機関、組織リスクを判断するCISOなど)
  SLSAは依存しているソフトウェアのセキュリティ慣行を判断し、受信したものが期待どおりであることを確認する方法を提供します。
• インフラストラクチャプロバイダー(エコシステムパッケージマネージャー、ビルドプラットフォーム、CI/CDシステムなどのインフラストラクチャ提供者)
  生産者と消費者の間の架け橋としてSLSAを採用することで、生産者と消費者間の安全なソフトウェアサプライチェーンが可能になります。

ここ数年、サプライチェーンのセキュリティ確保は米国の大統領令やEUのサイバーレジリエンス法など、公的な機関も大いに注目している領域になってきています。このSLSAフレームワークを提案し、導入する企業が増えることで脅威を軽減できるようになるので、このプロジェクトの今後を注視していく必要があると思います。