近年のシステム開発においては、オープンソースソフトウェア（OSS）をはじめとするサードパーティ製のソフトウェアを活用することが一般的となっています。OSS活用によりシステム開発の利便性は高まった一方で、ソフトウェアサプライチェーンの巨大化により、システムに含まれるソフトウェアコンポーネントの管理が煩雑になる面もあります。そこで、ソフトウェアサプライチェーンにおけるセキュリティ対策として注目されているのがSBOM（Software Bill of Materials / ソフトウェア部品表）です。
クレジットカード業界の情報セキュリティ基準であるPCI DSS（Payment Card Industry Data Security Standard）では、v3.2.1からv4.0へのメジャーバージョンアップに際して、サードパーティコンポーネントを含めたソフトウェアのインベントリ作成が新たに要求されています。この変更も、ソフトウェアサプライチェーンに起因するセキュリティ事故の増加や、それに伴うSBOM普及の流れに影響を受けての要件追加と見ることができます。
この記事では、SBOM作成の目的や、PCI DSS準拠におけるソフトウェアコンポーネント管理のポイントを紹介していきます。
SBOMを巡る業界動向
近年、ソフトウェアサプライチェーン内の脆弱性を狙う攻撃は攻撃者にとってメジャーな手法となっています。
2021年にApache Log4jの脆弱性「Log4Shell」が世界的に話題になったことも記憶に新しいのではないでしょうか。直近では、2024年3月に複数のLinuxディストリビューションに含まれるファイル圧縮ツールであるXZ Utilsにバックドアが仕込まれる攻撃も観測されています。
情報処理推進機構（IPA）が発表した「情報セキュリティ10大脅威2024」（図1）においても、『サプライチェーンの弱点を悪用した脅威』、『脆弱性対策情報の公開に伴う悪用増加』が継続してランクインしており、サプライチェーン内で利用されるソフトウェアや、自社システムに含まれているソフトウェアの把握・管理が不十分な組織がサイバー攻撃を受けるリスクが高い状況が続いています。
| 順位 | 「組織」向け脅威 | 初選出年 | 10大脅威での取り扱い |
| 1 | ランサムウェアによる被害 | 2016年 | 9年連続9回目 |
| 2 | サプライチェーンの弱点を悪用した脅威 | 2019年 | 6年連続6回目 |
| 3 | 内部不正による情報漏えい等の被害 | 2016年 | 9年連続9回目 |
| 4 | 標的型攻撃による機密情報の窃取 | 2016年 | 9年連続9回目 |
| 5 | 修正プログラムの公開前を狙う攻撃(ゼロデイ攻撃) | 2022年 | 3年連続3回目 |
| 6 | 不注意による情報漏えい等の被害 | 2016年 | 6年連続7回目 |
| 7 | 脆弱性対策情報の公開に伴う悪用増加 | 2016年 | 4年連続7回目 |
| 8 | ビジネスメール詐欺による金銭被害 | 2018年 | 7年連続7回目 |
| 9 | テレワーク等のニューノーマルな働き方を狙った攻撃 | 2021年 | 4年連続4回目 |
| 10 | 犯罪のビジネス化(アンダーグラウンドサービス) | 2017年 | 2年連続2回目 |
図1：IPA 『情報セキュリティ10大脅威 2024 [組織編]』 より引用
こうした動きに伴い、国内外の政府機関やセキュリティ団体によるSBOM整備を推進する動きが活発になってきています。
2021年５月に発令されたアメリカ大統領令（EO14028）では、ソフトウェアサプライチェーンのセキュリティ強化を目的としてSBOMによるソフトウェア管理が要求され、民間企業におけるSBOM導入が推進されています。また、EU圏内でデジタル製品を販売する事業者を対象としたサイバーセキュリティ規定を定めたEUサイバーレジリエンス法でも、事業者に対してSBOMの作成が求められています。日本国内においても、2023年7月に経済産業省から「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」（2024年8月にVer2.0に改訂）が発行されており、国内外でSBOMの普及を推進する動きが広まっていることが分かります。
SBOM作成の目的とは
SBOMを作成する主な目的の一つは、システムに組み込まれたソフトウェアコンポーネントを厳密に把握・管理し、脆弱性管理を漏れ無く、効率的に実施可能な状態にすることと言えます。
例えば、システム開発に複数のOSSを組み込んでいる場合、SBOMの利用なしに全てのソフトウェアコンポーネントを把握・管理することは難しいでしょう。前章で例示した「Log4Shell」についても、Apache Log4jがシステム内で利用されているのか即座に判断できないことが混乱を招く一因となりました。
このように、OSSの脆弱性情報が公表されても、そのOSSがシステムに組み込まれているのか確認するのに時間を要してしまい、その間に脆弱性を突いたサイバー攻撃を受けるといったケースも十分考えられます。
SBOMをソフトウェア管理に活用することで、システムに組み込まれている全てのソフトウェアコンポーネントを的確に把握し、脆弱性対応の要否判定を漏れなく迅速に実施することができます。SBOMの作成に関しては、弊社の過去ブログ（セキュリティリスクを可視化するためのSBOM活用）においても紹介していますので、ぜひご一読ください。
PCI DSSにおけるソフトウェアコンポーネント管理のポイント
PCI DSS v4.0にて新たに追加された要件6.3.2では、『特注ソフトウェアおよびカスタムソフトウェア、並びに特注ソフトウェアおよびカスタムソフトウェアに組み込まれたサードパーティソフトウェアコンポーネントのインベントリを維持し、脆弱性およびパッチ管理を容易にする』ことが要求されており、『インベントリに特注・カスタムソフトウェアおよび第三者のソフトウェア部品が含まれていること』の確認が必要とされています。
「SBOMの作成」が明確に規定されてはいないものの、SBOMのようにOSSを含む全てのソフトウェアコンポーネントのインベントリ管理が要求されていると解釈できます。『脆弱性およびパッチ管理を容易にする』ことが求められることから、ソフトウェアコンポーネントのバージョン情報も併記することで、脆弱性を含むバージョンであるのかを一目で判断できる状態にしておくことも必要です。
また、SBOMはツールを利用することで効率的かつ正確に作成することが可能ですが、PCI DSSでは作成方法の指定まではされていないため、ツール等を用いずに手動でインベントリを作成することも許容されています。そのため、PCI DSSにおいてSBOM作成は必須ではなく、ソフトウェアコンポーネントのインベントリを作成するための一つの手段として捉えるのが適切でしょう。
以上の内容を踏まえて整理すると、PCI DSSで要求されるソフトウェアコンポーネントのインベントリには少なくとも次の要素を含む必要があると考えられます。
- 自社用に開発したソフトウェア（要件6.3.2の『カスタムソフトウェア』に該当）
- 他社へ開発を委託したソフトウェア（要件6.3.2の『特注ソフトウェア』に該当）
- 上記ソフトウェアを構成するサードパーティコンポーネント（OS、ミドルウェア、開発フレームワーク、ライブラリ、APIなど）
- 各種ソフトウェアコンポーネントのバージョン情報
本来はソフトウェアコンポーネント間の依存関係についても記載することが理想ですが、構成要素が少ない小規模システムの場合や、予算の関係でSBOMツール導入が難しい中小企業の場合などは、上記の要素をベースに、対象システムの構成やシステム運用などに合わせた形のインベントリを整備することが望ましいでしょう。また、サポート期限（EOS）の情報なども合わせて管理することで、ソフトウェアコンポーネントのライフサイクル管理などにも活用することができるインベントリとなります。（図2）
| ソフトウェア コンポーネント名 |
バージョン情報 | EOS情報 | |||
| 導入時期 | EOS時期 | (EOSが間近の場合は) 対応計画等 |
|||
| アプリケーションA | 1.5 | - | - | - | |
| ライブラリA | 2.3 | 2019/4/1 | 2026/3/31 | - | |
| ライブラリB | 1.9 | 2020/4/1 | 2026/3/31 | - | |
| フレームワークA | 3.2 | 2019/4/1 | 2025/3/31 | 2025年2月中にバージョンアップ予定 | |
| ミドルウェアA | 2.2 | 2019/4/1 | 2025/3/31 | 2025年2月中にバージョンアップ予定 | |
| OS A | 14.5 | 2018/4/1 | 2026/3/31 | - | |
| アプリケーションB | 2.5 | - | - | - | |
| ライブラリC | 1.6 | 2019/4/1 | 2026/3/31 | - | |
| ライブラリD | 2.1 | 2020/4/1 | 2026/3/31 | - | |
| フレームワークB | 2.3 | 2019/4/1 | 2027/3/31 | - | |
| ミドルウェアB | 1.3 | 2020/4/1 | 2025/3/31 | 2025年2月中にバージョンアップ予定 | |
| OS B | 23.1 | 2017/4/1 | 2025/3/31 | 2025年2月中にバージョンアップ予定 | |
| ・ ・ ・ |
・ ・ ・ |
・ ・ ・ |
・ ・ ・ |
・ ・ ・ |
|
図2：ソフトウェアコンポーネントのインベントリ作成例
また、無償提供されているSBOMツールを活用する方法も選択肢としては考えられます。有償のツールと比較して機能が限定的であったり、サポートが手薄であったりといった面もありますが、予算が限られている場合などには、検討の余地はありそうです。
さらに、要件では『インベントリを維持し、脆弱性およびパッチ管理を容易にする』ことが求められているため、インベントリを作成するだけでは意味がありません。作成したインベントリを脆弱性管理プロセスに組み込む必要があります。PCI DSSでは、既存要件にて脆弱性情報の収集・管理が求められており、収集した脆弱性情報に対して、パッチ適用の要否を検討する必要がありますが、その際にインベントリと突き合わせることで、脆弱性が発見されたソフトウェアがシステムに含まれているかを効率的に判断することが可能になります。インベントリを作成し、脆弱性管理プロセスにおいて活用することで、その効果は最大化されるでしょう。
もちろん、インベントリに全てのソフトウェアコンポーネントが網羅されていることが前提になりますので、委託先にて開発されたソフトウェアや、利用されているOSSも含めて漏れなく記載されていることが必要です。定期的にソフトウェアコンポーネントの棚卸しを行うなどして、インベントリを最新の状態に維持することも重要になります。
まとめ
現時点ではPCI DSSにおいてSBOM作成が明確に要求されていないため、本稿では簡易的な形式でのインベントリの作成例を紹介しました。しかし、冒頭で述べたように、世界的にSBOM導入の機運が高まってきていることもあり、近い将来にSBOM作成が要件となる可能性は十分に考えられます。
また、SBOMツールをソフトウェア管理に利用することで、手動での管理と比較するとより効率的にSBOM作成や脆弱性管理を実施できる面もあります。そういった状況も踏まえて、現段階からツールを活用したSBOM作成と、SBOMを用いた脆弱性管理の必要性を検討していくことが重要ではないでしょうか。
ユービーセキュアでは、PCI DSSをはじめとした各種セキュリティ基準等への準拠支援コンサルティングを提供しております。本稿で取り上げたソフトウェアコンポーネントの管理方法に関する対策などはもちろん、各種セキュリティ対策について気になる点やお困りごとがある際には、ぜひ一度ご相談ください。
