SLSA サイバーセキュリティ フレームワークを理解する

SLSA がソフトウェア サプライ チェーン攻撃からの防御にどのように役立つか

SLSA セキュリティ フレームワークは、単なるルールではなく、ソフトウェア アーティファクトのコンポーネントの整合性を潜在的に強化できる標準フレームワークです。このエンドツーエンドのガイドラインは、ソフトウェア製品を構成するソフトウェア パッケージの改ざんやあらゆる種類の不正な変更を段階的に防止する一連の防御手段として機能します。 SLSA フレームワークを採用すると、一般的な攻撃からソフトウェアを保護できます。 サプライチェーン攻撃 以下のようなものです：

PHP の悪意のあるコミットリポジトリ攻撃

2021 年 80 月、ニキータ ポポフ氏は、悪意のある攻撃者がコード プラットフォームへの不正アクセスを可能にするバックドアを作成して PHP のソース コードを攻撃しようとしたと発表しました。 PHP はインターネット上の Web サイトの約 XNUMX% に使用されているため、成功した場合、この攻撃は壊滅的なものになっていたでしょう。幸いなことに、攻撃は時間通りに捕らえられましたが、このインシデントは、SLSA 制御が今後のこのような攻撃の防止にどのように役立つかを示しています。 XNUMX 人によるレビューや XNUMX 要素認証などの SLSA プロトコルに従えば、ソース コード プラットフォームは保護され、攻撃者にとってはるかに困難な標的になっていたでしょう。

Apple の悪意のあるコンパイラ侵害

2015 年、Apple 製品用のアプリを構築するソフトウェア開発者が、未検証のホスティング プラットフォームから Xcode (Apple デバイス用のコード作成ツール) のバージョンをダウンロードしました。 XcodeGhost として知られる Xcode のバージョンは、それを使用して構築されたアプリに密かに引き継がれる悪意のあるコードに感染していました。 Apple のコードレビュープロセスを回避するいくつかのアプリやアプリストアで提供されるアプリへのバックドアを作成しました。 SLSA フレームワークには、このような攻撃を防止したり、攻撃をより困難にしたりできるビルド関連のセキュリティ プロトコルが含まれています。そのような対策の XNUMX つは、開発者が使用したビルド ツールを含むすべてのソースを宣言することを強制する密閉ビルド要件です。

アップロードされた悪意のあるアーティファクト

1 年 2021 月 XNUMX 日、Codecov チームは、Codecov GitHub Action、Codecov CircleCI Orb、Codecov Bitrise Step など、Bash Uploader に影響を与える攻撃を発見しました。攻撃者は、Codecov の公開セルフホスト Docker イメージの XNUMX つの中間層の Google Cloud Storage サービス アカウントへのアクセスを提供する HMAC キーを抽出することにより、不正アクセスを取得しました。このキーを使用すると、Bash Uploader を変更して、悪意のあるコードをエンド ユーザーに直接アップロードすることができました。 SLSA フレームワークは、アーティファクトがソース リポジトリ内で予期された形式とは異なる方法でビルドされたときを示すことで、このアクションを捕捉したと考えられます。

イベントストリームの不正な依存関係

2018 年、ハッカーは悪意のあるパッケージ flatmap-stream を npm に公開し、これは後にプラットフォームで広く使用されているイベント ストリーム パッケージへの依存関係として追加されました。依存関係を追加した後、攻撃者はそれを悪意のある動作で更新しました。アップデートは GitHub に送信されたコードと一致しなかったため、SLSA フレームワークが攻撃を捕捉し、ベクトルを阻止した可能性があります。悪意のあるコードの出所を追跡すると、それが GitHub や適切なビルダーから来たものではないことが判明するでしょう。いずれにせよ、攻撃は防げたはずだ。

SLSA サイバーセキュリティ フレームワークの 4 つのセキュリティ レベル

SLSA フレームワークは、増分的で実用的なプロトコルです。これは 4 つのレベルで構成され、レベル XNUMX は安全なシステムの理想的な最終状態を表します。最高レベルのアーティファクトは、いかなる方法でも改ざんされておらず、すべてのコンポーネントをソースまで追跡できるという消費者の信頼を得るために必要なすべての要件を満たしています。下位レベルのアーティファクトは、ランクに応じて特定の整合性が保証される増分マイルストーンも達成したアーティファクトです。

レベル 1 — 基礎を築く

SLSA フレームワークのレベル 1 は、安全なソフトウェアを作成するためのフレームワーク全体の一種の基盤と考えることができます。この段階で、SLSA を採用する開発者または組織は XNUMX つのことを行う必要があります。まず、構築プロセスを完全に自動化する必要があります。これはさまざまな方法で実行できますが、ビルドを自動化する従来の方法はメイクファイルを使用することです。 GitHub Actions を使用して同じ結果を達成することもできます。

SLSA レベル 1 を達成するための XNUMX 番目の部分は、完全な出所文書を生成することです。これは、ソフトウェア成果物がどのように構築されたかを示すメタデータです。ビルド プロセス全体、すべての依存関係、ビルドに使用されるトップレベルのソースについて詳しく説明する必要があります。

この方法でビルド プロセスをスクリプト化し、ソフトウェア アーティファクトの出所を示すことで、消費者はソフトウェア製品の使用について十分な情報に基づいた意思決定を行うことが容易になります。 SLSA 1 検証があるからといって、ソフトウェアが改ざんから完全に保護されるわけではありませんが、ソフトウェアのコンポーネントの識別が容易になります。これは脆弱性管理の最初の段階です。

