Japan's Ministry of Economy, Trade and Industry (METI) first published its "Guidance on Introduction of Software Bill of Materials (SBOM) for Software Management" on July 28, 2023, then revised it to Ver. 2.0 on August 29, 2024, after running a public comment period from April 26 to May 27, 2024 that drew formal input from groups like BSA | The Software Alliance. The guidance is voluntary, and even the US comparison point has softened: the government-wide attestation mandate that gave US Executive Order 14028 its teeth was rescinded by the Office of Management and Budget in January 2026 in favor of an agency-by-agency, risk-based approach, leaving SBOM delivery to individual federal contracts rather than a blanket requirement. METI's guidance was voluntary from the start, and it is quickly becoming a de facto reference point for procurement conversations at Japanese manufacturers, critical-infrastructure operators, and their suppliers regardless of what happens to any single country's mandate. Then, on September 3, 2025, METI went further: it was one of 21 government agencies across 15 countries — including the US Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) — that co-signed "A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity," signaling that Japan's approach is converging with, not diverging from, the rest of the world's SBOM expectations. For a software vendor with customers in Japan, the practical question isn't whether METI's guide is "law" — it's whether a procurement questionnaire will cite it next quarter. This post breaks down what the guidance actually says and what to do about it.
What does METI's SBOM guidance actually require?
It requires nothing by law — METI's document is guidance, not regulation, and it carries no penalties or certification scheme. What it does is define a shared vocabulary and a phased process: an SBOM production and sharing phase, where suppliers generate and hand off component inventories, and an SBOM use and management phase, where recipients ingest that data to track vulnerabilities over the software's life. Ver. 1.0 (July 2023) was aimed primarily at software suppliers and framed SBOM as a vulnerability-management tool, not a compliance checkbox. Ver. 2.0 (August 2024) broadened the audience to explicitly address both suppliers and procuring organizations, and added two operational constructs: an "SBOM-compliance model" and an "SBOM-contract model," giving companies language to put into actual vendor contracts. It emerged from METI's Task Force for Evaluating Software Management Methods, with an explicit goal of making SBOM practical for SMEs, not just large enterprises.
Which SBOM formats does METI actually endorse?
METI's guidance does not invent a Japan-specific SBOM format — it points to the two formats already dominant internationally: SPDX and CycloneDX. That's a deliberate choice: rather than fragment the ecosystem the way some early national frameworks risked doing, METI aligned with what NTIA's 2021 minimum-elements framework in the US and the SBOM tooling ecosystem (Syft, Trivy, cdxgen, and others) already produce by default. For a vendor already generating SPDX or CycloneDX output for US federal customers under EO 14028, there is no new format to build a pipeline for — the same SBOM artifact can, in principle, satisfy a Japanese procurement request and a US one, provided the content depth matches what each buyer asks for.
How is this different from the US EO 14028 SBOM requirement?
The core difference has always been legal force, and that gap has actually narrowed this year. EO 14028, signed in May 2021, was operationalized through OMB memos M-22-18 and M-23-16, which required federal agencies to collect a secure-software-development attestation from vendors and let agencies request an SBOM as supporting evidence. In January 2026, OMB rescinded both memos via M-26-05, replacing the uniform attestation mandate with an agency-led, risk-based approach — agencies may still choose to require an SBOM by contract, but there is no government-wide mandate to do so today. METI's guidance was never a mandate in the first place, so the practical distance between the two regimes has narrowed rather than widened: both now leave the SBOM decision largely to the buying organization's own contract terms. What still separates them is convergence at the format and vocabulary level, not enforcement — both point to SPDX/CycloneDX, both describe a "minimum elements"-style baseline (supplier name, component name, version, dependency relationships), and both frame SBOM primarily as a vulnerability-response tool rather than a licensing or audit artifact. The September 2025 joint guidance, co-signed by METI alongside CISA, NSA, and 18 other national cybersecurity agencies, formalizes that convergence, defining a shared vocabulary and value proposition for SBOM across all 15 signatory countries rather than leaving each nation to define terms independently.
Why would a non-Japanese vendor need to care about voluntary guidance?
Because "voluntary" in a national guidance document has historically been a leading indicator of what shows up in private contracts a year or two later — that is exactly the path EO 14028 took as it propagated from a federal mandate into private-sector vendor questionnaires industry-wide. Japan's largest manufacturers and critical-infrastructure operators sit inside global supply chains where a security team that has read METI's guide is increasingly likely to ask a foreign software vendor for an SBOM in SPDX or CycloneDX format as a condition of a renewal, even with no law compelling it. Vendors that already generate SBOMs for US or EU customers are not starting from zero — the same artifact, generated consistently and versioned across releases, is the asset that answers a METI-flavored request the same afternoon it lands instead of triggering a scramble.
What should a vendor selling into Japan do differently today?
Start by treating SBOM generation as a standing build artifact, not a one-off deliverable produced when a customer asks. METI Ver. 2.0's contract-model language suggests buyers will increasingly specify SBOM delivery cadence and update triggers (new release, disclosed CVE) inside master service agreements, so a vendor that can hand over a current, versioned SBOM on demand — rather than committing to generate one after the request arrives — has a real procurement advantage. Second, generate in SPDX or CycloneDX by default, since both satisfy METI's guidance and every other major framework a global vendor is likely to encounter, avoiding one-off format conversions per customer. Third, keep prior versions: METI's use-and-management phase assumes buyers will compare SBOMs across releases to spot newly introduced components and vulnerabilities, which requires the vendor (or the buyer) to retain a version history rather than a single current snapshot.
How Safeguard helps
Safeguard's Enterprise Software Supply Chain Manager generates SBOMs directly from source repositories, containers, and manifests in CycloneDX format on every build, so vendors selling into markets that reference METI's guidance always have a current artifact ready rather than one produced under deadline pressure. The SBOM Repository stores every version a product has ever shipped, with built-in version comparison that shows added and removed components and newly introduced vulnerabilities between releases — the exact comparison METI's use-and-management phase assumes buyers will want to run. And for teams on the receiving end of Japanese customer or vendor requirements, Safeguard's SBOM Requests workflow in TPRM lets a security team request, track, and validate SPDX or CycloneDX submissions from vendors at scale, with automatic format and completeness validation, instead of chasing individual PDFs and spreadsheets by email.