SLSAとCIS Software Supply Chain Securityのどちらを使用すべきか #aqua #セキュリティ #ソフトウェアサプライチェーン

本ブログは「Aqua Security」社の技術ブログで2023年1月12日に公開された「 Should You Use SLSA or CIS Software Supply Chain Security Guidelines? 」の日本語翻訳です。

SLSAとCIS Software Supply Chain Securityのどちらを使用すべきか

---

昨今のソフトウェアサプライチェーンに対する攻撃の増加によって、CISO への個人的責任の追及、米国政府が調達するあらゆる製品・サービスに対して最低限のセキュリティソフトウェア基準を要求するなどのできごとを受け、開発業界はセキュリティを最優先としたソフトウェア開発戦略に再び焦点を当て始めています。しかし、多くの信頼できるソースがガイダンスを作成している中で、どれがベストなのでしょうか。このブログでは、SLSA(Supply chain Levels for Software Artifacts) と CIS の両方のガイドラインの重要な構成要素を比較検討し、最適なセキュリティ開発戦略の立案に役立てます。

ソフトウェアサプライチェーンセキュリティとは

ソフトウェアの開発は、ソフトウェア開発ライフサイクルの一連のステージの始まりとして構築されるコードの部分から始まります。このプロセスの各段階は、脆弱性の侵入や攻撃の潜在的な入口となり得る、ソフトウェアアーティファクトや複雑な相互関係で構成されています。ソフトウェア開発ライフサイクルのいずれかの段階で侵害が成功し、ソフトウェアがエンドユーザにリリースされると、それらのクライアントも影響を受けることになります。このような攻撃は、サプライチェーン攻撃と呼ばれ、計画的に行われます。侵入機会の幅が広く、成功した場合のインパクトが大きいため、増加傾向にあります。一方、DevOps チームでは、セキュリティが全体的に徹底されていないことが多いため、こうした攻撃を防ぐための厳しい戦いに直面しています。さらに、オープンソースが広く採用されていることも、この課題に拍車をかけています。攻撃者は、このような深いレベルの依存関係が、チームにとってセキュリティを維持するのがさらに困難であることを認識し、攻撃を仕掛けるための主要な経路として活用し始めています。最近観察された巧妙な攻撃の例としては、以下のようなものがあります。

• npm などの一般的に使用されるライブラリへのマルウェアの挿入
• Log4J などのオープンソースの脆弱性を悪用した自動化
• 脆弱なアクセス制御を悪用したコード改ざん
• typosquatting などの手法により、開発者を騙して悪意のあるコードをダウンロードさせる

ソフトウェアサプライチェーン攻撃を防止するため、組織は、プロセスや開発パイプライン全体にセキュリティのベストプラクティスを組み込む責任を負っています。開発プロセスのさまざまな段階で、開発者はサードパーティコード、プロプライエタリコード、オープンソースコードからパッケージをインポートし、CI/CD ツールと相互作用するパッケージを構築し、それをエンドユーザにリリースしています。このため、開発者は、プロセスやコード内の依存関係を活用する際に、生産者とエンドユーザの両方の立場からセキュリティ戦略を検討する必要があります。このセキュリティの証明は、検証済みのソフトウェア部品表(SBOM)という形で提供されます。その代表的な例が、ソフトウェアのサプライチェーン規制に関する米国大統領令14028や EU のサイバーレジリエンス法案に規定された要件です。

SLSAとCIS Software Supply Chain Security の利点

SLSAと CIS Software Supply Chain Security はともに、現代のソフトウェア開発プロセス全体にセキュリティを組み込み、脆弱性を減らしてプロセスを保護し、本質的に安全なソフトウェアを生み出します。これによって、エンドユーザと開発者間の信頼を向上させることに重点を置いています。両者とも、コードセキュリティの問題として、含まれる機密データ、ツールやクラウドアカウントの設定ミス、脆弱性、インフラのスキャンなど、同じキーポイントを推奨しています。しかしその一方、それぞれのガイダンスは、セキュリティに関する貴重な洞察を提供するために、異なる側面をより深く掘り下げています。

