増え続けるサプライチェーンセキュリティリスク
Log4Shell脆弱性のように、多くのソフトウェアで使用されるOSSライブラリの脆弱性を侵害の切り口としてソフトウェアを狙う、サプライチェーンセキュリティ攻撃のリスクが世界的に高まっています。IPAが発表した「情報セキュリティ10大脅威 2023」（※1）では、「サプライチェーンの弱点を悪用した攻撃」が2位にランクインし、NIST（アメリカ国立標準技術研究所）が公表する脆弱性の量は2016年から2022年まで単調増加の一途を辿ります（※2）。
高まるサプライチェーンセキュリティリスクに対処するため、国内外でSBOMを脆弱性対応に活用するための普及展開が官民で進められています。米国では2021年5月のサイバーセキュリティ強化のための大統領令を受け、NIST等でSBOMを活用するためのガイドライン等の整備が進められています（※3）。一方、日本でも経済産業省が主体となり、産業分野毎に導入を見据えた実証実験を進めており（※4）、早ければ2024年にもSBOM提出義務化の可能性があります（※5）。
こうした状況を踏まえ、ソフトウェア開発者やシステムサプライヤは、SBOMを適切に生成・管理・脆弱性対応に活用するための体制づくりが求められています。
https://www.nikkei.com/article/DGXZQOUA0314J0T00C23A1000000/
SBOM（Software Bill of Materials）とは
SBOMとは、図1に示すように、ソフトウェアが含んでいるライブラリやモジュールを一覧化した構成情報を指します。SBOMを特徴づけるポイントとして、あるライブラリが依存する別のライブラリについても記述できる点にあります。今日の多くのソフトウェアは、コンポーネントが階層的に複数のコンポーネントを含み、深い層のコンポーネントが上位の層から見えづらくなっていることが一般的です。それらの複雑な依存関係を可視化し、脆弱性を持つライブラリや、改ざんされたライブラリがパッケージに含まれていないかを検査することが可能になります。
図1：SBOMの構成内容イメージと実際のSBOMデータ例（※6）
図2に示すように、一般的にSBOMはSCA（Software Composition Analysis）に分類される解析ツールを用いて生成します。コーディング段階で独自のソースコードに存在する脆弱性はSAST（Static Application Security Testing）で特定することが一般的ですが、これではサードパーティやOSSのライブラリに存在する脆弱性が特定できません。そこで、SCAツールでSBOMを生成することにより、ライブラリが持つ脆弱性を明らかにします。この点で、SASTとSCAはセキュリティテストにおいて相互に補完的な役割を備えていると言えます。
図2：アプリケーション開発フローにおけるSBOMの生成タイミング
現在、SBOMは複数の団体が独自フォーマット（※7）を提案し、仕様の策定やツールへの組込み等の標準化をけん引しています。SBOMは黎明期のため、現時点で完璧と言えるメソドロジはありません。自社の属する産業分野やサプライチェーンにおいて主流となりそうなSBOMフォーマットを調査し、段階的にSBOM管理の要件定義やツールの導入、脆弱性モニタリングと対応のための体制やプロセスの構築を行うことが望ましいでしょう。
https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf
CycloneDX: OWASP（Open Web Application Security Project）が策定を主導するプロジェクト
https://cyclonedx.org/
SPDX: Linux Foundationの傘下のプロジェクト
https://spdx.dev/
SBOM活用に求められる主な要件
先に述べた通り、SBOMは単なるソフトウェアの構成情報に過ぎないため、SBOMを生成して脆弱性対応が完了、とはなりません。SBOMが真価を発揮し、内包する脆弱性の特定と対応に活用するためには、図3と下記に示す機能が要件となります。
（1）継続的にSBOMを生成し、管理できる環境にインポートできること
サプライチェーン上で求められるフォーマットのSBOMを生成し、管理環境に取得します。一般的なSCAツールは、CI/CDツールと連携してソフトウェアの変更時に自動でスキャンする機能を持ちます。これらのツールを併用することで、DevSecOpsの実現にも寄与します。
（2）インポートしたSBOMに対して脆弱性情報をマッピングし、モニタリングできること
商用SCAツールではコンポーネントのスキャン時に脆弱性の特定機能を備えますが、無償のSCAツールでは構成情報のみの出力となるケースがあります。外部データベースから脆弱性情報を取得し、コンポーネントに対して脆弱性の有無を検査する必要があります。
（3）検知した脆弱性について、開発現場に早急に通知できること
ソフトウェアが脆弱性を持つコンポーネントを含む場合、早急に開発現場へ通知する必要があります。この際、ライブラリのバージョンをいくつまで上げれば影響を受けなくなるか、といった緩和策の情報が同時に提供されれば、開発現場は迅速な対応が可能になります。
（4）SBOMや脆弱性対応状況をレポーティングできること
開発現場のルールやお客様からの要求により、任意のタイミングでSBOMや脆弱性対応状況のレポーティングが求められます。サプライチェーン上のステークホルダへのSBOM提出が法令化されることを見越して、納品のためのエクスポート機能が求められるでしょう。
上に挙げた要件は、SBOMに基づき効果的に脆弱性対応を行うための一例です。開発現場によってはマニュアル対応したり、外部のリソースに頼ったりする部分もあると思います。また、SCAツールだけでなく、SASTやDASTといったセキュリティスキャナの実行結果を統合管理することで、情報のサイロ化を防ぎ、より効率的な脆弱性対応が見込めます。
図3：SBOMデータから脆弱性を特定・対応するための要件
脆弱性統合管理の実践
SBOMを取り巻く技術には、商用ソリューションだけでなくOWASP Dependency-Track（※8）やOWASP DefectDojo（※9）等、セキュリティコミュニティに支えられている有用なOSSツールが多く存在します。これらを利用することで、前述のSBOM活用に必要な機能の実現が可能です。
将来的にSBOM導入をお考えの方は、SBOM管理の手順理解や、現在のソフトウェア開発ツール・プロセスに対する適合のノウハウを、調査活動や実証実験を通じて蓄積されることを強くお勧めします。
NTTデータでは、きたるSBOM活用必須化の未来を予測し、社内開発プロジェクトに存在する脆弱性対応のセキュリティガバナンスとして、SBOMの効果的な運用方法を検証しています。また、サイバーセキュリティに先進的な海外企業と連携して、SBOM管理のPoC（概念実証）に取り組んでいます。図4のようにSBOM統合管理プラットフォームを開発し、SBOMをどのように運用すべきか、ベストプラクティスの確立を進めています。将来的に、お客様のSBOM管理を含む、サプライチェーンセキュリティの包括的な保護サービスの提供に向けて準備をしています。
図4：OWASP DefectDojoとSCAツールを組み合わせた脆弱性管理の例
おわりに
広範に使われるOSSライブラリやIT運用管理ソリューションの侵害事例が増えていることから、高まるサプライチェーンセキュリティリスクへの対策が急務です。解決策として注目を集めるSBOMですが、効果的に運用するためには、SBOM活用のための方法論を確立し、従来のソフトウェア開発プロセスに統合する必要性があります。今回ご紹介したSBOM導入時の要件や、DevSecOpsを実現する（※10）ことが、サプライチェーンセキュリティの強靭化に繋がります。
今回の記事が、SBOM導入を検討されているソフトウェア開発者やセキュリティ担当者の皆様の一助となれば幸いです。
