Blog

なぜ今、SBOMが不可欠な存在となったのか

現代社会を支えるソフトウェアは、そのほとんどがゼロから作られているわけではありません。オープンソースソフトウェア（OSS）やサードパーティ製のライブラリといった、無数の外部コンポーネントを複雑に組み合わせて構築されています。これは、開発の速度と効率を飛躍的に向上させる一方で、新たなリスクを生み出しました。それは、自社のソフトウェアが「何でできているのか」を正確に把握できなくなるという、サプライチェーンのブラックボックス化です。この課題を解決するために登場したのが、SBOM（Software Bill of Materials）、すなわちソフトウェア部品表という概念です。

物理的な製品の世界では、ある製品がどの部品で構成されているかを一覧化したBOM（部品表）は、古くから当たり前に存在し、製造、調達、品質管理の根幹を支えてきました。SBOMは、この考え方をソフトウェアの世界に適用したものです。具体的には、あるソフトウェアを構成するコンポーネントの名称、バージョン、供給元、そしてそれらの部品がどのように依存し合っているかといった情報を、機械が読み取れる形式で網羅的に記述したデータです。この「部品表」があることで、組織は自社のソフトウェア資産の構成を正確かつ即座に把握できるようになります。

近年、SBOMが急速に注目を集めるようになった背景には、ソフトウェアサプライチェーンを標的としたサイバー攻撃の深刻化があります。その象徴的な出来事が、2021年末に発覚した「Log4j」の脆弱性問題です。世界中の非常に多くのシステムで利用されていたこのロギングライブラリに深刻な脆弱性が発見されたことで、あらゆる組織が対応に追われました。問題は、自社のシステムが直接Log4jを使っていなくても、利用している別のソフトウェアやサービスが間接的にLog4jに依存しているケースが多数あったことです。多くの企業が「自社のどこに、どのバージョンのLog4jが含まれているのか」を特定するために膨大な時間と労力を費やし、サプライチェーンの可視化がリスク管理の最重要課題であることが浮き彫りになりました。

こうした状況を受け、各国の政府や規制当局も動き出しています。特に米国では、サイバーセキュリティ強化を目的とした大統領令が発令され、政府機関にソフトウェアを納入するベンダーに対してSBOMの提出を義務付ける動きが進んでいます。この流れは、医療、金融、重要インフラといった特定の産業分野にも広がりを見せており、SBOMは単なるベストプラクティスから、契約や規制上の必須要件へと変化しつつあります。顧客から取引の条件としてSBOMの提出を求められるケースも増えており、ビジネスを継続する上で避けては通れない要素となっているのです。

組織横断で価値を生むSBOMの多面的な活用法

SBOMがもたらす価値は、単一の部門に留まるものではありません。セキュリティ、法務、そして運用・調達といった異なる領域において、それぞれの課題を解決し、組織全体のレジリエンスを向上させる力を持っています。

まず、最も直接的で分かりやすい効果は、セキュリティ部門における脆弱性対応の劇的な迅速化です。新たな脆弱性情報（CVE）が公開された際、従来であれば、影響を受ける可能性のある資産を一つひとつ手作業で調査し、棚卸しする必要がありました。これは時間がかかるだけでなく、調査漏れのリスクも常に伴います。しかし、最新のSBOMが整備されていれば、データベースを検索するだけで、脆弱性のあるコンポーネントがどの製品のどのバージョンに含まれているのか、そしてそれがどのような依存関係の上にあるのかを瞬時に特定できます。これにより、セキュリティチームは影響範囲の把握と対応の優先順位付けを数時間、場合によっては数分で完了させることが可能になり、修正パッチ適用の迅速化に繋がります。

さらに、VEX（Vulnerability Exploitability eXchange）という情報を組み合わせることで、対応の精度はさらに向上します。VEXは、特定の脆弱性が自社の製品において「実際に悪用可能かどうか」というコンテキスト情報を付与するための仕組みです。例えば、「脆弱性のあるライブラリは含まれているが、製品の利用状況や設定上、その脆弱性が悪用される経路は存在しない」といった評価を機械可読な形式で記録します。SBOMで影響範囲を網羅的に洗い出し、VEXで緊急対応が必要なものだけを絞り込むことで、セキュリティチームは誤検知による不要なアラート対応から解放され、本当にリスクの高い問題にリソースを集中させることができるのです。