フレームワークとしての SLSA は、CNCF や OpenSSF などのオープンソースコミュニティからの支援により、推奨事項を満たすことができる基本構造となっています。

CIS Software Supply Chain Security は、企業の開発サイクルに焦点を当てた詳細なガイドで、SBOM などの新しい業界標準やその他のセキュアな開発のベストプラクティスを考慮したものです。

主な構成要素を拡大し、各アプローチの主な特徴を比較してみましょう。

SLSA

Supply chain Levels for Software Artifacts は、SLSA とも呼ばれ、ソフトウェアのサプライチェーンの整合性を実現するためのセキュリティフレームワークです。当初は Google 社内で使用されていましたが、業界を超えたコラボレーションへと発展し、後に Open Source Security Foundation(OpenSSF)の一部となりました。そして、業界とオープンソースのエコシステムが、ソフトウェア開発ライフサイクルのセキュリティを担保するのに貢献しています。

このフレームワークを適用するための道筋は、段階的な成熟度のレベルで表現されます。レベルが高いほど、より優れたセキュリティ対策が適用されていることを示しています。管理対象は、ソース、ビルド、出所、およびコモンズに重点を置いています。SLSA レベルは、ソフトウェアライフサイクルのパッケージビルドプロセスにおける改ざんや不正な改変から保護するために設計されています。

SLSAツール

SLSA フレームワークは、ソフトウェアライフサイクルプロセスにおいて堅牢な SLSA レベルを実現するためのツール群を開発しています。これらのツールの詳細については、GitHub でホスト型ランナーとセルフホスト型ランナーの両方をサポートする slsa-github-generator などで確認できます。

Gitlab、Jenkins、Tekton などのコミュニティのイニシアチブとともに、SLSA レベルを実装し、ビルダーで何がどこで構築されたかの証明、すなわち provenance(来歴) を作成します。

あるパイプラインで、コンテナやライブラリなどのアーティファクトがビルドされる――、SLSA の来歴は、こういったビルドプロセスを記録する in-toto に基づいたマニフェストです。

SLSA 来歴は述語型です。この来歴の仕様の詳細は、SLSA の provenance のページでご覧いただけます。このページでは、「ビルダー」がパッケージのビルドプロセスを、すべての依存関係やビルド環境の詳細とともに追跡する方法を説明しています。ビルダーは、すべてのビルドプロセスの詳細が含まれる来歴を作成するよう規定されています。

slsa-github-generator は、コンテナ、go、bazel、java、rust、Haskell などのアーティファクトに対応したビルドプロセスから来歴を作成します。次のフェーズでは、slsa-verifier が来歴の裏付けを行います。

CIS Software Supply Chain

Center for Internet Security(CIS)は、ソフトウェアサプライチェーンセキュリティのための CIS ベンチマークを開発し、ソースコード、ビルドパイプライン、依存関係、アーティファクト、およびデプロイメントの5つの主要分野に分けられた一般的なガイドラインを含んでいます。

以下では、各カテゴリーにおける重要なポイントを紹介します。

1．ソースコード

コードの変更は、少なくとも2人の正式に認証されたユーザによって検証されなければなりません。非アクティブブランチとブランチ保護ルールは、新しい変更に対する署名付きコミットの検証を保証し、「直線状のコミット履歴」の要件が満たされていることを確認します。

ソースコード管理(SCM)は、SECURITY.md ファイルのようなプライベートリポジトリとパブリックリポジトリの制御を検証します。これは、ユーザの作成と削除、管理者ユーザと非活動ユーザを含む、SCM における承認と認証に関するルールが満たされていることを確認するものです。 また、組織内の多要素認証(MFA)、メール通知の検証済みドメインへの制限、ssh 証明書の提供、IP アドレスによる Git アクセスの制限、異常なコード動作の追跡も確認します。

また、サードパーティソースコードを承認し、必要最小限の権限に制限することや、スキャナーを使用してソースコード内の機密データ、コードの設定ミスや脆弱性(SCA)を特定することも求めています。

2．パイプラインの完全性

パイプラインインフラ、設定、およびその環境に対するアクセスなど、ビルド環境が不変であることを保証するための措置を講じる必要があります。ビルドワーカーは、単一使用、隔離、または最小限のネットワーク接続で構成され、脆弱性を自動でスキャンし、ランタイムセキュリティを強制する必要があります。

