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

ソフトウェア サプライ チェーン攻撃は近年、より蔓延し、巧妙化しています。によると ガートナーレポート、ソフトウェア サプライ チェーン攻撃の数は 2025 年までに XNUMX 倍に増加し、世界中の組織のほぼ半数に影響を与えると予測されています。この脅威の増大により、すべてのコンポーネント、アクティビティ、および SDLC 実践のセキュリティを確保することがこれまで以上に重要になっています。

防ぐことが難しい一方で、 ソフトウェアサプライチェーン攻撃影響を軽減したりリスクを軽減したりするためにできることは次のとおりです。インフラストラクチャを監査し、すべてのソフトウェア資産の最新のインベントリを保持し、ベンダーを評価してゼロトラスト アプローチを適用し、セキュリティ ツールを使用し、セキュリティを確保します。エンドポイントなど

安全はおろか、生命の保証もありませんが、 ソフトウェア サプライ チェーンのセキュリティのベスト プラクティス 開発者と製品組織は、ソフトウェア サプライ チェーンを保護するためにこれに従う必要があります。ソフトウェア ライフサイクルのさまざまな段階で、これらのガイドラインを使用して、組織内のセキュリティ慣行を説明、評価、測定できます。ベスト プラクティスは、取得、開発、導入など、ソフトウェア サプライ チェーンの各段階で発揮されます。

の数の増加 ソフトウェアサプライチェーンのリスク そして、それらに起因する一連の注目を集める侵害は、脆弱性の問題がいかに深刻であるかを示しています。ソフトウェア サプライ チェーンに対して、サードパーティ ソフトウェアによって引き起こされる可能性のあるいくつかの脅威があります。攻撃者は、サードパーティ ソフトウェアに依存するシステムの脆弱性をさまざまな方法で悪用する可能性があります。これらの攻撃方法の中には、ソフトウェアに悪意のあるコードを導入し、依存関係の混乱を引き起こしたり、タイポスクワッティングを引き起こしたりすることが含まれます。

サプライ チェーン攻撃は通常、正当なプロセスの背後に隠れて、組織のソフトウェア エコシステムへの無制限のアクセスを取得します。ほとんどの場合、攻撃者はベンダーまたはソフトウェア サプライヤーのセキュリティ防御を突破することから始めます。サプライ チェーン マルウェアが挿入されると、デジタル署名された正当なプロセスに自身を接続する必要があります。ソフトウェア アップデートは、攻撃者がソフトウェア サプライ チェーン全体にマルウェアを拡散するためによく使用されます。いくつかの共通点 ソフトウェアサプライチェーン攻撃の種類 侵害されたソフトウェア構築ツール、盗まれたコード署名証明書または盗まれた ID を使用して署名された悪意のあるアプリ、およびハードウェアまたはファームウェア コンポーネントの侵害されたコードが含まれます。

SBOM (ソフトウェア部品表）は、ソフトウェア製品またはアプリケーションを構成する多くのコンポーネントに関する一連の情報です。通常、これにはライセンス情報、バージョン番号、コンポーネントの詳細、ベンダーなどが含まれます。このような詳細かつ正式なリストにより、他の人がソフトウェアの内容を理解し、それに応じて行動できるようになるため、メーカーとユーザーの両方のリスクが軽減されます。

SBOM を使用すると、製品コンポーネントの可視化、脆弱性スキャンの容易化、ライセンス ガバナンスの活用が可能になり、Integrity に対する脅威の分析に使用できます。

継続的保証は、ソフトウェア サプライ チェーンの盲点を払拭することを目的としています。これには、製品のビルドや展開など、最終的なソフトウェア製品のセキュリティに影響を与える可能性のある開発ライフサイクルのあらゆるイベントについて、署名された証拠を収集することが含まれます。現在、企業はソフトウェア製品の安全性を高めるためにさまざまなセキュリティ ツールを使用しています。ただし、これらのツールを一貫して使用するためのポリシーを確立することはほとんどありません。

継続的な保証 ソフトウェア製品が開発中に改ざんされていないこと、およびセキュリティ関連のテストが実行されていることを保証します。

コードのマイナーな変更は、長期間検出されない可能性があります。開発チームは、変更された製品が適切に署名されていれば、コードの所有者を信頼します。その結果、マルウェアが含まれたパッケージが作成され、信頼できる人気のあるメンテナが知らないうちにそれらのメンテナに割り当てられる可能性があります。信頼を誤った場合は、問題のある脆弱性や完全な問題を意味する可能性があります。 コードに悪意のあるコードが隠されています。

開発者が既存のライブラリまたは StackOverflow からコードをコピーして貼り付けて、独自のコードで使用したり、新しいライブラリにアップロードしたりすることも一般的です。これにより、本質的に追跡不可能になった、安全でない脆弱なコードもコピーされる可能性が高まります。 

の最終バージョン NIST SSDF 1.1 (セキュア ソフトウェア開発フレームワーク) は 22 月 2021 日に発行されました。 XNUMX 年 XNUMX 月に、フレームワークの草案版が公開されました。違いの多くは、高レベルの実践やタスクではなく、提供されるさまざまな例に集中しています。

どのプラクティスを実装するかを決定する際、NIST はリスクとコスト、実現可能性、および適用可能性のバランスをとることを推奨しています。ソフトウェアのセキュリティを確保するには、できるだけ多くのチェックとプロセスを自動化することが考慮すべき重要な機能です。

ソフトウェアの信頼を構築することは、特に SSDF や SLSA などの新しい標準やベスト プラクティスを考慮すると重要なタスクです。間もなく、この信頼を証明できないベンダーは米国連邦政府に販売できなくなるでしょう。

信頼を築くには、製品の SBOM とその安全な開発と構築に関する証拠を保持し、関係者と共有する必要があります。

スクライブプラットフォーム真のエンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションである は、この機能を提供します。ゼロトラスト アプローチで SDLC 全体に継続的なコード保証を適用し、共有可能な SBOMS を自動的に生成するため、脆弱性やコードの改ざんに関する洞察を得ることができます。

動的パイプラインは、セキュリティのために継続的に監視する必要があります。で SLSA サイバーセキュリティ フレームワーク (ソフトウェア アーティファクトのサプライ チェーン レベル) では、ソフトウェア サプライ チェーンの 4 つの保護レベルと、各レベルに到達する方法に関するガイドラインが定義されています。

いくつか例を挙げると、Sigstore や OPA などのオープンソース ツールを使用して、自動化を実装するためのベスト プラクティスに従う必要があります。