ソフトウェア サプライ チェーンとは、開発ライフサイクル全体を通じて何らかの形でソフトウェア コードに接続されているあらゆるものを指します。すべてのソフトウェアは複数のコンポーネントで構成されています。スクラッチから書かれた独自のコードに加えて、コードが適切に動作するには、外部のソフトウェア インフラストラクチャ、クラウド サービス、オペレーティング システムも必要です。レジストリ、リポジトリ、コードベース、さらにはこのソフトウェアを作成した人々もすべてソフトウェア サプライ チェーンの一部です。
この複雑なチェーンの各ノードは、ソフトウェアのパフォーマンスとセキュリティに何らかの形で影響を与える可能性のある潜在的な脆弱性ポイントです。この依存関係チェーンのどの時点でも脆弱性が導入されると、下流に深刻な影響を及ぼします。ソフトウェア サプライ チェーンの複雑さによってリスクが隠蔽され、サプライ チェーンを保護するための標準化されたフレームワークがなければ予測と特定が困難になるためです。このため、開発者と製品組織にとって次のことが重要です。 ソフトウェア サプライ チェーン セキュリティとは何かを学びます。
ソフトウェア サプライ チェーン セキュリティとは、アプリケーション開発の時点から継続的な統合と展開 (CI/CD パイプライン) を通じて、ソフトウェア開発ライフサイクル全体にわたって潜在的な脆弱性からソフトウェアを保護するために導入された一連の標準化された実践方法を指します。
組織のソフトウェア サプライ チェーンを安全に保つために、セキュリティ チームがソフトウェア サプライ チェーンのセキュリティのベスト プラクティスのリストを理解し、従うことが重要です。この投稿では、知っておくべきサプライ チェーンのベスト プラクティスについて詳しく説明します。
ソフトウェア サプライ チェーンを保護するためのベスト プラクティス
このセクションでは、ソフトウェア サプライ チェーンを保護するために開発者と製品組織が従う必要がある標準的な慣行について言及します。これらのガイドラインは、ソフトウェア ライフサイクルのさまざまな段階で組織のセキュリティ実践を説明、評価、測定するための基本的なフレームワークとして使用できます。これらのベスト プラクティスは、ソフトウェア サプライ チェーンの取得、開発、展開の各段階を横断して、開発環境、ソース コード、および最終製品の整合性を確保します。
十分に安全なコンポーネントを入手する
サードパーティのコンポーネントをソフトウェアに組み込むことは、開発者にとって標準的な方法です。これにより、最初から構築するのではなく、既存の API 機能を活用して必要な機能を提供できるようになります。サードパーティ コンポーネントは、商用の独自ソフトウェアまたは無料のオープンソース ツールのいずれかの形式をとることができます。これらのコンポーネントのいずれかを調達する場合、ソフトウェア コンポーネントが満たさなければならない最も重要な基準の 1 つとしてセキュリティを考慮することが重要です。
サードパーティ コンポーネントのセキュリティを判断するには、安全な構成分析、脆弱性データベース分析、ソース コード評価、リスク評価分析などの高度なセキュリティ分析を実行する必要がある場合があります。これらのチェックの結果は、このコンポーネントが安全であり、製品に許可されるべきかどうかを判断するのに役立ちます。
さらに、自動化された脆弱性追跡サービスを使用して、選択したコンポーネントを継続的に監視し、脆弱性をできるだけ早く特定し、即座に削除する必要があります。
安全なコーディング慣行を遵守して安全なソフトウェア コンポーネントを社内で作成する
ソフトウェアに組み込まれる外部ソフトウェア コンポーネントは重要ですが、ソフトウェア製品のセキュリティと完全性は、社内で従う安全なコーディング慣行にも依存します。
すべての組織には、作成された成果物が規定のガイドラインに準拠していることを確認するために、安全なコーディング手法を組み込んだ包括的なソフトウェア開発ライフサイクル フレームワークが必要です。
まず、ソフトウェア製品と社内で構築する成果物の整合性は、チームの品質に依存します。開発チームには、開発専門家、品質保証、サイバーセキュリティの専門家、および標準的なセキュリティ慣行に関する十分な知識を持つビルド エンジニアが含まれている必要があります。
製品管理チームには、安全な開発ポリシーへの準拠を確保するために働くセキュリティ アーキテクト、製品マネージャー、製品リーダーも含める必要があります。安全なソフトウェア成果物を社内で確実に作成するための基本的な戦略には、次のようなものがあります。
- 各アーティファクトの設計およびアーキテクチャのドキュメントを生成する
- ソフトウェア製品の脅威モデルの作成
- セキュリティテストの定義と実装
- 製品を評価するための具体的なリリース基準の設定
- 製品ごとの脆弱性対応ポリシーの策定
- 各ソフトウェア リリースのセキュリティ手順を文書化して公開する
安全なサードパーティ ソフトウェア ツールチェーンと互換性ライブラリを使用する
ソフトウェア開発プロセスで使用される統合開発環境 (IDE) の多くは、自己完結型です。これは、コーディング、コンパイル、パッケージ化、コードのデバッグなど、開発プロセス内のさまざまな手順をすべて同じツールから実行できることを意味します。一部の IDE には、ソースを外部リポジトリに接続するツールもあります。この機能を備えた IDE は、複数のコンパイラ言語をサポートします。これらのコア機能に加えて、開発者はプラグインを使用して使用する IDE の機能を拡張できる場合があります。このような信頼できないソースは複雑であるため、これはローカル開発環境の潜在的な脆弱性の原因となります。
開発環境を安全に保つために、環境内で使用されるすべての IDE とプラグインは、脆弱性のスキャンと検証後に監査され、事前承認される必要があります。
ビルド環境の機能を拡張するプラグインに加えて、脆弱性をチェックする必要があるサードパーティ ビルド ツールのもう 1 つのカテゴリは、ソフトウェア ツールチェーンと互換性ライブラリです。これらのサードパーティ オペレーティング システム ツールは開発環境にインストールされ、そのオペレーティング システムに固有の特定のユーティリティやコマンドを使用できるようになります。たとえば、Windows 開発環境では、運用プロセス中に両方のシステム間の互換性を確保するために、ビルド プロセス中に Linux オペレーティング システムに固有のいくつかのオペレーティング システム コマンドが必要になる場合があります。
同様に、API 変換ライブラリは、2 つの異なるオペレーティング システムに共通のコーディング環境を作成するのにも役立ちます。これらの API ツールチェーンはオープンソースの商用ツールであり、ビルド環境に採用され、プロジェクトで使用される前に、アクセスして脆弱性を見つける必要があります。
内部関係者によるソースコードの改変や悪用を軽減する
サイバーセキュリティ・インフラストラクチャ・セキュリティ庁 (CISA) によると、インサイダーとは、組織のリソースへのアクセス権または知識を許可された人物を指します。お客様の施設、ネットワーク、機器、およびシステムにアクセスした、またはアクセスしていた個人は、意図的か無意識にかにかかわらず、ソフトウェア製品の完全性を危険にさらす可能性があります。
ソフトウェアを保護する取り組みの一環として、侵害された担当者、十分な訓練を受けていないエンジニア、または非アクティブな従業員などの内部関係者によって、本番コード内の悪意のあるコードが意図的または意図せずに公開されることを防ぐためのポリシーが開発プロセスに導入されていることを確認する必要があります。これを軽減するために導入できる対策には、次のようなものがあります。
- バランスが取れ、認証されたソースコードのチェックインプロセス
- 脆弱性の自動セキュリティスキャン
- 安全なソフトウェア開発トレーニング
- 開発環境の強化
- コードレビューの優先順位付け
コードまたは実行可能ファイルを保存し、承認前にすべての変更を確認します
バージョン管理は、ソフトウェアの整合性を維持するのに役立つ標準的な方法の 1 つです。継続的インテグレーションとデプロイのプロセス (CI/CD パイプライン) の一環として、コードと実行可能ファイルを保存するリポジトリを維持する必要があります。これにより、コードの作業履歴が提供されるため、その時点までに開発スタックに何が入ったかを簡単に追跡できます。
また、ソフトウェアに加えられたすべての変更を承認前にレビューするには、継続的な承認システムも必要です。これは、チーム内の他の開発者と共同作業する場合に特に便利です。この場合、変更が加えられ、誰が加えたかを簡単に特定できるため、問題のトラブルシューティングが容易になります。
構築しているソフトウェアがどれほど単純か複雑かに関係なく、ソースまたはバージョン管理システムを使用すると、コードに加えられたすべての変更を簡単に確認して追跡したり、必要に応じてバージョン履歴を追跡したり、以前のバージョンに戻すこともできます。必要に応じてコードを入力します。
作成されたソフトウェア パッケージごとに SBOM を作成および維持する
この ソフトウェア部品表 は、ソフトウェア製品に組み込まれているすべてのサードパーティ コンポーネントの詳細を記載した重要なドキュメントです。 SBOM を使用すると、ソフトウェアのすべての承認済みコンポーネントを簡単に検証し、脆弱性や欠陥を簡単に特定できます。作成するソフトウェア パッケージごとに、そのパッケージの SBOM も作成して維持する必要があります。
ソフトウェア部品表は、Linux、OWASP、NIST でそれぞれ定義されている Software Package Data Exchange (SPDX)、CycloneDX、Software Identification (SWID) タグなどの標準形式で定義された仕様に基づいて作成できます。
あなたが構築するすべてのソフトウェア製品について、使用するサードパーティ コンポーネントのサプライヤーまたは所有者は、包括的なソフトウェア部品表を提供する必要があります。プロジェクトの成果物とサプライヤーが提供する SBOM は、構成分析 (SCA) ツールを使用して検証することもできます。
サプライヤーが SBOM を提供しない場合でも、ソフトウェア構成分析ツールで生成された SBOM は、ソフトウェアのサードパーティ コンポーネントを説明するために必要な情報を提供できます。のプロセス SBOM の生成 自動化する必要があります。 SBOMの自動化 サードパーティ ベンダーや開発者はサードパーティ ソフトウェアが変更されるたびに新しい SBOM を生成する必要があり、手動でそれを行うのは現実的ではないため、これは非常に重要です。更新された SBOM には、コンポーネント コードの機能強化や変更、およびそれらのコンポーネント コードとの関係が記述されます。ソフトウェア製品。
ビルド環境を強化する
ソフトウェアの整合性を確保する方法の 1 つは、潜在的な脆弱性に対して開発環境を強化することです。これには、個々の開発環境と全体的な運用ビルド環境の両方が含まれます。
ビルド環境がクラウドでホストされているかオンプレミスでホストされているかに関係なく、ビルド環境を構成し、サーバーとネットワークを保護すると同時に、誰が何にアクセスできるかを制御するための対策を講じる必要があります。この方法でビルド環境の最適化とセキュリティ保護におけるデュー デリジェンスを実行すると、ソース コードと最終製品の整合性が保証されます。
ビルド パイプラインの保護には、製品のビルド プロセス中に使用するすべてのシステムの保護が含まれます。これには、コード リポジトリ、署名サーバー、エンジニアリング ワークステーション、展開サーバーなどが含まれます。ビルド パイプライン インフラストラクチャを保護するために導入できる対策には、次のようなものがあります。
ロックダウンシステム
システムを保護するには、システム操作を、システムが実行する予定の特定の機能に制限する必要があります。たとえば、ビルド システムはビルド操作にのみ使用し、それ以外には使用しないでください。
外部ネットワークおよびオフLANネットワークアクティビティを制限する
インバウンドとアウトバウンドの両方のネットワーク アクティビティにより、システムが危険にさらされる可能性があります。 攻撃。すべての外部および LAN 外のアクティビティを遮断し、外部接続を必要な URL に制限する必要があります。
システムのデータ漏洩を監視する
製品のソース コードの整合性を確保するには、リポジトリ、ワークステーション、およびビルド環境のその他の部分をデータの漏洩や侵入から保護するサイバーセキュリティ防御を設定する必要があります。これには、すべての悪意のある動作のブロック、アプリの隔離、侵入が発生したらすぐに捕捉する検出システムの設定が含まれます。
バージョン管理パイプラインを構成する
コード パイプラインはバージョン管理されている必要があります。製品に変更を加える場合は、実際のシステムではなく、構成コードを更新する必要があります。
マルチファクタ認証
ビルド環境の一部である各システムは、可能な限り多要素認証を使用して構成する必要があります。役割ベースのアクセス、最小権限などの追加のセキュリティ対策も導入する必要があります。 NIST ガイドラインでは、ビルド環境内のすべての重要なシステムまたは機密性の高いシステムに対して二重認証システムを推奨しています。
エンジニアリングネットワークを分離する
ビルド システムには、組織の他のネットワークとは異なる隔離されたエンジニアリング ネットワーク経由でのみアクセスする必要があります。可能であれば、エンジニアリング ネットワークはオフラインにする必要があります。
各脆弱性を分析して、修復を計画するのに十分な情報を収集します。
ソフトウェアを開発するときは、製品とそのすべてのコンポーネントに既知の高リスクの脆弱性が存在しないことを確認するための対策を講じる必要があります。同様に、新しい脆弱性が発見または顧客によって報告された場合は、直ちにインシデントに対応する必要があります。場合によっては、新たに発見された脆弱性に関連するリスクを軽減するためにシステムを更新する必要があります。
ソフトウェア ベンダーは、サードパーティの研究者または顧客から自社製品の潜在的な脆弱性や欠陥に関するアップデートや報告を受け入れるためのプロセスを整備する必要があります。また、サイバーセキュリティ・インフラストラクチャセキュリティ庁 (CISA) などの信頼できる組織によって発表された脆弱性の更新を通知する自動システムも必要です。
すべての組織には、標準ガイドラインに準拠した内部脆弱性管理ポリシーが必要です。高リスクの脅威に関するアラートは、報告された脆弱性の影響を受ける可能性のある製品とそのコンポーネントとの関係に基づいて評価する必要があります。エンジニアリング チームには、問題を確認、診断し、場合によっては解決するための包括的なシステムも必要です。
コンポーネントのメンテナンス
ソフトウェア製品とそのコンポーネントは決して静的ではありません。製品に組み込まれているサードパーティのコンポーネントは、サプライヤーによって定期的に変更または更新される可能性があることに留意してください。これらの変更は、特に Common Vulnerabilities and Exposures (CVE) に関連する場合に監視する必要があります。
ソフトウェア コンポーネントの保守の大部分は、標準の CVE レポート メカニズムやその他のサポート チャネルを監視して、製品に組み込まれているサードパーティ コンポーネントで新たに特定された脆弱性が独自のシステムの整合性に影響を与えるかどうかを判断し、リスクを軽減するために適切な措置を講じることです (あれば）。
製品に含めるサードパーティ コンポーネントを選択する場合は、契約をチェックして、コンポーネントの所有者が、システムの更新、脆弱性の存在、および脆弱性の期間について製品組織に通知する方法に関するポリシーを持っていることを確認する必要があります。解決策と、最適なセキュリティを確保するためにユーザー側で実行する必要があるアクションを確認します。