SBOM（ソフトウェア部品表）とは、特定のソフトウェア製品を構成するコンポーネントや依存関係のリストのことです。 これには、ソフトウェアを構築するために必要なすべてのライブラリ、モジュール、フレームワーク、その他の外部リソース、およびそれら間の関係が含まれています。 要するに、SBOMはソフトウェアシステムのデジタルサプライチェーンを表すものです。 そして現在、連邦政府にソフトウェアを販売するすべてのベンダーに対して、これが義務付けられています。 ソフトウェアを開発・運用するその他の皆様も、その恩恵を受けることができます。
SBOMは10年以上にわたりオープンソースコミュニティの一部として存在してきましたが、 2020 年および2021年に米国企業や政府機関を標的としたソフトウェアサプライチェーン攻撃が相次いだことを受け、サイバーセキュリティ界隈でさらに注目を集めるようになりました。
特に、 SolarWindsハッキング事件 —— 国土安全保障省や財務省を含む連邦政府機関が、知らず知らずのうちにトロイの木馬化されたコンポーネントを導入し、その結果、攻撃者が被害者のコンピュータシステムにアクセスできるようになってしまった件 —— を契機として、 大統領令 が 2021年5月 で発令され、連邦政府にソフトウェアを販売するすべてのベンダーに対し、SBOMを用いてそのコンポーネントの詳細を明示することが義務付けられました。
ソフトウェアのサプライチェーンは複雑であるため、たった1つのソフトウェアコンポーネントが、そのセキュリティに甚大な影響を及ぼす可能性があります。 しかし、ユーザーは、ビジネス上最も重要なアプリケーションに組み込まれているコンポーネントについて、ほとんど把握できていません。 製品の「構成要素」の一覧を用意しておくことで、セキュリティリスクをより的確に把握できるようになり、危機に発展する前に脆弱性を特定するための指針となります。
SBOMの起源は何でしょうか？
SBOMへの新たな重点化は、バイデン大統領が署名した「 」大統領令（EO） 14028号『国家のサイバーセキュリティの向上について』（ ）に端を発するものです。この大統領令は、連邦政府のネットワークをより適切に保護するため、米国国立標準技術研究所（NIST）およびその他の連邦機関に対し、ソフトウェアサプライチェーンのセキュリティと完全性に関連する様々な取り組み を通じて、サイバーセキュリティの強化を図ることを求めています。
この大統領令は、主に 2020 年および’21年に米国企業や米国政府を標的としたサイバー攻撃が急増したことへの対応として発令されたものです。 この期間中の攻撃は頻度も高まり、その深刻度も増しました。中でも特に甚大な被害をもたらした2件の攻撃――SolarWindsへの攻撃と、 のコロニアル・パイプラインに対するランサムウェア攻撃（）――が、この大統領令の発令につながりました。
SolarWindsへの攻撃では、テキサス州に拠点を置く同社の「Orion」ソフトウェア（ITネットワークやインフラの監視・管理に使用される）に含まれる、トロイの木馬化された単一のコンポーネントにより、ハッカーは を通じて、フォーチュン 500 企業、複数の連邦政府機関、さらには最終的にこの侵害を検知した米国のサイバーセキュリティ企業を含む、数千の組織のシステム にアクセスすることが可能となりました。 最大 18,000人の の民間および公共部門の被害者が、感染したソフトウェアをダウンロードしましたが、その後、実際に被害に遭ったのはそのうちの少数にとどまりました。
コロニアル・パイプライン社に対するランサムウェア攻撃は、単一の組織を標的としたものでしたが、米国のインフラに広範囲にわたる影響を及ぼしました。 東海岸の燃料供給量の約 45 パーセントを担う同社が、この攻撃を発見した際、脅威を封じ込めるために重要なコンピュータシステムをオフラインにせざるを得なくなり、事実上、操業を停止することとなりました。 その結果生じた燃料不足により、パニック買いが相次ぎ、ガソリン価格が急騰しました。
[関連記事：バイデン大統領の大統領令がテクノロジー企業の経営陣に与える影響とは]
この大統領令は、これらおよびその他のセキュリティインシデントから得られた教訓を反映したものであり、ますます巧妙化するサイバー攻撃の被害を軽減するため、官民の連携を促進することを目的としています。 具体的には、いくつかの目標が示されています：
- 情報共有の強化 —この大統領令は、政府と民間部門間の脅威情報の共有を妨げる契約上の障壁をすべて取り除くよう指示するとともに、ITサービスプロバイダーに対し、連邦政府に影響を及ぼす可能性のある脅威、脆弱性、およびインシデントに関する情報を共有することを義務付けています。
- 政府のサイバーセキュリティの近代化――この大統領令は、連邦政府に対し、より強力なサイバーセキュリティ基準とベストプラクティスを導入するよう求めています。 これには、安全な クラウドサービスの導入、 ゼロトラスト セキュリティモデルの採用、および多要素認証（MFA） と暗号化ルーチンの実装が含まれます。
- ソフトウェアのサプライチェーンのセキュリティを強化――政府は、請負業者から調達するソフトウェアについて、ソフトウェア開発のセキュリティに関する基本基準を策定する予定です。 商務省および米国電気通信情報局（NTIA）は、ソフトウェア製品を構成する個々のコンポーネントを列挙し、詳細を記載した「ソフトウェア部品表」の構成要素を公表しなければなりません。
- サイバーセキュリティ安全審査委員会の設置 —政府は、 委員会 を設置します。この委員会は、政府および民間部門の専門家が共同議長を務め、重大なサイバーセキュリティインシデントが発生した際に招集され、事態の分析およびセキュリティ改善に向けた提言を行うものです。
[関連記事：サプライチェーンを強化するための米国政府の戦略]
- インシデント対応プレイブックを作成する――政府のIT責任者は、すべての連邦機関がサイバー攻撃に効果的に対応し、その被害を修復できるよう、セキュリティインシデントへの対応に関する 標準プレイブック を策定する必要があります。
- インシデントの検知能力の向上 —この大統領令では、サイバーセキュリティインシデントの検知能力を向上させるため、政府全体で「 」エンドポイント検知・対応（EDR） システムを導入すること、および連邦政府内での情報共有を改善することが求められています。
- 調査と是正措置の強化 —政府は、連邦政府ネットワークにおけるサイバーセキュリティインシデントの調査と是正措置を強化するため、すべての連邦機関を対象としたサイバーセキュリティイベントログの要件を策定する予定です。
この大統領令では、いくつかの政府機関が達成すべき当面の目標が示されましたが、連邦政府の調達サプライチェーン全体に波及効果をもたらしています。 具体的には、この大統領令は以下の3つのグループに影響を及ぼします：
- 連邦行政機関――政府の最高レベルの機関は、自機関の技術環境とセキュリティ対策の近代化を推進する責務を負っています。
- 連邦政府の契約業者―― 米国政府と取引を行う契約業者（市販ソフトウェア（COTS）プロバイダーを含む）は、契約条件に新たなサイバーセキュリティ基準が盛り込まれることが予想されます。 また、サイバーインシデントに関する情報をより多く共有することが求められています。
- 民間企業――民間企業は、新たなサイバーセキュリティ関連法規制の対象となり、既存の法律や方針の執行も強化される見込みです。特に、 ソフトウェアのサプライチェーンのセキュリティ および サイバーインシデントの報告 への注目が高まっています。 また、ソフトウェアやモノのインターネット（IoT）デバイスに対する消費者向けセキュリティ表示の導入が提案されており、透明性の確保がより重視されるようになっています。その結果、これらのプロバイダーに対しては、新たなセキュリティ要件や評価基準が設けられることとなりました。
なぜ、今日、SBOMは重要なのでしょうか？
SBOMは、組織が自社のソフトウェアやその依存関係に存在する可能性のある脆弱性を特定し、修正するのに役立つため、重要です。 現代のアプリケーションは、物理的な製品を製造するメーカーが利用するものと同様に複雑な、ソフトウェアコンポーネントのサプライチェーンを活用して開発されています。 一般的なアプリは、独自開発のコードと再利用可能なサードパーティ製コンポーネントを組み合わせて、数十のコンポーネントから構成されています。 開発者は、自分が書いたコードについてはエラーやミスがないか精査することができますが、サードパーティのコードについては、その内容を把握しづらいものです。 攻撃者はこの点を理解し、悪用して、検出を免れる可能性が高いことを承知の上で、サードパーティ製コンポーネントを標的にしています。
「脆弱性が発見または公表された際、SBOMを活用することで、組織内でそのソフトウェアのバージョンがどこで使用されているかを特定するのに役立ちます。」
今や悪名高いSolarWinds事件に加え、ここ数年で相次いだサプライチェーン攻撃は、このような事態がもたらす壊滅的な影響を浮き彫りにしました。 攻撃者は、オープンソースのApache Log4j ソフトウェアに存在する重大な脆弱性を悪用しました。このソフトウェアは、数百万ものJavaベースのアプリケーションにおける活動を記録する、ほぼあらゆる場所で利用されているロギングライブラリです。 また、ハッカーたちは、Microsoft Exchange Server に存在する 4 つの別々の「 」ゼロデイ脆弱性（ ）を悪用し、米国の 30,000 組織のネットワークへのアクセス権を取得しました。
SBOMを活用することで、企業はこうしたサプライチェーン攻撃に対する防御を強化し、リスク管理の優先順位付けを行うことができます。 例えば、SBOMを活用して、まず既知の脆弱性があるライブラリの使用を排除し、次に各オープンソースライブラリの最新版が使用されていることを確認することができます。 脆弱性が発見または公表された際、SBOMを活用することで、組織内でそのソフトウェアのどのバージョンが使用されているかを特定するのに役立ちます。 より一般的に言えば、SBOMを活用することで、組織は使用するソフトウェアについて、より十分な情報に基づいた意思決定を行うことが可能となり、またソフトウェアプロバイダーがより安全な製品を開発するよう促すことができます。
SBOMにはどのような構成要素がありますか？
2021年7月において、NTIAは「ソフトウェア部品表（SBOM）の必須要素」を発表し、連邦政府の におけるSBOMに関する要件 の概要を示しました。 SBOMのベースライン構成要素を、データフィールド、自動化サポート、および実践・プロセスの3つのカテゴリーに分類します。 それでは、それぞれについて詳しく見ていきましょう。
データフィールド
データフィールドは、各コンポーネントを確実に識別できるものでなければなりません。これにより、ソフトウェアサプライチェーン全体を通じてコンポーネントを監視し、脆弱性データベースやライセンスデータベースと照合することが可能になります。 NTIAは、7つのデータフィールドを規定しています：
- サプライヤー名： コンポーネントを作成および識別する組織の名前です。
- コンポーネント名： ソフトウェアユニットに、元の供給元が付与した名称です。
- コンポーネントのバージョン： ソフトウェア製品で使用されているコンポーネントのビルドおよびバージョンの詳細です。
- その他の一意の識別子： 検索キーや、 NISTのCPE辞書 に記載されている識別子など、コンポーネントを特定するために使用できるその他の情報。
- 依存関係： コンポーネントと他のソフトウェアとの間の依存関係に関する説明です。 例えば、コンポーネントAはソフトウェアBに含まれています。
- SBOMデータの作成者： コンポーネントのSBOMデータを作成した組織名です。
- タイムスタンプ： SBOMデータが作成された日時です。
自動化のサポート
セキュリティ担当者がすべてのSBOMにおいて、侵害されたコンポーネントを手作業で検索することは現実的ではないため、NTIAは、すべてのSBOMが以下の3つの機械可読形式のいずれかを通じて自動化に対応することを義務付けています：
- サイクロンDX
- ソフトウェアパッケージデータ交換（SPDX）
- ソフトウェア識別（SWID）タグ
[Read also: Here’s your security automation playbook for 2023]
実践手法とプロセス
実践手法とプロセスにより、ソフトウェア製品のライフサイクル全体を通じて、SBOM文書の正確性が確保されます。 NTIAは、取り組むべきいくつかの最低限の要素を概説しており、その中には以下が含まれます：
- 頻度： ソフトウェアコンポーネントが新しいビルドまたはリリースで更新されるたびに、そのソフトウェアの新しいバージョンを反映した新しいSBOMを生成する必要があります。 これには、更新されたコンポーネントや依存関係を統合するためのソフトウェアのビルドが含まれます。 同様に、サプライヤーが既存のSBOMデータ内の誤りを訂正したり、情報を更新したりしたい場合は、改訂版の新しいSBOMを発行する必要があります。
- 詳細： SBOMには、すべてのトップレベルコンポーネントを含め、それらの依存関係を一覧表示する必要があります。
- 「既知の未知」： 開発者は、あるコンポーネントに関する依存関係のすべてを把握していないことに気づくことがあります。 このような場合、SBOMでは、データが不完全であることを明記し、どのような関連性が考えられるかを説明する必要があります。
[関連記事：既知の未知については評価済みですか？ 素晴らしいことですが、そこで止まってはいけません――リーダーにとっては、「未知の未知」についても想定しておくことが重要なのです]
- 配布と提供： SBOMは、それを必要とする者が、適切なアクセス権限と役割を有している場合に、適時に利用できるようにする必要があります。
- アクセス制御： SBOMデータを非公開にしたい組織は、ユーザーがSBOMデータを自社のセキュリティツールに統合するための許容範囲や配慮事項を含め、利用条件を明記する必要があります。
- 誤りの許容： SBOMデータの管理は、現在も発展途上にある取り組みであるため、ユーザーは偶発的な誤りに対して寛容であるべきです。 サプライヤーは、過去のSBOMにおいて問題が特定された場合、最新のデータを提供すべきであり、ユーザーは、継続的な改善を促進するため、ペナルティを課すことなく、こうした更新や修正を受け入れるべきです。
SBOMの要件は、今後も拡大・進化し続けるものと見られます。 ガイドラインの更新に伴い、データフィールドの追加や、セキュリティスコア、脆弱性リスト、その他の情報の追加が行われる可能性があります。 組織にはSBOMの最低要件を満たすことのみが義務付けられていますが、ソフトウェア製品に関する追加の関連情報を盛り込むことで、透明性とセキュリティに対する強い取り組み姿勢を示すことができます。
SBOMの開発ライフサイクルとは何でしょうか？
理想的には、ソフトウェアがデプロイされるたびにSBOMが自動的に生成され、可能な限り完全な構成リストが含まれるべきです。 SBOMのライフサイクルは、アプリケーションを特定し、SBOMを作成し、それらをエンドユーザーに提供するためのプロセスを提供することで、これを促進します。
「ソフトウェアがデプロイされるたびにSBOMを自動的に生成し、可能な限り完全な構成情報を含めるべきです。」
これは、以下の5つの段階から構成されています：
- アセットの検出 —最初の段階は、SBOMを提供する必要があるアプリケーションを見つけることです。 すべてのアプリを完全に把握するためには、 のアセット検出ツール（ ）をご利用いただくことをお勧めします。
- アプリケーションデータの分析 —SBOMに必要なアプリケーションデータが収集されます。
- SBOMの作成 —関連するすべてのアプリケーションデータを含むSBOMファイルが作成されます。 アプリの新しいリリースのたびに、SBOMが常にソフトウェアの最新の状態と一致するように、この作業を行う必要があります。
- SBOMの保管 —SBOMは、暗号化を用いて一元的かつ安全に保管する必要があります。
- SBOMの検索機能 —最終段階では、エンドユーザーが潜在的な脆弱性を検索できるよう、SBOMの検索機能を確保します。
どのようなSBOM規格があるのでしょうか？
SBOM規格とは、ソフトウェアの構成を詳細に記述するためのスキーマであり、脆弱性スキャナーやソフトウェアライセンス管理ツールなどの他のツールで利用可能な、機械可読形式のファイルとして提供されます。 現在、SBOMを生成し、エンドユーザーと共有するための主な標準は3つあります：
- SPDX—Linux Foundationによって開発されたSPDX（Software Package Data Exchange）規格は、アプリケーションの構成要素、ライセンス、著作権、セキュリティ情報などのSBOMデータを、複数のファイル形式でやり取りするための、広く採用されているフォーマットです。
- CycloneDX—CycloneDXは、OWASPコミュニティによって開発されたもう一つのオープンスタンダードです。 SPDX規格に基づいていますが、実装や利用が容易になるよう簡素化されています
- SWID—SWID（Software Identification Tags の略）は、ソフトウェアの構成要素を記述し、その文脈を明確にするために、多くのアプリケーションによって自動的に生成されるメタデータの一種です。
NTIAは、これら3つのSBOM規格を適格なものとして選定しました。その理由は、これらの規格が人間が読み取れるだけでなく、機械でも読み取ることができ、自動化を支援することで、エンドユーザーがSBOMを組織全体でより容易に利用・展開できるようになるためです。
SBOMの作成と活用には、どのような課題がありますか？
他の新しいシステムと同様、SBOMの作成や活用には、いくつかの課題が伴います。
主な障害は、標準化が進んでいないことです。 SBOMは、サプライチェーン全体が同じ基準、プロセス、およびツールを遵守している場合に、最も効果を発揮すると思われます。 しかし、現段階では、これらのいずれについても合意はほとんど見られず、ソフトウェアベンダーやエンドユーザー間で統一性が欠けることは避けられません。 その結果、SBOMを詳細に分析し、注文に合わせて調整するのに余分な時間がかかってしまう可能性があります。
「」サプライチェーン全体が同じ基準、プロセス、ツールを遵守している場合、SBOMは最も効果を発揮するでしょう。 しかし、現段階では、これらのいずれについても合意はほとんど見られません。”
もう一つの課題は、SBOMを継続的に更新していく必要があるという点です。 アプリが新しくリリースされるたびに、そのアプリの現在の状態を反映した新しいSBOMを含める必要があります。 そのため、SBOMの生成をソフトウェア開発ライフサイクルに組み込むことができるSBOM管理ツールを導入することが極めて重要となります。
スプレッドシートや電子メールなど、従来の方法でSBOMを作成している場合、サプライチェーンパートナーが増えるにつれてSBOMの規模を拡大していくことも課題となり得ます。 さらに、こうした手作業による方法は時間がかかり、ミスが生じやすく、コンポーネント間の階層関係を把握しにくくなる可能性があります。
効果的なSBOMを作成するためのベストプラクティスにはどのようなものがありますか？
以下のベストプラクティスを参考にすれば、効果的なSBOMを作成するのに役立ちます：
- 一貫した形式を使用してください――。SBOMデータの構成においては、標準的な形式に従うことが重要です。 SPDX、CycloneDX、SWIDが最も一般的ですが、結局のところ、どの形式を選ぶかよりも、一貫して使用することが重要です。
- SBOMの作成を自動化—ソフトウェアデリバリーパイプラインの一環としてSBOMを自動的に生成することには、いくつかのメリットがあります。 何よりも、開発者がSBOMを一つひとつ手作業で作成する必要がなくなるため、時間を節約できます。 また、これにより、SBOMがソフトウェアのデリバリーサイクルにおいて恒常的な要素となる可能性が高まります。 最後に、これにより、連邦政府へのITサービス提供に関して、バイデン大統領令で定められた要件を満たすことが可能となります。
- リリースごとにSBOMを更新してください —SBOMは、アプリケーションが更新される場合を含め、各ソフトウェアリリースごとに個別のものとする必要があります。 ここでの鍵となるのは自動化です。開発者がアプリの更新のたびにSBOMを手作業で更新しなければならない場合、それが実際に行われる可能性ははるかに低くなります。
- 完全なメタデータを含めること —統一されたSBOM規格は存在しませんが、各SBOMには可能な限り多くのメタデータを含めるよう心がけるべきです。 これにより、エンドユーザーが手動で確認しなければならない情報の量が減り、セキュリティと透明性に対する貴社の取り組みを示すことができます。 また、更新も簡単になります。
