過去数年間の主要なソフトウェア サプライ チェーン攻撃から学んだことが何かあるとすれば、 SolarWinds & ログ4シェル この種の攻撃は非常に破壊的なものになる可能性があるということです。しかし、今日の相互接続されたデジタル世界では、企業がそれらを回避することがますます困難になっています。
ソフトウェア サプライ チェーン攻撃の影響を受けない人は誰もいません。これらをさらに悪化させるのは、1 つの企業に侵入すると、ソフトウェア サプライ チェーン上の何千もの企業が攻撃にさらされる可能性があることです。これが意味するのは、自社の内部システムを保護するだけでは十分ではないということです。組織がサプライ チェーンのリスクを積極的に軽減し、攻撃を軽減できる方法の 1 つは、ソフトウェア部品表 (SBOM) として知られる概念を採用することです。
組織では、日常業務のさまざまな側面を実行するために、さまざまな外部システムに依存している可能性があります。ただし、プロバイダーが開示しない限り、これらの外部システムがもたらすリスクを把握することはできないでしょう。 SBOM は、使用するソフトウェア コンポーネントを構成するものについての洞察を提供する包括的な成分リストとして機能します。この文書は、 サプライチェーン攻撃リスクを管理するための重要なコンポーネント.
サプライチェーンリスク管理におけるSBOMの機能は何ですか?
使用するサードパーティ ソフトウェアの可能性を十分に理解し、リスクを軽減するには、その構成を知る必要があります。ソフトウェア部品表 (SBOM) は完全な透明性を提供するため、内部システムのセキュリティをより適切に制御できるようになります。
ソフトウェア部品表は、ソフトウェアまたはアプリケーションのコンポーネント、サービス、およびサードパーティの依存関係のリストです。 BOM の概念は新しいものではありませんが、ソフトウェアの世界で応用されるようになったのはつい最近のことです。この概念の根源は、メーカーが通常、製品を構築するためにさまざまなベンダーの部品を使用する製造業界にまで遡ることができます。製品の歴史を追跡し、将来のメンテナンスを容易にするために、すべてのコンポーネントと各コンポーネントがどこから来たのかを詳細に記載した部品表が作成されます。
SBOM は、多くの米国政府機関に影響を与えた 2020 年の Solarwinds 攻撃の後、最近になって普及しました。これに対して、 バイデン大統領が大統領命令を出した 連邦機関に要請を義務付けた SBOM ソフトウェア開発者とその提携ベンダーから提供されます。サプライ チェーン攻撃を防ぐことはできませんが、正確な SBOM はソフトウェア製品内のすべての依存関係を明らかにします。これにより、透明性を確保し、サプライ チェーンの脆弱性を明らかにし、サプライ チェーンのリスクを軽減できる貴重なサイバーセキュリティ ツールとなります。
オープンソース コードに依存する開発者にとって SBOM が重要な理由
サードパーティまたはオープンソース コードの再利用は、最新のソフトウェア開発プロセスに不可欠な部分です。開発者は依然として独自のコードを記述する必要がありますが、サードパーティのオープンソース コンポーネントをソフトウェアに日常的に統合しています。これを行うことは、プロジェクトを高いペースで進め続けるために非常に必要になっています。
これまで、オープンソース ソフトウェアを使用する組織や開発者がそのコンポーネントについて知りたがる唯一の理由は、ライセンスの問題を回避するためでした。多くのオープンソース ソフトウェアには、使用と配布が制限されたコンポーネントが含まれており、それらを利用したい人はこれらの制限を認識する必要がありました。しかし現在、開発者は、オープンソース ソフトウェアを使用することのリスクはライセンスを超えていることを認識し始めています。セキュリティ上の懸念も生じる可能性があります。部品表は、オープンソース ソフトウェアのライセンス要件とセキュリティ要件の両方を理解するために不可欠です。
開発者にとって、ソフトウェア部品表は、使用しているオープンソース ソフトウェアのコードベースをよりわかりやすく表示します。これにより、多くの場合、時間と労力を節約できます。たとえば、新しい脆弱性が発見された場合などです。部品表がなければ、開発者はすべてのソフトウェアをレビューして問題の原因を特定する必要があります。複雑なプロジェクトの場合、これは大変で時間のかかる作業です。 SBOM を使用すると、脆弱性を含むソフトウェアを簡単に特定でき、必要なバグ修正がすぐに実行されます。その他の理由 SBOM ソフトウェア開発においては非常に重要です。
-
コードの肥大化を軽減—使用するオープンソース コードごとに、同様の機能を実行するわずかに異なる代替コードがおそらく数十存在します。 SBOM を使用すると、システムのコンポーネントの標準リストを作成することで冗長性を減らすことができます。また、使用する各コンポーネントには独自の欠陥や脆弱性があるため、必要な部分だけコードを整理しておくと、脆弱性の追跡と修正が容易になります。
-
ライセンス義務を遵守します—ライセンスがソフトウェアのすべてのコンポーネントを知ろうとする主な動機の 1 つであることについてはすでに述べました。 SBOM を取得すると、使用することを選択したコンポーネントに対するすべてのライセンス義務を確実に遵守できます。
-
リスクをプロアクティブに評価して修正する—新たに特定されたリスクを特定して修正することは難しく、時間がかかる場合があります。ただし、コンポーネントの概要を明確に示したリストがあれば、積極的に脆弱性を探して修正し始めることができます。これにより、問題を特定するまでの時間が短縮され、プロセスがより効率的になります。
-
テストとコードレビューが容易になります—ソフトウェアを展開する前に、広範なテストとレビューを行う必要があります。開発者がそのソフトウェアのすべてのコンポーネントとサブコンポーネントを明確に理解している場合、このプロセスはより簡単になります。 SBOM を使用すると、レビュー時間を大幅に短縮できるため、ドキュメントを使用しない場合よりも早くコードを実稼働環境に導入できるようになります。
SBOM を使用すると、コードの作成中の初期段階でセキュリティ テストを開始し、有害なコンポーネントを検出して回避できます。また、このドキュメントはサードパーティのコードとそのコンポーネントに関するより深いコンテキストを提供し、コード ベースのレビューや変更に必要な作業と時間を削減します。
-
サポート終了 (EOL) ソフトウェアを特定する —これは、オープンソース ソフトウェアではよくある現象です。場合によっては、サプライチェーンのはるか上流にあるサプライヤーが製品のサポートを終了したために、これらのコンポーネントが寿命に達することがあります。まだ機能しますが、サポートされていないオープンソース ソフトウェアは、脆弱性が悪用される可能性がある主要なノードです。 SBOM を使用すると、EOL ソフトウェアを監視し、可能であればそれを置き換えるための事前の措置を講じることができます。
SBOM の使用例と利点
ソフトウェア部品表 (SBOM) の入手は、開発するすべてのソフトウェアに必須ではありません。ただし、その準備は、すべてのデジタル製品開発者が検討する必要があるベスト プラクティスになりつつあります。以下に、このドキュメントが非常に価値のある SBOM の使用例をいくつか示します。
SBOMの使用例
連邦要件への準拠
2020年と2021年の大規模なソフトウェアサプライチェーン攻撃を受けて、バイデン大統領は次の声明を発表した。 行政命令 これは、政府にソフトウェア ソリューションを提供する政府機関やベンダーに対する主要な推奨事項の概要を示しています。大統領令に含まれる要件の 1 つは、連邦政府が使用するすべてのソフトウェアに SBOM を含めるという提案でした。 SBOM はすべての人に義務付けられているわけではありませんが、米国連邦政府にソフトウェアを提供するすべての組織は、使用するすべてのコンポーネントと行ったバージョン変更の詳細を記載した SBOM を提供する必要があります。
ソフトウェア消費者のリスクを軽減する
SBOM は、ソフトウェア ツールのサードパーティ コンポーネントを完全に可視化します。ソフトウェアのすべてのコンポーネントとサブコンポーネントを追跡することは、組織が使用予定または既に使用しているソフトウェア ソリューションのセキュリティとコンプライアンスの標準を検証できる方法の 1 つです。
部品表のないソフトウェアを使用する消費者は、サプライヤーから入手したコードにオープンソース コンポーネントが含まれていることをおそらく認識しているでしょう。ただし、これらの成分は不明であるため、消費者はソフトウェアの潜在的な悪意のあるコード、サポートされていないコンポーネント、その他の脆弱性に気づいていない可能性があります。
危機的状況への迅速な対応
SBOM を使用すると、ソフトウェア コードベースを可視化できます。最終的に、これにより開発者は危機が発生した場合に対応しやすくなります。たとえば、SBOM がなければ、新しい脆弱性に対処しようとしているソフトウェア エンジニアリング チームは、問題を特定するために使用するすべてのソフトウェアを手動でレビューする必要があります。ただし、部品表があれば、脆弱性が含まれる可能性のあるソフトウェアを絞り込み、必要な修正を非常に短時間で実行することが容易になります。これにより、危機解決の時間を節約し、発生する可能性のある損害を最小限に抑えることができます。
情報の非対称性の問題
現在、ソフトウェア市場には情報の非対称性の問題があります。アプリのセキュリティに関する完全な情報を秘密にしておくことで、ソフトウェア ベンダーやプロデューサーはソフトウェアの品質について責任を負うことがなくなります。 SBOM は、ソフトウェア顧客が製品のセキュリティに関する情報を利用できるようにします。これにより、制作者はソフトウェア開発における最高のセキュリティ標準に準拠する必要があります。
M&Aのサポート
ソフトウェア部品表は、企業を買収する際に必要となる文書の 1 つです。企業買収のプロセスの一部には、買収の潜在的なリスクを評価するためのデューデリジェンスが含まれます。 SBOM は、企業が運営するセキュリティ フレームワークと買収の潜在的なリスクについての深い洞察を提供します。
SBOM の利点
現代の組織における最も重要なセキュリティ対策の 1 つは、ソフトウェア サプライ チェーンのリスクにアクセスすることです。これには、組織のソフトウェア スタックに、サプライ チェーンのリスクを構成する可能性のあるサードパーティ構成要素が含まれているかどうかを知ることが含まれます。これらのソフトウェアの脆弱性は、他のソフトウェア アプリケーションに依存するコンポーネントでよく見られます。このため、ソフトウェア部品表は製品セキュリティ フレームワークの重要なコンポーネントです。以下に最も重要なものをいくつか示します SBOMのメリット.
- 脆弱性に積極的に対処する - SBOM の最終的な利点は、組織が使用しているソフトウェアのセキュリティ フレームワークを精査し、脆弱性を特定し、それらを積極的に排除する方法を見つけることです。これにより、組織はサプライ チェーンのリスクを軽減できます。
- セキュリティ危機の管理プロセスを改善する—SBOM を作成しても、システムの脆弱性が除去されたり、ソフトウェア サプライ チェーンの攻撃が完全に防止されるわけではありません。ただし、サプライチェーンのリスクが軽減され、危機が発生した場合の管理プロセスを改善できます。ソフトウェア アプリケーションの潜在的な脆弱性ポイントとなる可能性のあるすべての依存関係のリストを作成すると、リスク管理のプロセスが簡素化されます。
- コストを削減-SBOM を活用してセキュリティ リスクに対処することの結果の 1 つは、長期的にはコストが削減されることです。コードを手動で解析して脆弱性を見つけるプロセスは、非常にコストがかかる場合があります。ソフトウェア部品表は、ソフトウェアの基礎となるライブラリを可視化します。これにより、時間を節約し、セキュリティ評価のコストを削減できます。
まとめ
自社の評判を真剣に考えているすべてのソフトウェア組織にとって、データで継続的に更新される包括的な SBOM を作成することは、ソフトウェア サプライ チェーン攻撃の影響を未然に防ぐための重要な方法の 1 つです。ソフトウェア製品を構築する場合、サードパーティ ソフトウェアの使用は事実上避けられないため、使用するすべてのコンポーネントの包括的な成分リストがあれば、問題を絞り込み、より効果的に解決することが大幅に容易になります。また、ソフトウェア ライセンスの問題や、場合によっては政府の規制への準拠も容易になります。