ソフトウェア部品表 (SBOM) の価値

公開: 2023-11-28

過去 1 年間、サプライ チェーンの安全性について少し考えたことがある人なら、おそらく「ソフトウェア部品表」(略して SBOM) という用語をご存知でしょう。 最も単純な形式では、SBOM はソフトウェアの構成要素リストと比較できます。 ただし、実際には、はるかに洗練されています。

ソフトウェア再販業者、オープンソース ツール、ホワイトラベル アプリケーションへの依存度が高い今日のデジタル主導の企業では、ソフトウェア部品表を持つ価値はどれだけ誇張してもしすぎることはありません。

SBOM の定義: ソフトウェア部品表 (SBOM) とは何ですか?

ソフトウェア部品表は、製品の構築に使用される基本コンポーネント (コード リソースなど) のリストです。 サプライ チェーン内のさまざまなソフトウェア要素間の接続を概説する機械可読情報と詳細を提供します。

SBOM は本質的に、信頼とセキュリティに重点を置き、扱うデジタル「マテリアル」の完全性に関するものです。 ソフトウェアが構成されているコンポーネント、これらのファイルの出所、作成方法、信頼できる個人によって安全に署名されているかどうかを識別できます。

SBOM は、ソフトウェア開発者と消費者がソフトウェア開発と配布のライフサイクルにおける自信と信頼性を高めるために使用できるツールです。

Gartner は、2025 年までに、重要なインフラストラクチャ向けのソフトウェアを開発または調達している組織の 60% が SBOM の使用を義務付けられると推定しています。これは、2022 年の 20% 未満から大幅に増加しています。その理由と、ソフトウェア請求額の正確な価値を見てみましょう。材料。

SBOM とサイバーセキュリティ: ソフトウェア部品表の維持が重要な理由

公共部門と民間部門の両方で、サイバー攻撃は今やあまりにも一般的になっています。 2022 年下半期には、政府部門に対する侵入件数が 2021 年の同時期と比較して 95% 増加しました。

サイバー攻撃による世界経済への影響は、2022 年の 8 兆 4,400 億ドルから 2027 年には 23 兆 8,400 億ドルへと劇的に増加すると予想されています。

そのため、企業、サイバーセキュリティ擁護団体、さらには政府が、デジタル インフラストラクチャの重要な部分として SBOM を推進していますが、あると便利なものではありません。

実際、2021 年 5 月の「国家のサイバーセキュリティの向上」と題された米国大統領令 (EO) 14028 では、米国連邦データベースのセキュリティを強化するために SBOM の使用が義務付けられています。 これにより、政府機関と協力するソフトウェア プロバイダーに対してソフトウェア部品表が義務付けられます。

結局のところ、企業が自社のソフトウェアの内部に何があるのか​​を知らなければ、それが企業や潜在的な下流顧客にもたらすリスクを完全に理解したり評価したりすることはできません。

SBOMの使用例

ソフトウェア部品表は、サードパーティ ソフトウェアを可視化してサプライ チェーン攻撃への対処を容易にするだけでなく、次の点でも役立ちます。

  1. ベンダーとバイヤーの関係を強化する

    ソフトウェア開発者もユーザーも、自分が使用しているソフトウェアを信頼する必要があります。 SBOM に含まれるメタデータは、個人がソフトウェアの整合性を検証し、システムやプロセスに影響を与える可能性のある欠陥のあるコンポーネントや脆弱なコンポーネントを迅速に認識するために使用できます。

    同様に、SBOM は、ソフトウェア開発者が安全な最先端のソフトウェアを作成するために講じる必要がある安全対策を強調することができます。

  2. より包括的な脆弱性分析の実施

    企業は SBOM コンポーネントの脆弱性を検査できます。 問題が存在する場合は、どの依存関係を修正する必要があるかにも注意します。 脆弱性とは、ソフトウェアに損害を与えたり、ソフトウェアが動作するシステムに損害を与えようとする悪意のある攻撃者によって悪用される可能性がある欠陥です。

    SBOM を使用すると、使用中のソフトウェアが定期的に最新のアバターで更新されるようになります。 そうでない場合は、ソフトウェア全体をレビューするためにリソースを無駄にするのではなく、時代遅れのコンポーネントのみについてリスク分析を実行できます。

  3. より高品質なソフトウェアの提供

    古いことわざにあるように、「何をするかを言い、言うことを実行する」 同様に、SBOM を作成して評価するという行為は、通常、開発者がソフトウェア ビルドが本当に最適な状態であるかどうかを判断するのに役立ちます。

    一貫性があり、再現可能ですか? 生成された SBOM は、ソフトウェアに含まれているとエンジニアが信じている内容を反映していますか? それとも溝が存在するのでしょうか? ほとんどの SBOM ジェネレーターは、ベンダーが認識していなかったソフトウェアに関する少なくともいくつかの項目を明らかにするため、ソフトウェアの品質を向上させ、最良のビルドのみを公開することができます。

  4. 調達の意思決定の向上

    サードパーティ ソフトウェア プロバイダーが提供する SBOM を使用すると、調達マネージャーはより多くの情報に基づいてソフトウェア購入の意思決定を行うことができます。 ソフトウェア部品表を使用すると、IT 調達専門家はソフトウェアの「内部」を調査して、購入前にソフトウェアがどのように機能するかを把握できます。

    購入前に SBOM が利用できない場合は、購入後の妥当な期間内 (ベンダー ロックインが始まる前) にこのユースケースを利用し、必要に応じてプロバイダーを切り替えることができます。

  5. 相互運用可能なエンタープライズ システムの構築

    エンタープライズ アーキテクトは、企業のテクノロジー フレームワークの構築を担当します。 建築設計者の場合と同様、手元にあるリソースの各要素を把握していれば、技術スタックをまとめるのがはるかに簡単になります。 これは、アーキテクトがソフトウェアの出所、機能、制限を完全に把握していない合併や買収の場合に特に当てはまります。

  6. セキュリティインシデントへの対応強化

    SBOM は、イベントの発見と推奨事項の検証、つまり何がうまくいかなかったのかを示す方向性の指標として機能します。 SBOM は、裏付けとなる証拠として、インシデントの調査と、同時システムまたは以前のシステム バージョンへの影響の評価を支援します。

    インシデントの発生中および発生後、SBOM は、協力者、影響を受けたグループ、顧客間のやり取りを促進することもできます。

    SBOM によって列挙された内容が配布時にかなり正確であり、特定された脆弱性または未解決の脆弱性が存在しないことを検証することは、インシデント対応管理における SBOM のさらなる応用です。

    これにより、データ侵害または同等の重大度のインシデントに直面した企業の法的リスクと法的責任を軽減できます。

