Research-driven open-source project / Direction under exploration
VERIFICATION BY THE SOFTWARE USER.
What does your software depend on? Vendors should be able to prove the answer without revealing their full composition, and users should be able to verify it themselves. MobS is exploring how SBOMs, blockchain, and zero-knowledge proofs can make this possible.
01 / THE PROBLEM & GOAL
The Log4j vulnerability (Log4Shell), the XZ Utils backdoor, and the Shai-Hulud attack spreading through npm packages show how problems in a dependency can put the software using it at risk. Users may ask a vendor whether a particular component or version is used, but have limited ways to verify the answer themselves.
An SBOM (Software Bill of Materials) lets users examine the listed components and dependencies, providing a starting point for investigating vulnerabilities. Determining whether a vulnerability affects a product also requires checking how components are used. Detailed composition data can reveal attack surface and trade secrets, so vendors cannot always hand it over. Users want to verify; vendors need to keep details confidential. MobS aims to serve both.
Why nowSBOMs are becoming more important in both regulation and practice. The EU Cyber Resilience Act (CRA) requires manufacturers of products within its scope to draw up an SBOM, with its main obligations applying from 11 December 2027. It does not impose a general obligation to publish SBOMs for users or share them with business partners. In Japan, the Ministry of Economy, Trade and Industry has published guidance on adopting SBOMs and making arrangements for their exchange. Balancing disclosure and confidentiality matters when composition data is requested.
Sources: Apache: Log4Shell / Red Hat: XZ Utils / GitHub: npm / Shai-Hulud / European Commission: Cyber Resilience Act / METI: SBOM guidance ver. 2.0 (in Japanese)
Users
MobS aims to let organizations that adopt or procure software independently verify claims about dependencies on specific components, without relying solely on the vendor’s answer. These checks would help them investigate whether a vulnerability affects their software.
Vendors
Organizations that supply software can back their dependency claims with proofs without disclosing SBOM details, and attach verifiable evidence to their answers.
Supply chains
By sharing dependency records between organizations, MobS aims to make dependencies verifiable across the whole supply chain, from component suppliers to end users.
The vendor supplies a proof supporting its dependency claim, and the user checks that proof. Verification should not require trust in the vendor’s statements.
This verifies a dependency claim against registered information. Whether the registered data matches the actual software composition requires a separate check. To close this gap, we plan to explore combining MobS with approaches such as reproducible builds and third-party review.
02 / APPROACH
Proving a claim without revealing the details, and being able to confirm that the underlying records have not been rewritten. MobS combines the two.
Zero-knowledge proofs
A claim such as “A depends on B” can be shown to be correct with respect to the registered records, without disclosing the full dependency graph. Users only need to verify the proof.
Blockchain
If the reference records lived in a database run by one company, users would still need to trust that operator. A blockchain lets multiple organizations share the records and confirm that they have not been rewritten. The project does not aim to issue or trade crypto assets.
| Approach | What it provides | What remains open |
|---|---|---|
| Sharing SBOMs individually (e.g. under NDA) | Direct access to the detailed composition. | The details leave the vendor’s hands, and they become harder to manage as recipients increase. |
| Vendor statements and VEX | Vendors can state whether a vulnerability affects their product. | Users find it hard to check those statements independently. |
| Signing and provenance (e.g. Sigstore, SLSA) | Verifiable origin and build process of artifacts. | Proving whether a specific dependency exists while keeping the rest confidential is not their main focus. |
MobS is not meant to replace these approaches, but to be used alongside them.
03 / RESEARCH FOUNDATION
MobS builds on research into managing and verifying dependency information extracted from SBOMs, published by team member ikepe (Shumpei Ikegami) as first author. The paper’s author is now turning that research into an implementation.
The related paper proposes a hybrid of public and consortium blockchains, recording hashed dependency information. It implements and evaluates verification using zero-knowledge proofs, while keeping detailed information confidential.
The project’s specific features, architecture, and delivery approach are being explored in light of this research.
RELATED PAPER
IEICE Transactions on Information and Systems (Japanese Edition), Vol. J109-D, No. 4, pp. 137–148, April 2026 (in Japanese)
DOI: 10.14923/transinfj.2025PDP0011View the publisher’s article04 / DEVELOPMENT SUPPORT
The project is exploring and developing a path from research to practical open-source software. We are seeking support for development tools and evaluation environments to advance implementation and testing.
How should users perform verification? What information needs to be disclosed? We aim to work through these questions with the research as a foundation, and iterate on implementation and evaluation.
05 / TEAM & CONTACT
MobS is developed by the following members.
For development support or joint evaluation, please get in touch at this address.
[email protected]Research & developmentFirst author of the related paper (Shumpei Ikegami)
GitHub: @ikepeDevelopment
GitHub: @Huyu2239