たくさん Googleの開発者が発表 「SLSA」 （ソフトウェアアーティファクトのサプライチェーンレベル） 開発インフラの保護 製品のコーディング、テスト、構築、配布の各段階で実行される攻撃の数。
開発者 開発プロセスはますます複雑になり、サードパーティのツールに依存していることに言及します、これは、最終製品の脆弱性の特定と悪用ではなく、開発プロセス自体のコミットメントに関連する攻撃を促進するための好ましい条件を作成します。
SLSAについて
SLSAは、次のXNUMXつの基本原則に焦点を当てていると述べられています。
片側ではない-少なくとも1人の他の「信頼できる人」からの明示的なレビューと承認なしに、ソフトウェアサプライチェーンのどこでもソフトウェア成果物を変更することはできません。 [^ XNUMX]目的は、リスク/悪い変化の防止、抑止、または早期発見です。
監査可能-ソフトウェア成果物は、人間が読み取れる元のソースと依存関係まで安全かつ透過的に追跡できます。 主な目的は、自動化されたソースと依存関係の分析、およびアドホック調査です。
フラグが立てられた脅威をブロックするには、 SLSAは、監査用のメタデータの作成を自動化するための一連のガイドラインとツールを提供します。 SLSAは、一般的な攻撃方法を要約し、保護レイヤーの概念を紹介します。
各レイヤーには、開発で使用されるアーティファクトの整合性を確保するための特定のインフラストラクチャ要件があります。 サポートされているSLSAレベルが高いほど、より多くの防御が実装されます インフラストラクチャは、通常の攻撃からより適切に保護されます。
SLSAレベル1
このレベルで ビルドプロセスを完全に自動化し、メタデータを生成する必要があります （「来歴」）ソース、依存関係、ビルドプロセス情報など、アーティファクトの収集方法に関する情報（GitHubアクション用に監査用のサンプルメタデータジェネレーターが提供されています）。 SLSA 1には、悪意のある変更に対する保護の要素は含まれていません最も簡単な方法でコードを識別し、脆弱性管理とリスク分析のためのメタデータを提供するだけです。
SLSAレベル2
ここで、最初のレイヤーは、ソース管理システムの使用を要求し、認証されたメタデータを生成するサービスを構築することによって拡張されます。 の用法 SLSA 2を使用すると、コードの出所を追跡し、不正な変更を防ぐことができます 信頼できるアセンブリサービスを使用する場合は、コード内で。
SLSAレベル3
この時点からまたは、ソースコードとビルドプラットフォームが標準の要件を満たしていることが確認されている コードを監査できること、および提供されたメタデータの整合性が保証されていることを確認するため。 監査人は、規格の要件に準拠しているプラットフォームを認証できるはずです。
SLSAレベル4
これは最高レベルであり、XNUMX人の異なる開発者によるすべての変更、およびすべてのコンパイルステップ、コード、依存関係の必須レビューである、はるかに厳しい要件を追加することで、以前のレベルを補完します。完全に宣言されている場合、すべての依存関係を個別にチェックアウトおよびチェックアウトする必要があり、ビルドプロセスはオフラインで実行する必要があります。
繰り返し可能なコンパイルプロセスを使用すると、コンパイルプロセスを繰り返し、実行可能ファイルが提供されたソースからコンパイルされるようにする機能も提供されます。
それに加えて このフレームワークは8種類の攻撃を考慮に入れています 製品コードの開発、コンパイル、テスト、および配布段階における悪意のある変更の脅威に関連しています。
考慮される攻撃の種類 これらは次のとおりです。
1.-脆弱性につながるバックドアまたは潜在的なエラーを含む変更のソースコードに含まれています。
2.-ソース管理プラットフォームのコミットメント。
3.-コード転送段階でコンパイルまたは継続的インテグレーションシステムに変更を加えます（リポジトリコードに対応しないコードが収集されます）。
4.-建設プラットフォームのコミットメント
5.-低品質の依存関係による悪意のあるコードの宣伝。
6.- CI / CDシステムで生成されないアーティファクトのロード。
7.-パッケージリポジトリの侵害。
8.-間違ったパッケージをインストールするユーザーの混乱。
最後に あなたがそれについてもっと知りたいなら、詳細を確認できます 次のリンクで。