次に、法務・コンプライアンス部門における価値です。現代のソフトウェア開発に欠かせないOSSには、GPLやAGPL、MITライセンスなど、それぞれ異なる利用条件が定められています。これらのライセンス条項を遵守しない場合、著作権侵害による訴訟リスクや、最悪の場合には製品の出荷停止やソースコードの公開といった事態に発展しかねません。SBOMは、ソフトウェアに含まれる全コンポーネントのライセンス情報を一覧化するため、こうしたコンプライアンス遵守を強力に支援します。製品のリリース前に、データに基づいてライセンス要件（著作権表示、ソースコード提供義務など）を網羅的にチェックするプロセスを自動化でき、これまで専門家が手作業で行っていたレビューの負荷を大幅に軽減します。これにより、事後的なライセンス違反の発覚による手戻りやビジネス上の損失といった高コストなリスクを未然に防ぐことができます。

そして、運用・調達の観点からも、SBOMは重要な役割を果たします。ソフトウェア製品やサービスを外部から調達する際、これまでは機能や価格が主な評価軸でしたが、その中身はブラックボックスでした。しかし、調達側がベンダーに対してSBOMの提出を求めることで、製品の透明性が格段に向上します。例えば、サポートが終了（EOL）に向かっている古いコンポーネントが含まれていないか、脆弱性への追従は迅速に行われているか、メンテナンスの頻度はどの程度か、といったソフトウェアの「健全性」を客観的なデータに基づいて評価できるようになります。これは、長期的な運用コストやセキュリティリスクを事前に見積もる上で極めて有効な情報となり、ベンダーロックインを回避し、より健全なパートナーシップを築く一助となります。また、M&A（企業の合併・買収）の際には、買収対象企業のソフトウェア資産の構成や潜在的リスクを把握するための技術デューデリジェンスの出発点としても活用されます。

実践的な導入から継続的運用へのロードマップ

SBOMの導入と運用を成功させるためには、その作成方法から配布、保守に至るまでのライフサイクル全体を考慮した戦略的なアプローチが求められます。

SBOMのデータフォーマットには、業界標準としてSPDXとCycloneDXの二つが広く利用されています。SPDXはLinux Foundationが主導しており、特にライセンス情報の詳細な記述や監査証跡の管理に強みを持っています。一方、CycloneDXはセキュリティコミュニティOWASPから生まれたフォーマットで、アプリケーションセキュリティのユースケースを重視し、VEXとの連携などに配慮した軽量な設計が特徴です。どちらを選択するかは、組織の目的や利用するツールとの親和性によって決まりますが、将来的にはフォーマット間の相互変換も可能になるため、まずは自社のプロセスに最も適したものから始めるのが現実的です。

SBOMを生成する手法は、主に「ソースコード解析」「ビルド時の生成」「バイナリ解析」の三つに大別されます。ソースコード解析は、開発者が用いるパッケージマネージャ（npm, Mavenなど）の依存関係ファイルから情報を抽出します。ビルド時の生成は、CI/CDパイプラインのプロセスにSBOM生成ツールを組み込み、ソフトウェアがビルドされるたびに自動で最新のSBOMを生成し、成果物と一緒に保管する方法です。バイナリ解析は、すでにコンパイルされた実行ファイルやコンテナイメージをスキャンし、実際に含まれているコンポーネントを特定します。理想的なのは、これらの手法を組み合わせ、開発の初期段階から本番運用の段階まで、一貫したパイプライン上でSBOMを継続的に更新し続けることです。

しかし、SBOMは一度作成すれば終わりという静的な文書ではありません。その価値を維持するためには、「鮮度」と「整合性」が極めて重要です。依存関係は日々更新され、ビルド環境の僅かな違いによっても成果物の中身は変化します。したがって、SBOMもそれに追随して常に最新の状態に保たれなければなりません。CI/CDへの組み込みによる自動生成は、この課題を解決するための必須のプラクティスです。

