{{item.videoDuration}}
{{item.title}}
{{item.text}}
{{item.videoDuration}}
{{item.text}}
ソフトウェアサプライチェーンリスクの顕在化事例とSBOMによる解決
2022-04-20
はじめに
本稿はSBOMが求められている背景と期待される効果および活用事例について解説する連載の第2回です。第1回では上流で発生した事象が下流全体に影響を及ぼすというソフトウェアサプライチェーンの構造的な課題と、その解決策としてソフトウェア部品表（SBOM：Software Bill of Material、「エスボム」と発音）の普及が本格化していることを解説しました。第2回の今回はソフトウェアサプライチェーンリスクが顕在化した主な事例を取り上げ、SBOMによってどのような解決が可能か考察します。
SBOMの欠如にはどのような問題があるのか
SBOMがソフトウェアサプライチェーンに提供する価値は透明性（Transparency）、完全性（Integrity）および識別性（Identity）だと言われています1。
- 透明性：ソフトウェアを構成する部品の一覧情報に基づいてライセンスや脆弱性に係るリスクを正確に評価することが可能
- 完全性：ハッシュ値に基づいてソフトウェアの改ざん有無を検証することが可能
- 識別性：ソフトウェアIDを用いてより正確にソフトウェアを特定することが可能
裏を返すと、SBOMがない場合、透明性、完全性、および識別性に以下のような問題が生じるということです。
- 透明性の問題：含まれているソフトウェア部品の一覧情報がないため、脆弱性の影響有無や適用されるライセンスを正確に把握できない
- 完全性の問題：不正コードやマルウェアの混入を検知することができない
- 識別性の問題：共通脆弱性識別子（CVE）2が作成されると、影響を受けるソフトウェアの共通プラットフォーム一覧（CPE）3が提供されるが、自身が利用するソフトウェアとの対応を正確に特定することができない
図表1はエンドユーザーから見たソフトウェアサプライチェーンのイメージ図です。SBOMが提供されていない場合、背景がグレーの領域に含まれるソフトウェア部品の情報を正確に把握することは困難です。
ソフトウェアサプライチェーンリスクが顕在化した事例とSBOMによる解決策
ここでは、上述した3つの問題について具体例を挙げ、SBOMによってどのような解決が可能か考察します。
①透明性の問題：オープンソースソフトウェアのライセンス違反
オープンソースソフトウェア（OSS）は、ソースコードの改変や再配布、著作権表示等について定められたライセンスに準拠することで使用可能なソフトウェアです。ソフトウェア部品を使用している場合もそれぞれのライセンスに従う必要があります。しかし、ライセンス管理においても、脆弱性管理と同様、影響を受けるライセンスを抜け漏れなく特定するのは容易ではないという課題があります。ライセンスに違反した場合、利用組織はソフトウェアの販売差し止めや罰金の支払いに加え、レピュテーションの棄損など、大きな影響を受ける可能性があります。
ライセンス違反による起訴として、2010年に家電メーカーら14社が起訴された事例4や2013年にメディアプレイヤーメーカーが起訴された事例5があります。特に後者の判決では、ソフトウェアサプライヤーのコンプライアンス準拠に依存するのは過失であり、自組織の責任でサードパーティの権利を侵害していないことを確認する必要があることが明言されています。つまり、OSSをソフトウェア部品として利用するユーザーは、自組織の責任で適用されるライセンスを確認し準拠する必要があるということです。
SBOMデータにはライセンス情報を含めることが推奨されており、適用されるライセンスを抜け漏れなく把握することで、適切なライセンス管理が可能になることが期待されています。
②完全性の問題：外部実行スクリプトの改ざん
2021年4月、コードカバレッジツール6を提供するCodecov社が顧客に提供しているツールBash Uploaderのスクリプトが改ざんされていたことが明らかになりました7。このツールは顧客のカバレッジデータをCodecov社に送信するツールですが、改ざんにより攻撃者にもデータが送信されるようになっていました。攻撃者はこのようにして窃取したデータを悪用し、日本企業を含む複数の顧客企業に対して不正アクセスを行っていました。
この攻撃は、ツールのハッシュ値をSBOMデータに含めることでユーザー側での改ざん検知が可能になると考えられます。実際に、Bash Uploaderの改ざんはCodecov社が提供するハッシュ値ベースの検証ツールを使用した顧客からの報告で発覚しました。SBOMはこのような検証をソフトウェアサプライチェーン全体で標準化するための仕組みだと言えます。
③識別性の問題：ソフトウェア部品の脆弱性
2014年9月、Linux系OSで広く利用されているシェルであるBashでリモートから任意のコード実行が可能になる脆弱性ShellShock（CVE-2014-6271およびCVE-2014-7169）が発見されました。この脆弱性は、Webサーバー上で動作するCGIプログラムやLinuxベースの組み込みシステムなど非常に広範囲にわたって影響を与えるものでした8。ShellShockは2014年に確認された古い脆弱性であるにもかかわらず、米国土安全保障省のサイバーセキュリティ・インフラセキュリティ庁（CISA）が公開している「Known Exploited Vulnerabilities Catalog」9にも含まれています。
2021年12月には、広く利用されているJavaのログ記録ライブラリApache Log4jでリモートから任意のコード実行が可能になる脆弱性Log4Shell（CVE-2021-44228）10を悪用するエクスプロイト（攻撃コード）が公開されました。Log4Shellは、脆弱性情報が公開された直後からさまざまなマルウェア11や国家支援型サイバー攻撃グループによって悪用されていること12が報告されています。2022年3月時点でも悪用を示唆する報告13が続いています。
BashやLog4jのようにソフトウェア部品として利用されているソフトウェアの脆弱性対応には、本連載の第1回で解説したように影響有無の確認が困難という課題があります。しかし、SBOMデータには階層を掘り下げながらソフトウェア部品を特定する情報が含まれるため、脆弱性を持つソフトウェア部品の利用有無を網羅的に確認することができます。
ソフトウェアサプライチェーン攻撃に対するSBOMの効果と限界
ソフトウェアサプライチェーンリスクの中で組織への影響が大きいのは、やはりソフトウェアサプライチェーン攻撃です。SBOMはソフトウェアサプライチェーン攻撃への対策として話題に上がることが多いですが、一口にソフトウェアサプライチェーン攻撃と言っても侵害の対象はさまざまであり、SBOMが有効なものとそうでないものがあります。図表2はソフトウェアサプライチェーン攻撃における侵害の対象とSBOMの効果をまとめたものです。SBOMはある時点のスナップショットのようなデータであるため、侵害発生後に正規プロセスを通してSBOMが生成された場合、攻撃を検知することは困難であることが分かるでしょう。
ソフトウェアサプライチェーン攻撃対策としてSBOMを導入する際は、パッチ管理や脆弱性スキャンのような既存のセキュリティ対策を効率化あるいは強化するものであることを理解し、その効果と限界を把握した上で活用することが重要です。
おわりに
本稿ではSBOMの欠如により発生する問題を透明性、完全性、および識別性の観点で分類し、それぞれ具体的な事例を挙げてSBOMによる解決策を解説しました。続いて、ソフトウェアサプライチェーン攻撃のタイプ別にSBOMの効果を整理しました。SBOMは決してソフトウェアサプライチェーン攻撃に対する万能薬ではありません。何ができて何ができないのかを正しく理解した上で導入することが重要です。また、SBOMは導入して終わりではなく、実際の業務で活用して初めてその価値を発揮するものです。本稿で取り上げた事例を参考に、ライセンス管理や脆弱性対応業務への適用を検討していただきたいと思います。
本連載の第1回および第2回ではSBOMに関する一般的なトピックについて解説しました。次回以降はPSIRT14やCSIRT15におけるSBOMの活用がテーマとなります。より具体的で実践的な内容になりますのでご期待ください。
1 Microsoft, 2021, 「Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft」
https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/
2 情報処理推進機構（IPA）, 2015, 「共通脆弱性識別子CVE概説」
https://www.ipa.go.jp/security/vuln/CVE.html
3 情報処理推進機構（IPA）, 2018, 「共通プラットフォーム一覧CPE概説」
https://www.ipa.go.jp/security/vuln/CPE.html
4 Software Freedom Conservancy, 2010, 「Conservancy Receives Default Judgment For BusyBox GPL Enforcement」
https://sfconservancy.org/news/2010/aug/03/busybox-gpl/
5 Free Software Foundation Europe, 2013, 「FSFE compliance workshop discovers GPL violation by FANTEC, Welte wins in court」
https://fsfe.org/news/2013/news-20130626-01.en.html
6 ソースコードのテスト範囲を測定するツール
7 Codecov, 2021, 「Bash Uploader Security Update」
https://about.codecov.io/security-update/
8 日本シーサート協議会, 2014, 「GNU bashの脆弱性 ～shellshock問題～ について」
https://www.nca.gr.jp/2014/shellshock/index.html
9 Cybersecurity & Infrastructure Security Agency, 「KNOWN EXPLOITED VULNERABILITIES CATALOG」
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
10 JPCERT/CC, 2021, 「Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起」
https://www.jpcert.or.jp/at/2021/at210050.html
11 Bleeping Computer, 2021, 「Hackers start pushing malware in worldwide Log4Shell attacks」
https://www.bleepingcomputer.com/news/security/hackers-start-pushing-malware-in-worldwide-log4shell-attacks/
12 Mandiant, 2022, 「Does This Look Infected? A Summary of APT41 Targeting U.S. State Governments」
https://www.mandiant.com/resources/apt41-us-state-governments
13 Netlab 360, 2022, 「New Threat: B1txor20, A Linux Backdoor Using DNS Tunnel」
https://blog.netlab.360.com/b1txor20-use-of-dns-tunneling_en/
14 Product Security Incident Response Teamの略、製品の設計段階から出荷後までを対象に、インシデントなど問題発生時に対応するチーム
15 Computer Security Incident Response Teamの略、平時および有事におけるサイバーセキュリティの安全管理業務を担うチーム
{{filterContent.facetedTitle}}
{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
{{contentList.loadingText}}
{{filterContent.facetedTitle}}
{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
{{item.videoDuration}}
{{item.title}}
{{item.text}}
{{item.videoDuration}}
{{item.text}}
{{contentList.loadingText}}