SBOM の使用に関する企業の考慮事項: SBOM の価値を最大化する方法

お客様が使用できる完全なソフトウェア部品表を組み立て、フォーマットし、提供するのはベンダーの責任です。 ただし、SBOM を取得するだけでは十分ではありません。 企業には、SBOM を最も価値のあるユースケースに導くためのガバナンス戦略が必要です。

  1. SBOM リクエストを送信するベンダーを把握する

    通常、リソースには固定の使用制限があるため、ビジネスへの影響分析から始めて、最も重要なサービス プロバイダーと商用既製または COTS ソフトウェア ソリューションを決定する必要があります。

    厳格なセキュリティ基準を設けている一部の企業では、組織のデータに何らかの影響を与えるすべてのベンダーが SBOM を提出する必要があります。 他の関係者にとっては、おそらく、主要なサービス プロバイダーのサブセットのみがこのプロセスに参加する必要があります。

    ベンダーの専門知識のレベルも考慮することが重要です。 確立された企業ベンダーは、気まぐれな新興企業と比較して、お客様が求めるものを提供する準備ができています。

  2. SBOM 更新の頻度を決定し、自動化を使用する

    SBOM を提出する必要がある規則性も考慮することが重要です。 特定の業界では、ソフトウェアが更新されるたびに顧客が更新を必要とする場合があります。

    SaaS プラットフォームでは、これが継続的に (時間単位または日単位で) 発生する可能性がありますが、このレベルの頻度では、ベンダーに SBOM データの収集と配信の義務が過度にかかることになります。 通常、スケジュールされた間隔 (毎日、新しいバージョンごとなど) で製品の SBOM の「概要またはスナップショット」をリクエストすることが望ましいです。

    契約に SBOM 配信のための正式なサービス レベル契約 (SLA) が含まれているかどうかを確認してください。

  3. SBOM交換とバージョン管理ワークフローを確立する

    JSON ファイルと XML ファイルでいっぱいのメールボックスは、データを管理する非効率的な方法です。 組織には少なくとも、各 SBOM のバージョンを監視および監督するための構造化された方法が必要です。

    理想的には、含まれる情報を取り込み、デコードし、評価できるシステムが必要です。 SBOM データは、Anchore や Mend.io などのプラットフォームによって取り込まれ、自動アラートの送信や自動セキュリティ分析などの機能を実行できます。

次のステップ

組織のセキュリティ プロトコルをさらに強化するには、SBOM を脆弱性管理ツールに接続します。 たとえば、アプリまたはコンテナのスキャナは SBOM データを使用して、認識されている脆弱性やリスクを検索できます。

サイバー攻撃の頻度が増加するにつれ、サプライチェーンの安全性は現在、すべての企業にとって重要な考慮事項となっています。 ソフトウェア部品表 (SBOM) は、組織がソフトウェア コンポーネントを識別して監視するのに役立つ非常に有益なツールです。 また、潜在的な安全性や効率性の問題についてもユーザーに十分に知らせることができます。

次に、コンプライアンスを超えたセキュリティに関する Splunk の最新の洞察を活用して、SBOM 戦略を構築します この記事を読んで気に入ったら、上部の Facebook、Twitter、または LinkedIn ボタンをクリックしてソーシャル メディアで共有してください。