SBOM (ソフトウェア部品表) とは何ですか?
ソフトウェア部品表 (SBOM) は、ソフトウェアを構成するコンポーネントの包括的な目録であり、そのソフトウェアで使用されるすべてのサードパーティソフトウェア (オープンソースと商用の両方) が含まれます。コンポーネントのリストとしての役割を果たすだけでなく、ソフトウェアを提供する相手に、提供するソフトウェアの内容を確実に把握してもらうことができます。では、その保証を提供するには、SBOM にどのコンポーネントを含めることが重要でしょうか？
ソフトウェア部品表を作成する理由
SBOM の作成と保守は、ソフトウェア開発とサイバーセキュリティのベストプラクティスとみなされています。これは、リスク管理とサプライチェーンのセキュリティにとって非常に重要であり、脆弱性管理やソフトウェアライセンスのコンプライアンスに使用されます。ソフトウェアの提供先にとって、SBOMはソフトウェアのコンポーネントが自社のビジネスにリスクをもたらすかどうかを把握できるため、ソフトウェアサプライチェーンの透明性と制御を提供する上で重要な役割を果たします。
ライセンスコンプライアンスに関連するため、顧客は SBOM 内のライセンスと著作権情報に基づいて、SaaS 製品、組込み IoT デバイス、または顧客に出荷および展開されるソフトウェアなど、ソフトウェアを使用できるかどうか、またどのように使用できるかを判断します。 SBOM は「SaaS で安全に使用できる」などの推奨事項を提供していませんが、顧客の法務チームとコンプライアンスチームは、SBOM 内のライセンスと著作権情報に基づいて、ソフトウェアを使用できるかどうか、またどのように使用できるかについて十分な知識に基づいた決定を下します。
セキュリティに関連しているため、新しいソフトウェアの脆弱性が毎日発見されるのは驚くべきことではありません。ソフトウェアを顧客に出荷する場合、そのコンポーネントには今日は脆弱性がないかもしれませんが、明日には状況が即座に変わる可能性があります。顧客に出荷するソフトウェアの各バージョンに SBOM を含めることは、ソフトウェアの特定のバージョンのコンポーネントについて新たに明らかになった脆弱性をあなた (および顧客) が認識できるようにするための鍵となります。
これは、SBOM が対処できるライセンスコンプライアンスとセキュリティリスクの完全なリストではありませんが、SBOM を組み立てる際に完全性が重要な部分である理由を明確にするために、これらのエレメントを取り上げます。存在するかどうかわからない、またはツールが特定の種類のコンポーネントをサポートしていないという理由で SBOM からエレメントを省略すると、顧客を危険にさらし、そのリスクが現実化した場合に評判が損なわれる可能性があります。では、SBOM にはどのようなコンポーネントを含めるべきでしょうか？
SBOM エレメント
人々が SBOM に興味を持つ最も一般的な理由、つまりコードベース内のオープンソースコンポーネントのインベントリの作成から始めましょう。 SBOM には、宣言されたオープンソースと宣言されていないオープンソースという 2 つのカテゴリのオープンソースが含まれている必要があります。
オープンソースの宣言
宣言されたオープンソースとは、マニフェストファイルで宣言され、パッケージマネージャー (たとえば、Java の場合は Maven、Node.js の場合は NPM) を使用して管理されるオープンソースを指します。 SBOM を作成する場合、オープンソースコンポーネントの依存関係に関するパッケージマネージャーの知見が、SBOM を信頼できる情報源として不可欠なものとします。使用する要素 (直接的な依存関係) とその依存関係 (推移的な依存関係) の両方が SBOM に存在する必要があります。どちらもセキュリティとライセンスコンプライアンスのリスクを引き起こす可能性が同等であるためです。市場の、すべてではないにしても、ほとんどのツールは、信頼できる情報源としてパッケージマネージャーを使用して、宣言されたオープンソースでSBOM を作成します。
未宣言のオープンソース
逆に、宣言されていないオープンソースとは、パッケージマネージャーを使用せずにコードベースに組み込まれるオープンソースを指します。宣言されていないオープンソースは、コードがどこでどのように使用されているかを知るためにコードに関するより深い知識 (またはより特殊なスキャンツール) が必要なため、SBOM で特定して追跡するのがより困難です。未宣言のオープンソースには、次のようなさまざまな形があります。
- カスタムアプリケーションで使用するためにフォークおよび変更されたオープンソースコンポーネント。
- GitHub リポジトリまたは Stack Overflow などのサイトからコピー＆ペーストしたファイルまたはコードスニペット。
- ファイルツリーにコピー＆ペーストされたオープンソースコンポーネントのバイナリリリース。
- GitHub Co-Pilot などの生成 AI ソリューションから自動生成されたコード。
宣言されていないオープンソースは、宣言されているオープンソースよりも大きなリスクを伴います。なぜなら、信頼できる情報源としてのパッケージマネージャーがなければ、ほとんどのツールは、特に変更されている場合、コンプライアンスチェックやセキュリティチェックを行うためにオープンソースを特定できないからです。コードベースに未宣言のオープンソースの目録がなければ、それらのコンポーネントに対して公開された新しい脆弱性や、その変更や配布を禁止するライセンス義務が見逃される可能性があります。手動で管理されたソフトウェアカタログを使用する場合でも、未宣言のオープンソースを検出できるスキャンツールを使用する場合でも、未宣言の要素は SBOM に含まれている必要があります。
宣言されたオープンソースと未宣言のオープンソース
商用ソフトウェア
これは SBOM の分野であまり話題になることはありませんが、同じくらい重要です。オープンソースソフトウェアと同様、商用ソフトウェアにもライセンス義務があり、セキュリティ上の脆弱性がある可能性があります。 SBOM から商用コンポーネントを除外すると、あなたや顧客は、それらのコンポーネントがもたらす潜在的なリスクに気づかなくなる可能性があります。 SBOM に商用コンポーネントを含めることで、あなたとその顧客は商用ライセンスの条項に準拠し、それらのコンポーネントで公開される可能性のある新しい脆弱性の存在を認識できるようになります。
SBOM の完全性が鍵です
米国の大統領令 10428 や EU のサイバー レジリエンス法 (CRA) などの規制基準により、民間企業は SBOM を採用する必要性が急速に高まっています。現在存在するこれらの基準のいずれかに準拠するには、組織がこの投稿で詳しく説明されているすべての情報を含める必要はないことに注意することが重要です。今日草案された基準は、データの完全性ではなく、SBOM の構造に焦点を当てています。大統領令 10428 を規定する米国商務省電気通信情報局(NTIA) によって定義された要件を満たす SBOM を設計および構築するのは論理的であるように思えるかもしれませんが、それは過去の間違いを繰り返すことになるでしょう。
より良いアプリケーションセキュリティの実践を促進するために 2004 年に導入されたペイメントカード業界データセキュリティ標準 (PCI DSS) に準拠するためにアプリケーションセキュリティへの取り組みを構築した多くのグローバルリーダーに何が起こったのかを考えてみましょう。多くの組織は、PCI_DSS を出発点として捉えるのではなく、最終目標として捉え、標準に基づいたプラクティスを構築しました。これにより、誤ったセキュリティ意識が生まれ、PCI 準拠を「認定」されている多くの組織が、セキュリティ悪用の被害者になっていることがわかりました。
現在の規制基準は、より良いソフトウェア開発の実践を促進するための優れた第一歩ですが、包括的なリスク管理の取り組みに取って代わるものではありません。
完全なSBOM には、上記で説明したすべてのコンポーネント (宣言されたオープンソース、宣言されていないオープンソース、および商用コンポーネント) が含まれている必要があります。完全な SBOM を構築することで、自分自身やソフトウェアを使用するすべての人に対するリスク管理が向上するだけでなく、ライセンスコンプライアンスとセキュリティ脆弱性リスクを定量化するために SBOM を利用する人々との信頼関係も構築されます。
FossID がアプリケーションの完全な SBOMの作成にどのように役立つかご質問やご興味がございますか？お問い合わせください。