レベル 2 - ビルド プロセスが改ざん防止されていることを確認する

SLSA フレームワークのレベル 2 では、ビルド プロセスの耐改ざん性を可能な限り高めるための対策を講じ始めます。 SLSA フレームワークのレベル 2 を達成すると、消費者はソフトウェアの起源についてさらに自信を持つことができます。

繰り返しますが、これは 2 つのステップで行われます。1 つ目はバージョン管理を使用し、2 つ目はホストされたビルド サービスを使用して出所を認証します。最初のステップでは、GitHub、GitLab、またはその他の同様のサービスを使用してコードを保存し、それに加えられた変更を記録します。この方法でバージョンの変更を追跡すると、アーティファクトの構築過程でアーティファクトに対して行われた変更を理解しやすくなります。

レベル 2 ではレベル 1 と同様に出所文書が必要ですが、ここでの違いは、ソフトウェア アーティファクトがホストされたビルド サービスによって認証される必要があることです。ホストされたサービスは、最初の出所文書に詳述されているビルド プロセスが正確であることを確認できる信頼できるサード パーティとして機能します。 GitHub Actions は、認証された出所を提供できるホスティング サービスの一種です。

 レベル 3 - SLSA のセキュリティ制御

レベル 3 では、SLSA フレームワークで強調されている特定のセキュリティ制御の実装を開始します。このレベルを達成するには、ソフトウェア成果物のソースおよびビルド プラットフォームが、ソースが監査可能であり、コードの出所が信頼できることを保証する特定の基準を満たしている必要があります。 SLSA レベル 3 は、アーティファクトが改ざんや特定のクラスの脅威から十分に保護されていることをより強力に保証します。

レベル 3 の具体的な要件には次のようなものがあります。

•     ソースコードの検証履歴と保持- ソース コードの検証履歴により、ソフトウェア ソース コードに加えられた変更には、その変更を行った作成者、レビュー担当者、またはアップロード者の認証された ID が、変更の特定のタイムスタンプとともに伴っていることが保証されます。この変更履歴も少なくとも 18 か月間保存する必要があります。
•   一時的な環境での分離されたビルド—この要件を満たすには、ソフトウェア ビルドを他のビルド インスタンスから完全に独立した一時的な環境に実装する必要があります。これを実現するには、仮想ビルド マシンを使用してオンデマンドでビルドを生成する GitHub Actions のようなサービスを使用できます。
•     コードとしてビルド—これらの基準では、ビルド ファイルをコードのように扱うことが求められます。これは、必要に応じてビルド プロセスを再作成できるバージョン管理システムにそれらを保存することを意味します。
•     反証不可能な出所- この要件の目的は、ビルド サービスによって生成された来歴ドキュメントをユーザーが改ざんするのを防ぐことです。

レベル 4 - 消費者の信頼

SLSA フレームワークのレベル 4 は、ソフトウェアがいかなる方法でも改ざんされていないことを保証することを目的としています。次の要件を満たすソフトウェア アーティファクトのみが、フレームワークのレベル 4 を達成できます。

すべての変更を 2 人でレビューします

この基準では、組織はソフトウェア コードとコンポーネントに提案された変更を徹底的にレビューするために 2 人の資格のあるレビュー担当者を任命する必要があります。この 2 人によるレビュー プロセスにより、信頼され認証された開発者だけがソフトウェア アーティファクトに変更を加えられることが保証されます。

気密性と再現性のあるビルド プロセス

すべての入力がビルド プロセスの外側で前もって指定されている場合、ビルド プロセスは密閉されていると言われます。このルールは、ソース コードだけでなく、ビルドで使用されるすべてのコンパイラー、ライブラリ、ツールにも適用されます。これは、すべてのサードパーティのインポートの整合性を保証するのに役立ちます。再現可能なビルド基準は必須要件ではありませんが、推奨されます。この基準では、ビルド プロセスがいつどこで実行されたかに関係なく、同じ出力を生成する必要があります。

SLSA レベルを満たすための技術要件

SLSA フレームワークには、さまざまなレベルに特有の技術要件があります。これらの要件は、ソース要件、ビルド プロセス要件、共通要件、来歴コンテンツ要件、来歴生成要件の 5 つの主要カテゴリに分類されます。これらの要件カテゴリのそれぞれを以下で強調表示します。

ソース要件

これは、ソース コードの整合性を確保することを目的とした要件を指します。これらの一連のプロトコルに従うことで、コードの改ざんや悪意のある変更を防止できます。また、あらゆる不正行為が見逃されることもありません。ソース要件を以下の表に示します。

ビルド要件

SLSA フレームワークは、ビルド プラットフォームの安全性を向上させ、ビルド プロセスの整合性を維持することを目的としたビルド要件を強調しています。

来歴生成の要件

これらの要件は、ソフトウェア資産のすべてのコンポーネントのソースを検証することを目的としています。来歴生成の要件は、以下の表で強調表示されています。

来歴コンテンツの要件

来歴コンテンツ要件では、ビルド プロセスで使用されたすべてのアーティファクト、依存関係、およびビルド制限のアイデンティティとソースを検証します。それらは以下の表で強調表示されています。

共通の要件

共通の要件は、SLSA のレベル 4 のソフトウェア アーティファクトに適用されます。すべての信頼できるアーティファクトは、これらの要件を満たすことが期待されます。これらには、ベースラインのセキュリティ要件と、すべての物理アクセスとリモート アクセスの詳細を示すログが含まれます。共通要件では、SLSA ドキュメントの規定を上書きできる少数のプラットフォーム管理者も規定しています。