また、現場での運用においては、いくつかの課題も認識しておく必要があります。一つはデータ品質の問題です。異なるツールで生成した結果、同じコンポーネントが別の名前で記録されたり、依存関係が不正確になったりすることがあります。これを防ぐためには、purl（Package URL）のような標準化された識別子を積極的に利用し、社内での命名規約を整備することが有効です。もう一つの課題は、SaaSやマネージドサービスのように、自社で直接ビルドしないソフトウェアの扱いです。これからの時代は、SaaSプロバイダーが自社サービスのSBOMを公開し、利用企業がそれを取り込んで自社のリスク管理に統合していくという、エコシステム全体での連携が不可欠になるでしょう。

これからSBOM導入に着手する組織にとって最も重要なことは、最初から完璧を目指して立ち止まらないことです。まずは、自社の主要な製品やサービスを一つ選び、そのCI/CDパイプラインにSBOM生成を組み込むことから始めるのが良いでしょう。そして、生成されたSBOMと、実際に運用されている環境をスキャンした結果を比較し、その差分を分析することで、自社にとっての品質基準を定めていきます。次に、脆弱性管理プロセスと連携させ、VEXの試験運用を開始します。このように、開発、運用、セキュリティ、法務といった関係者を巻き込みながら、スモールスタートでサイクルを回し、徐々に適用範囲を広げていくアプローチが成功の鍵となります。

最終的に目指すべき姿は、SBOMを単なる提出書類として扱うのではなく、サプライチェーン全体の状況をリアルタイムに把握するための「観測可能性（オブザーバビリティ）のデータ基盤」として活用することです。脆弱性情報、ライセンス情報、ビルドの来歴、そして実行環境の実測データといった様々な情報をSBOMに紐づけて一元管理し、組織内の誰もが同じデータを見て、迅速かつ的確な意思決定を下せる状態を築くこと。それこそが、SBOMがもたらす真の価値と言えるでしょう。

企業のウェブサイトやサービスで使われるドメインは、インターネット上の「住所」であり、顧客からの信頼の礎となる重要な資産です。しかし今、そのドメインの一部である「サブドメイン」が、設定のわずかな見落としから第三者に乗っ取られ、巧妙なサイバー攻撃に悪用される事例が世界中で深刻化しています。「サブドメイン乗っ取り（Subdomain Takeover）」と呼ばれるこの脅威は、使われなくなったクラウドサービスや外部サービスへのDNS設定を削除し忘れたまま放置してしまう、いわゆる「ダングリングDNS（宙ぶらりんのDNSレコード）」を足がかりにします。攻撃者はこの隙を突いて、本来の組織が持つ正規ドメインのサブドメインを掌握し、フィッシングサイトやマルウェア配布の拠点として悪用するのです。見た目は完全に正規のURLであるため、利用者は疑うことなくアクセスしてしまい、被害はブランドイメージの毀損から、サプライチェーン全体を巻き込む大規模なインシデントへと発展しかねません。2025年に入り、日本の政府機関ドメインでもこの問題が発覚し、決して他人事ではない脅威として国内でも急速に関心が高まっています。本稿では、この静かで深刻な脅威の実態を国内外の最新事例から読み解き、なぜ攻撃が起きるのか、そして組織としていかにして自社のドメインを守るべきか、その具体的な対策を深く掘り下げていきます。

日本でも顕在化した静かなる脅威――政府機関ドメインで起きたこと

2025年1月、日本のセキュリティ界隈に大きな衝撃が走りました。国土交通省をはじめとする複数の省庁や関連機関において、過去に利用していたサービスのサブドメイン設定が削除されないまま放置され、第三者がそれを悪用できる危険な状態にあったことが、大手メディアによって次々と報じられたのです。特に深刻だったのは、国土交通省が過去に使用していた特定のサブドメインが、実際にある海外のオンラインカジノの広告サイトへ利用者を誘導する目的で悪用されていたという事実でした。政府機関の公式サイトのドメイン（go.jp）を冠したURLが、全く無関係な、それも公序良俗に反する可能性のあるサイトに繋がっていたこの出来事は、「サブドメイン乗っ取り」の危険性を日本国内に広く知らしめる象徴的な事件となりました。