パイプラインはコードとして定義し、パイプラインの変更を追跡しレビューする必要があります。パイプラインコードは、機密データ、設定ミス、脆弱性をスキャンします。

パイプラインの完全性のために、リリース時にすべてのアーティファクトに署名し、外部の依存関係をロックして署名付き SBOM を作成し、ビルドパイプラインが再現可能なアーティファクトを作成したことを確認する必要があります。

3．依存関係の完全性

依存関係の完全性を維持するために、すべてのサードパーティサプライヤーからのそれぞれの SBOM を検証する必要があります。オープンソースコンポーネントのパッケージマネージャーとリポジトリの信頼性を確保するためには、依存関係を固定し、60日以上は経過していないようにする必要があります。また、脆弱性、ライセンスタイプ、所有者の変更についてパッケージを検証するためのポリシーを適用する必要があります。

4．アーティファクトの完全性

アーティファクトの検証は、ビルドパイプライン自身による署名、暗号化、配布のための最善のセキュリティに従うことを保証します。アーティファクトへのアクセスは制限され、MFA を使用して、パッケージレジストリ(gitlab、github、クラウドベースレジストリ、jFrogなど)の管理とアクセス、Webhook 統合の検証のためのベストプラクティスを保証します。

5．デプロイメントの完全性

デプロイメント設定ファイルは、ソースコードから分離されます。変更は追跡され、インフラの設定ミスを含む機密データをコードとしてスキャンされます。デプロイメント環境は自動化され、再現可能であり、アクセスは制限されています。

CIS Supply Chainツール：Chain-bench

Chain-bench は、CIS ガイドに従って、SCM、ソースコード、依存関係、パイプライン、アーティファクトに関連する監査統制を行うことができます。

また、SLSA フレームワークのサポートも追加されています。


Chain-bench：chain-bench scan -r https://github.com/my-org/my-repository --access-token xxx_my_gh_access_token


SLSAとCIS Supply Chain

下表は、SLSA と CIS Supply Chain Guide の主な機能の概要を示しています。

Aqua Supply Chain Security

---

Aqua は CIS Supply Chain Security の開発に参加し、その経験と専門知識を活かして Aqua Supply Chain モジュールを開発しました。オープンソースの Chain Bench プロジェクトは、CIS および SLSA コントロールの特定の側面の検証を支援します。Aqua Enterprise を使用すると、SCM、CI/CD、アーティファクトリポジトリ管理を統合して、コード、ビルド、デプロイ、リリースなどアーティファクト構築の全段階にわたってベストプラクティスを適用・分析できます。

SBOM マニフェストには、アーティファクトに関連する依存関係(コンテナ、ライブラリ、パッケージなど)のリストが含まれています。しかし、これらの依存関係の脆弱性を見つけるには、もう1つのステップが必要です。Trivy はこのステップを支援し、Aqua はソースコードからランタイムまでのリスク、脆弱性管理、ポリシー、ランタイム保護に優先順位を付け、ワークロードのリスク管理を支援します。SCM および CI/CD との統合により、ビルドプロセスの整合性の追跡と検証、およびサプライチェーンセキュリティ内部の重要なコンポーネントであるパイプラインの統合が可能です。

ビルドツール(CI/CD)における異常なコード動作の検出など、高度なサプライチェーン制御は、アーティファクトビルドプロセスに統合されたランタイムセキュリティツールを使用して実現できます。サプライチェーンのベストプラクティスでは、パイプラインにおけるシフトレフトアプローチを推奨し、コードとしてのインフラの設定ミスをスキャンし、コードの脆弱性を見つけ、機密データやライセンスをスキャンします。これらのコントロールの多くは、Trivy で実現できます。詳しくは、こちらをご覧ください。

Aqua は、サプライチェーンセキュリティの新しい課題、次世代 SBOM の開発、パイプラインセキュリティ、脆弱性管理などに対応できるよう支援します。詳しくは、フルライフサイクルソフトウェアサプライチェーンセキュリティに対する Aqua のアプローチについてをご覧ください。