MobS

研究を起点としたOSSプロジェクト / 方針を検討中

VERIFICATION BY THE SOFTWARE USER.

依存関係は、信じるものから、確かめるものへ。

ソフトウェアが何に依存しているか。その答えを、ベンダーは構成の詳細を明かさずに証明し、利用者は自ら検証する。MobSは、SBOM・ブロックチェーン・ゼロ知識証明を用いて、そのための仕組みを検討しています。

課題と目的を読む関連論文を読む
地上の若い植物と、土や霧に隠れた根のネットワーク。茎から一つの小さな点につながる根だけが、濃い緑の線で示されている。
利用者自身が、確かめられるようにSBOM + BLOCKCHAIN + ZERO-KNOWLEDGE

01 / THE PROBLEM & GOAL

ベンダーの回答を、信じるしかないのか。

Log4jの脆弱性（Log4Shell）、XZ Utilsへのバックドア混入、npmパッケージを通じて広がったShai-Hulud攻撃。依存する部品の問題は、利用中のソフトウェアにも影響し得ます。問題のある部品やバージョンが使われているかをベンダーに問い合わせても、利用者には、その回答を自ら確かめる手段が限られています。

SBOM（ソフトウェア部品表）を受け取れば、記載された部品や依存関係を確認し、脆弱性の影響を調べる手がかりを得られます。影響の有無を判断するには、部品の使われ方なども確認する必要があります。詳細な構成情報は攻撃の手がかりや営業上の秘密にもなりうるため、そのまま渡せるとは限りません。確かめたい利用者と、詳細を明かしにくいベンダー。MobSが目指すのは、この二つの立場の両立です。

なぜ今かSBOMの整備は、制度と実務の両面で重要になっています。EUのサイバーレジリエンス法（CRA）は、対象製品の製造者にSBOMの作成を求めます（主な義務は2027年12月11日から適用）。利用者への公開や取引先への共有が一律に義務付けられるわけではありません。日本では、経済産業省がSBOMの導入や取引時の取り決めに関する手引を公表しています。構成情報を求められる場面で、開示と秘匿をどう両立するかが重要になります。

出典: Apache「Log4Shell」 / Red Hat「XZ Utils」 / GitHub「npm / Shai-Hulud」 / 欧州委員会「Cyber Resilience Act」 / 経済産業省「SBOMの導入に関する手引ver2.0」

誰にとって、何が変わるか

利用者

回答を、自分で確かめられる

ソフトウェアを導入・調達する組織が、脆弱性の影響を調べるために、対象部品への依存関係の主張をベンダーの回答だけに頼らず、自ら検証できるようにすることを目指します。

ベンダー

詳細を明かさずに、裏付けられる

ソフトウェアを提供する組織が、SBOMの詳細を開示せずに、依存関係についての主張を証明で裏付けられます。問い合わせへの回答に、検証できる根拠を添えられます。

サプライチェーン

組織をまたいで、たどれる

依存関係の記録を組織間で共有し、部品の提供元から利用者まで、サプライチェーン全体で確かめられることを目指します。

ベンダーの説明ではなく、検証可能な証明を判断の根拠にする。

ベンダーに依存関係の主張を裏付ける証明を求め、利用者はその証明を検証する。ベンダーを信用することを、検証の前提にしない考え方です。

ここで確かめるのは、登録された情報に対する依存関係の主張です。登録内容と実際のソフトウェア構成が一致するかは、別途確認する必要があります。この差を埋める方法として、再現可能なビルドや第三者による確認などとの組み合わせを検討していきます。

02 / APPROACH

なぜ、ゼロ知識証明とブロックチェーンなのか。

詳細を見せずに主張の正しさを示すこと。その根拠となる記録が、後から書き換えられていないと確かめられること。MobSは、この二つを組み合わせます。

ゼロ知識証明

詳細を見せずに、正しさを示す

「AはBに依存している」という主張が、登録された記録に基づいて正しいことを、依存関係の全体を開示せずに示せます。利用者は証明を検証するだけで、主張の正しさを確かめられます。

ブロックチェーン

一者に頼らない、共有の記録

検証の基準となる記録を特定の一社が管理するデータベースに置くと、その管理者を信頼する必要が残ります。複数の組織で記録を共有し、後から書き換えられていないことを参加者が確かめられるようにするために使います。暗号資産の発行や取引を目的とするものではありません。

既存の方法との関係

方法できること残る課題
SBOMを個別に共有する（NDAなど）詳細な構成を直接確認できる。詳細が相手に渡る。共有先が増えるほど、管理が難しくなる。
ベンダーの回答・VEX脆弱性の影響の有無を、ベンダーが表明できる。表明の内容を、利用者が独立して確かめにくい。
署名・来歴の証明（Sigstore、SLSAなど）成果物の出所やビルドの過程を確かめられる。依存関係の詳細を伏せたまま、特定の依存の有無を示すことは主な対象ではない。

MobSは、これらを置き換えるものではなく、組み合わせて使うことを想定しています。

03 / RESEARCH FOUNDATION

秘密を保ちながら、検証を可能にする研究。

MobSは、メンバーのいけぺ〜（池上 峻平）が第一著者として発表した、SBOMから抽出した依存関係を管理・検証する研究を出発点にしています。論文の著者自身が、研究の実装に取り組んでいます。

関連論文では、公開型とコンソーシアム型のブロックチェーンを組み合わせ、依存関係をハッシュとして記録する手法を提案しています。詳細な情報を開示せずに検証するため、ゼロ知識証明を用いた実装と評価を行っています。

論文での研究成果を踏まえ、プロジェクトの具体的な機能や構成、提供方法は現在検討中です。

関連論文

サプライチェーン全体での依存関係管理を支援するコンソーシアム型ソフトウェア依存関係管理手法の提案

池上 峻平・高野 知佐・稲村 勝樹

電子情報通信学会論文誌 D, Vol. J109-D, No. 4, pp. 137–148, 2026年4月

DOI: 10.14923/transinfj.2025PDP0011出版社の論文ページへ

04 / DEVELOPMENT SUPPORT

利用者が検証できる仕組みに向けて。

現在は、研究を実用的なOSSにつなげるための検討・開発段階です。実装と評価を進めるため、開発ツールや検証環境などの支援を求めています。

利用者による検証をどのように実現するか、必要な情報をどの範囲まで開示するか。研究を踏まえてこうした課題を整理し、実装と検証を重ねていきたいと考えています。

連絡先を見るGitHubでプロジェクトを見る

05 / TEAM & CONTACT

チームと連絡先

MobSは、次のメンバーで開発しています。

開発支援や共同での検証についてのご連絡は、こちらのアドレスまでお寄せください。

[email protected]