この攻撃の根源にあるのは、「ダングリングDNS」と呼ばれる状態です。これを分かりやすく例えるなら、引っ越した後の古い家に、以前の住人の表札が残っているようなものです。新しい住人がその表札を悪用して郵便物をだまし取ったり、なりすましたりできるように、インターネットの世界でも同様のことが起こります。企業や組織がウェブサイトのリニューアルや、利用するクラウドサービスの変更を行った際に、古いサービス（例えば、Amazon S3のストレージやMicrosoft Azureのウェブアプリなど）は解約します。しかし、その古いサービスに向けて設定されていたDNSレコード、特にドメインの別名を定義する「CNAMEレコード」を消し忘れてしまうことがあるのです。攻撃者は、インターネット上を常にスキャンし、このような「宛先を失って宙ぶらりんになったCNAMEレコード」を探しています。そして、その宛先と同じ名前で新しいクラウドサービスを契約しさえすれば、DNSの設定上、そのサブドメインへのアクセスはすべて攻撃者が用意したサーバーへと向かうことになります。これが、サブドメイン乗っ取りの基本的な仕組みです。

go.jpドメインでの事件を受け、日本のドメイン登録管理組織であるJPRS（日本レジストリサービス）は、直ちに技術的な解説と対策に関する注意喚起を発表しました。そこでは、サービス終了時にDNS設定、特にCNAMEレコードや、子会社や関連組織に委任していたNSレコードの削除を徹底することの重要性が改めて強調されました。これまでDNSの設定管理は、一部の技術専門家の間での課題と認識されがちでしたが、この一件を機に、企業の広報や経営層までもが無視できない、事業継続に関わる重大なリスク管理マターとして認識されるようになったのです。技術的な設定ミスという小さな綻びが、組織全体の信頼を根底から揺るがしかねないという厳しい現実が、白日の下に晒された瞬間でした。

世界で「産業化」する乗っ取り攻撃――巧妙化する手口とその実態

日本での事件がDNS運用の見直しを促す警鐘となった一方で、海外ではサブドメイン乗っ取りはすでに「産業化」の様相を呈しています。攻撃者は、これを一過性のいたずらではなく、継続的な収益源として確立しようと活動を活発化させているのです。2025年春、セキュリティ企業のInfobloxは、「Hazy Hawk」と名付けられた攻撃者グループの活動を報告しました。彼らは、組織が放置したクラウド資産に向けられたダングリングDNSを体系的に探し出し、米疾病対策センター（CDC）のような公的機関や、Bose、Panasonic、Deloitteといった世界的に著名な大企業のサブドメインを次々と乗っ取り、マルウェアの配布や悪質なスパムサイトへの誘導に利用していました。この攻撃手法の厄介な点は、サーバーへの不正侵入のような派手な痕跡を残さないことです。攻撃者はただ、正規の運用プロセスからこぼれ落ちた「運用のほころび」を突くだけで、正規ドメインの権威を悪用できてしまいます。そのため、被害組織側での検知が遅れがちになり、気づいた頃にはブランドイメージが大きく傷つけられているという事態に陥りやすいのです。

このような攻撃は、もはや単に偽のウェブサイトを公開するだけには留まりません。近年の攻撃者は、TDS（Traffic Distribution System）と呼ばれる仕組みを組み合わせ、アクセスしてきたユーザーの地域やデバイス、OSなどの情報に応じて、表示するコンテンツを動的に切り替えます。あるユーザーにはフィッシングサイトを、別のユーザーにはマルウェアをダウンロードさせるサイトを見せるなど、効果を最大化するよう最適化されているのです。さらに、ウェブサイト訪問時に表示される「通知を許可しますか？」というポップアップを悪用し、一度許可してしまったユーザーに対して、その後も持続的に偽の警告や詐欺的な広告を送り続けるといった手口も横行しています。表面上は「○○社の公式サイト」という信頼性の高い顔をしていながら、その裏側では、攻撃者が自由に使い捨てるためのインフラとして機能し、広告配信ネットワークなどを介して被害はネズミ算式に拡大していきます。

