ソフトウェア部品表 (SBOM) は新しい現象ではありませんが、その必要性は高まり続けています。開発者がこれまで以上に多くのオープンソース コードやサードパーティ コードをアプリケーションに追加するにつれて、ソフトウェアはますます複雑になっています。一方で、規制も強化され、ソフトウェア コンポーネントの出所、作成者、作成時期、目的、バージョン番号を知る必要性が高まっています。
ソフトウェアをより速くリリースするという絶え間ない圧力により、ソフトウェアのバージョンは開発者が制御できない方法で絶えず変化しています。
「SBOMのようなものでソフトウェアの構成を（理解し）ないと、（多くの）理由でコストがかかる可能性があります。これには、脆弱性、ライセンスの使用、複雑さに関する指標、エンジニアリングポリシーの違反など、ソフトウェアの構成に関連するさまざまなことが含まれます」と、ソフトウェアサプライチェーントランスペアレンシーのCTO兼共同創設者であるマイケル・リーバーマンは述べています。 鎖 電子メールのインタビューで、彼は次のように答えました。「重要なのは、SBOM が真空中に存在する必要がないということです。SBOM はオープン スタンダードであり、組織はこれを使用して単一のソフトウェアに関連するリスクを理解できるだけでなく、複数のソフトウェアにまたがるリスクをより深く理解することもできます。」
ソフトウェアの依存関係は、SBOM を使用するもう 1 つの理由です。
「開発者がアプリケーションにもたらす各依存関係のコード行をすべて確認することはほとんどないため、ソフトウェアサプライチェーンに侵入する新しい脅威を発見するための複数のパスを用意することがこれまで以上に重要になっています」と、自動化された秘密検出および修復プラットフォームのCEOであるエリック・フーリエ氏は言う。 ギットガーディアン電子メールのインタビューで、彼は次のように答えています。「SBOM、特にライブSBOMは、セキュリティチームが新しい問題を監視し、新しいエクスプロイトが発見されて報告されたときに迅速に対応するのに役立ちます。」
コンプライアンスも推進力となります。
「BOM に関連する主なコンプライアンス リスクの 1 つは、ソフトウェアで使用されるすべてのコンポーネントがそれぞれのライセンスに準拠していることを確認することです。オープンソース ライセンスにはさまざまな要件があり、広範な使用と変更を許可する許容ライセンスから、派生作品を同じライセンスの下でリリースすることを要求するより制限的なライセンスまであります。ライセンス条件に従わないと、訴訟や罰金など、組織にとって大きな法的結果につながる可能性があります」と、社内開発者ポータル プロバイダーの開発者関係責任者である Justin Reock 氏は述べています。 コルテックスIDP電子メールのインタビューで、彼は次のように答えています。「これらのリスクを軽減するには、企業は正確な BOM を作成および維持し、定期的に脆弱性評価を実施し、ライセンスを効果的に管理し、ソフトウェア開発ライフサイクル全体を通じて規制および契約上の義務を遵守するための堅牢なプロセスを実装する必要があります。」
AIはソフトウェアの構成要素を理解するのに役立つが、リスクもある
AI はあらゆる種類のアプリケーションに組み込まれており、SBOM も例外ではありません。自動化と組み合わせることで、AI により SBOM の内容が迅速かつ容易に理解できるようになり、GenAI により SBOM の調査が容易になりますが、結果を盲目的に信頼すべきではありません。
「一部の AI モデルは、データの要約に優れていることがわかっています。したがって、SBOM のセットがあれば、そのデータを読み取って人間による要約を提供できる可能性があります。ただし、不正確になりがちなので注意が必要です。他のツールを補完して説明するために使用し、追加のゲートなしで意思決定に使用しないでください」と、Kusari の Lieberman 氏は言います。「その一方で、AI はサプライ チェーンにとって大きなリスクです。従来のオープン ソース ソフトウェアとベンダー ソフトウェアの両方の場合、ほとんどの場合、そのソフトウェアを遡ることができます。現在、AI モデルをトレーニングに使用したデータまで遡ることは困難です。これにより、悪意のある可能性のあるデータでトレーニングされることによるセキュリティ リスクと、モデルが偏ったデータまたは違法なデータでトレーニングされていることが判明した場合のその他の責任の両方が発生します。」
AI によって生成されたコードも考慮すべきリスクです。
「開発者が AI が生成したコードをますます信頼するようになっています。開発者が、結果が十分に良いので、綿密な精査をせずに本番環境に出荷できると安心しきっているのではないかという懸念があります」と GitGuardian の Fourrier 氏は言います。「AI が生成するコードのすべての行を綿密に調べなければ、AI が単純に作り上げたパッケージが悪意のある人物に利用され、脅威は増大し続けるでしょう。SBOM は、警戒を維持するために活用できるもう 1 つのツールです。」
賢明なアドバイス
SBOM を使用していない組織は、今すぐに使い始めるのが賢明です。
「簡単です。取り込むソフトウェアに関するデータをできるだけ多く記録し始めてください。まずは SBOM、静的分析スキャン、in-toto/SLSA などのソフトウェア ビルド アテステーションを生成してください。ベンダーに SBOM を要求し、オープン ソースで探しながら、使用する SBOM のデータが十分に完全で有用かどうかも確認してください」と Kusari の Liberman 氏は言います。「データはパズルの最も重要なピースです。ソフトウェアを安全に開発して使用しているかもしれませんが、データがなければ、何が欠けているか、次の log4shell のような避けられない事態が発生したときに何をすべきかを把握できません。」
AI強化セキュリティ自動化企業のCISO、マイク・ライボーグ氏 スイムレーンは、悪意のある人物が SBOM を悪用する可能性があるため、組織は SBOM を過度に共有しないように注意する必要があると警告しています。
「彼らはクリティカル パスがあることをすぐに見抜くことができます。ソフトウェア A、B、C がこれを使用しているため、偵察活動の範囲を縮小できます」と Lyborg 氏は言います。「誰も SBOM を入手してコード ベースをコピーすることはできません。それがリスクではありません。リスクは、それが悪意のある人物のロードマップになる可能性があることです。アプリケーション スタックを実際に変更していない場合は、サプライ チェーンの依存関係に関連する可能性のある脆弱性が継続的に拡散するだけです。」
最後に、SBOM の使用がチェックボックスの作業ではないことを確認してください。そうしないと、メリットが失われる可能性があります。
「自分が何を実行しているのか分からず、気にも留めないなら、もっと大きな問題を抱えることになるかもしれない」と、オープンソースソフトウェアサプライチェーンセキュリティプロバイダーの共同創設者兼ソフトウェアエンジニアであるヴィレ・アイカス氏は言う。 チェーンガード。 「（SBOM を持つ）理由の 1 つは、脆弱性の影響を受けているかどうかを把握することです。もう 1 つは、メンテナンスが行われていないソフトウェアが存在する場合があることです。ソフトウェアがメンテナンスされていない場合は、代替手段を見つけるか、自分でメンテナンスを開始する必要があります。」