クラウドコンピューティングの普及が、この問題に拍車をかけている側面も無視できません。AWS S3、GitHub Pages、Heroku、各種CDN（コンテンツデリバリネットワーク）といったサービスは、誰でも手軽にウェブサイトやアプリケーションを公開できる利便性を提供します。その利便性を支えているのが、柔軟なCNAMEレコードの運用です。しかし、この手軽さが仇となり、「とりあえず作って、終わったら消し忘れる」という事態を誘発しやすくなっています。セキュリティ研究者のコミュニティでは、どのクラウドサービスのどのような設定状態であれば乗っ取りが可能か、という知見が「can-i-take-over-xyz」のような公開リポジトリに蓄積されており、攻撃者にとっても格好の参考情報となっています。利便性とリスクは常に表裏一体であり、クラウド時代の恩恵を安全に享受するためには、その光と影を正しく理解することが不可欠なのです。

脅威の連鎖を断ち切るために――今、組織が取り組むべき対策とは

サブドメイン乗っ取りという脅威の根は、突き詰めれば「ライフサイクル管理の失敗」という非常にシンプルな問題に行き着きます。プロジェクトの開始、クラウドサービスの導入、ウェブサイトの公開といった「始まり」には多くの時間と注意が払われる一方で、プロジェクトの終了、サービスの解約、サイトの閉鎖といった「終わり」の手続きは、しばしば軽視されがちです。このギャップこそが、攻撃者に付け入る隙を与えてしまうのです。この脅威の連鎖を断ち切るためには、「技術的な設定」と「組織的な運用習慣」の両面から対策を講じ、それを組織文化として根付かせる必要があります。

まず、技術的な対策としては、各クラウドプラットフォームが提供している「なりすまし防止機能」を正しく活用することが挙げられます。例えば、Microsoft AzureのApp Serviceでは、ドメインの所有権を確認するために「asuid」という固有のIDを含んだTXTレコードをDNSに設定する仕組みがあります。このTXTレコードが存在する限り、たとえCNAMEレコードが残っていても、第三者が同じ名前でサービスを立ち上げてドメインを乗っ取ることをブロックできます。これは、万が一DNSレコードを消し忘れてしまった場合の、最後のセーフティネットとして機能します。すべてのプラットフォームが完璧な保護機能を提供しているわけではありませんが、利用するサービスの仕様を正しく理解し、推奨されるセキュリティ設定を施すことは、防御の第一歩として極めて重要です。

しかし、より本質的で重要なのは、組織的な運用習慣の見直しです。具体的には、サービスやプロジェクトを終了する際の公式な手順書、いわゆる「退役手順書（Runbook）」の中に、「関連する全DNSレコードの削除」を必須のチェック項目として明記し、実行を義務付けることです。そして、その手続きが徹底されているかを、変更管理プロセスの中で確実に監査する体制を整えなければなりません。さらに、人間の注意力には限界があることを前提に、定期的に自社の管理するドメイン全体を自動スキャンし、ダングリングDNSの兆候がないかを洗い出す仕組みを導入することが望ましいでしょう。近年では、EASM（外部攻撃対象領域管理）と呼ばれるソリューションも登場しており、こうしたツールは自社の気づいていないIT資産や、今回のような設定不備を自動的に検知するのに役立ちます。

最終的に最も重要なのは、組織の壁を越えた連携です。ドメイン名の管理を担当する情報システム部門、クラウドサービスを契約・利用する事業部門や開発部門、そしてアプリケーションのライフサイクルを管理するチーム。これらの担当者が縦割りで業務を進めている限り、資産のライフサイクル全体を見通すことは困難です。ドメインという会社の「表札」を誰が管理し、その「表札」がどの「家」（クラウド資産）を指しているのか、そしてその「家」がいつ取り壊されるのか。この一連の流れを一元的に把握し、それぞれの責任者が連携して管理する文化を醸成することこそが、サブドメイン乗っ取りという脅威に対する最も強力な対抗策となります。この脅威は、特定の製品の脆弱性ではなく、私たちの「運用文化」そのものに潜んでいます。プロジェクトの「始まり」にかけるのと同じだけの情熱と規律をもって「終わり」を設計し、管理しきること。それこそが、最小のコストで最大のセキュリティ効果を生む、確実な道筋と言えるでしょう。