Japan software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Japan, the rules that matter most changed shape in the last year. Since 1 October 2026, the 258 designated operators of essential infrastructure must report cyber incidents on their critical systems to their ministry and the Prime Minister (a first report promptly, three to five days at most for ransomware and most attacks, a detailed report within 30 days), and must list the products running those systems by 31 March 2027. Financial institutions answer to the Financial Services Agency's 2024 cybersecurity guidelines, which ask for software version ledgers, deadline-driven patching and contract terms for third parties, and recommend SBOMs. The Act on the Protection of Personal Information still sets the breach clock for everyone else, and AI is governed by a promotion law with no fines, plus a basic plan revised in July 2026.

This guide takes each rule from its primary text, shows the evidence a supervisor will ask for, and ends with a 30/60/90-day plan that works with your current tools. It is a practical reading of public documents, not legal advice. Where a rule needs interpretation for your entity, take it to counsel or your competent ministry.

Key takeaways

• Incident reporting under the Active Cyber Defense law started on 1 October 2026. Designated operators report "specified intrusion events" on specified important computers: a first report promptly (DDoS as soon as possible, ransomware and other attacks within three to five days of becoming aware) and a detailed report within 30 days.
• Asset notification is due by 31 March 2027 for specified important computers already in use on 1 October 2026, and within four months of installation for new ones. "Computer" includes the firmware, operating system, middleware and applications running on it, and cloud services.
• Economic security pre-screening governs critical purchases. Designated operators file an introduction plan before installing a specified critical facility or outsourcing its maintenance; screening takes 30 days, extendable to four months.
• The FSA's Guidelines on Cybersecurity for the Financial Sector (4 October 2024) ask for software ledgers with version and support dates, patch deadlines by criticality with senior management sign-off for exceptions, and third-party contract terms on vulnerability reporting and data location. SBOMs for in-house software are a recommended measure.
• APPI breach reports go to the Personal Information Protection Commission promptly, with a final report within 30 days, or 60 days where the leak may have been caused with unauthorized intent.
• Japan's AI Promotion Act (Act No. 53 of 2025) is fully in force since 1 September 2025. It creates duties to cooperate, not fines. The AI Basic Plan was first adopted on 23 December 2025 and revised on 14 July 2026.
• Safeguard capabilities in this guide are all GA: SBOM generation and analysis, SCA and vulnerability management, reachability analysis, autonomous remediation (ships switched off), policies and gates, the Compliance and GRC suite, TPRM, CSAF and VEX upload, Package Firewall, AI-BOM discovery, AI-SPM, AI Gateway, MCP Guardrail, agent identity, Trust Center, the CLI and local runner, Zero AI mode, bring your own model and air-gapped deployment.

Who this applies to in Japan

Japan regulates software security mostly through who you are and what you run, not through a single horizontal law. Five groups carry most of the load.

Designated essential infrastructure operators. The Economic Security Promotion Act (Act No. 43 of 2022) lets ministries designate "specified essential infrastructure service providers" in listed sectors. The Cabinet Office's July 2026 outline counts 258 designated providers as of 1 July 2026 across electricity, gas, petroleum, water, railways, trucking, international maritime cargo, port transport, air transport, airports, telecommunications, broadcasting, postal services, financial services and credit cards. Medical care was added by an amending act promulgated on 17 June 2026, which comes into force on a date set by Cabinet Order within 18 months. These same operators are the ones the Active Cyber Defense law calls "special social infrastructure operators" and asks to report incidents. Each answers to its own competent ministry (for finance, the FSA), with the Cabinet Office coordinating.

Banks, insurers, securities firms and payment providers. The FSA's guidelines note these firms are critical infrastructure operators under the Basic Act on Cybersecurity, and that their sector laws already require sound operations, including cybersecurity. Under Article 24(2) and Article 25(2) of the Banking Act, the FSA can also order reports from, and inspect, firms that banks outsource to.

Cloud providers selling to central government. Ministries buy cloud services from the ISMAP list, run jointly by the National Cybersecurity Office, the Digital Agency, the Ministry of Internal Affairs and Communications and METI. Low-risk SaaS can register under ISMAP-LIU.

Every business handling personal information. The Personal Information Protection Commission (PPC) enforces APPI against businesses handling personal information.

Makers of internet-connected products and of AI. JC-STAR, run by the Information-technology Promotion Agency (IPA), labels IoT products. The AI Promotion Act asks every developer and user of AI in business to cooperate with government measures.

Software vendors outside these groups are usually in scope indirectly: the operator buying your product must name it, screen your supply chain, or write your vulnerability duties into a contract.

The rules, regulator by regulator

Active Cyber Defense law: incident reporting and asset notification

The law's formal title is the Act on the Prevention of Damage Caused by Unauthorized Acts against Important Electronic Computers (重要電子計算機に対する不正な行為による被害の防止に関する法律, Act No. 42 of 2025), and the government also calls it the Cyber Response Capability Enhancement Act (サイバー対処能力強化法). The English titles here are our translations; the Japanese text is the one with legal effect. It is administered by the Cabinet Office's Director-General for Cybersecurity together with the National Cybersecurity Office (NCO) in the Cabinet Secretariat and the sector ministries.

Status today. In force. The Cabinet Office and NCO briefing of September 2026 says incident reporting, asset notification and a new public-private council took effect on 1 October 2026, alongside access and neutralization measures against attack servers. Its diagram shows the use of communications information starting in autumn 2027. The implementing Cabinet Order is No. 47 of 2026, and the reporting rules sit in a 2026 joint order of the Cabinet Office and seven ministries.

What counts as a covered system. A "specified important computer" is a designated operator's computer that is, or is part of, a specified critical facility under the Economic Security Promotion Act, is connected to one, or can feed data into one through USB or cloud services. The joint explainer of 1 October 2026 says in section 2-1-2 that the term includes the program built into the computer: firmware, operating system, middleware and applications, not just hardware.

Asset notification (Article 4). Operators notify their competent minister of each specified important computer: the operator, the related critical facility, the category of computer, the product name and the manufacturer. For cloud services the product name is the service name and the manufacturer is the provider. A system diagram showing how each computer relates to the others is attached. The explainer recommends, without requiring, that operators also say whether the asset is an appliance, software, a cloud service or other, and use "other" when a third party manages the system and the operator cannot collect its software details. The deadline is four months after installation, and six months after the law took effect (31 March 2027) for everything already installed on 1 October 2026.

Incident reporting (Article 5). When a designated operator becomes aware of a specified intrusion event on a specified important computer, or an event that could cause one, it reports to its competent minister and the Prime Minister. Article 4(2) of the joint ministerial order requires a first report promptly after awareness and a full report within 30 days. The explainer's section 6-2 sets the first-report clock by attack type: DDoS as soon as possible, and ransomware and other cyber attacks within three to five days of awareness. The explainer asks operators to send follow-up reports with indicators of compromise, the exploited vulnerability, and "the name and version of the targeted device or software", plus forensic reports. Report formats follow the interministerial agreement of 28 May 2025.

Why it matters for software teams. The September briefing says the government will match notified assets against vulnerability information, including unpublished information, and warn the operators affected. A list that goes down to the software on each computer gets warnings you can act on.

Economic Security Promotion Act: pre-screening of critical facilities and maintenance contracts

Chapter III of the Act on the Promotion of Ensuring National Security through Integrated Implementation of Economic Measures (経済施策を一体的に講ずることによる安全保障の確保の推進に関する法律) requires designated operators to submit an introduction plan to the competent minister before introducing a specified critical facility or entrusting its critical maintenance and management to a third party.

Status today. In force, with 258 designated providers as of 1 July 2026 and the medical sector to be added within 18 months of 17 June 2026. The Cabinet Office updated its explanatory material on 18 September 2026 and is holding briefing sessions in late 2026.

What it asks. The plan names the suppliers of the facility and its component facilities, and every contractor and subcontractor for critical maintenance. The ministry screens for 30 days, a period it can shorten or extend up to four months, and introduction is prohibited during screening. If it judges the facility highly likely to be misused for disruptive actions, it can recommend or order changes. Each plan also declares which "risk management measures" the operator has taken. The Cabinet Office's list includes having the operator check for malicious code and run vulnerability tests before introduction, keeping the facility patched to the operator's requirements, and confirming that the supplier will provide after-sales service such as responses to failures and vulnerabilities.

For a supplier, questions about who builds your product and how you handle vulnerabilities now arrive before the contract is signed.

Basic Act on Cybersecurity and the National Cybersecurity Office

The Basic Act on Cybersecurity (サイバーセキュリティ基本法) sets national principles and designates critical infrastructure sectors. In 2025 the former National center of Incident readiness and Strategy for Cybersecurity (NISC) was reorganized into the National Cybersecurity Office (国家サイバー統括室, NCO) in the Cabinet Secretariat. The NCO coordinates national cyber policy and, with METI, signed the international statement, "A Shared Vision of SBOM for Cybersecurity" in September 2025. For most private firms the Basic Act matters through the sector rules it underpins rather than through direct duties.

FSA Guidelines on Cybersecurity for the Financial Sector

The FSA published the Guidelines on Cybersecurity for the Financial Sector (金融分野におけるサイバーセキュリティに関するガイドライン) on 4 October 2024, alongside amendments to its supervisory guidelines. They apply on a risk-based approach: the FSA says it does not mandate uniform responses and checks firms through inspections and monitoring sized to the institution. Each section separates "fundamental response measures" from "recommended measures".

The sections that touch software most directly:

• 2.2.1.2 Hardware, software, etc. A fundamental measure: keep ledgers of hardware and software, including assets managed by external contractors, with the planned end of support and, for software, version information. Recommended measure (e): prepare an SBOM for software developed in-house and for services in use where the provider offers one. The guidelines define an SBOM as a machine-readable list of software components and their dependencies.
• 2.2.3 Vulnerability management. Fundamental measures: written procedures covering information sources, severity and scope evaluation, response deadlines and exception handling; patch deadlines set by system criticality and vulnerability severity, with records of status; formal senior management approval and a documented risk assessment when a patch is not applied; prompt identification of affected systems from the asset inventories when a severe vulnerability appears; group companies and overseas offices in scope; and, for critical vulnerabilities, management of the response on systems owned by critical third parties, using assurance reports or contracts.
• 2.6 Third-party risk management. Fundamental measures: a lifecycle framework and policy, a central function, a ledger of third parties (name, products and services, level of access, and the type, sensitivity and location of data they hold), due diligence before contracting, and contract or SLA terms covering audit rights, subcontracting, incident reporting, "response and reporting procedures when serious vulnerabilities are identified", vulnerability assessments, and data location, storage, transfer and disposal. Recommended measures extend this to fourth parties and concentration risk.

Many banks also follow the security guidelines published by the Center for Financial Industry Information Systems (FISC). FISC's website was under emergency maintenance when we checked on 25 October 2026, so we have not cited its current edition here.

METI's SBOM guide

METI's Guidance on Introduction of Software Bill of Materials (SBOM) for Software Management was first published in July 2023. Version 2.0, dated 29 August 2024, adds a concrete vulnerability management process and is written so that smaller companies can use it too; METI says it tested feasibility through proof-of-concept projects. The guide is voluntary. It sets out how to plan SBOM adoption, how to generate and share SBOMs, and how to use them for vulnerability and license management, and it uses the minimum elements familiar from US practice: supplier, component name, version, unique identifiers, dependency relationships, SBOM author and timestamp. Our earlier post on the METI guide walks through it in detail.

ISMAP and ISMAP-LIU

The Information system Security Management and Assessment Program (ISMAP) pre-assesses and registers cloud services that meet government security requirements, and ministries buy cloud from its lists. ISMAP-LIU, for SaaS used for low-risk work and information, began operating on 1 November 2022. The Digital Agency says ISMAP-LIU covers SaaS handling confidentiality level 2 information used for low-risk tasks. Both tracks require external audits against the ISMAP governance, management and control standards. Under ISMAP-LIU, governance and management standards are externally audited in full every year, while external audit of the control standards focuses on the controls that directly affect the service platform and configuration. The provider must also report on its own internal audits, which must cover every control objective at least once in three years.

ISMAP registers cloud providers; it does not cover software you run yourself.

Act on the Protection of Personal Information (APPI)

APPI (個人情報の保護に関する法律) is enforced by the PPC. Four articles shape software and supplier practice:

• Article 23: take necessary and appropriate measures to manage the security of personal data, including preventing leaks, loss or damage.
• Article 25: exercise necessary and adequate supervision over anyone entrusted with handling personal data.
• Article 26: report leaks likely to harm individuals' rights to the PPC and notify the people affected.
• Article 28: restrictions on providing personal data to third parties in foreign countries.

The PPC's guidance page says to report promptly once a leak is discovered, with the full report within 30 days, or within 60 days of discovery where the leak may have been caused with unauthorized intent. Reportable cases include leaks involving special care-required personal information, leaks that may have been caused with unauthorized intent (by insiders or outside attackers), and leaks affecting more than 1,000 people. A misconfiguration that leaves more than 1,000 people's data viewable on the internet is one of the PPC's own examples.

AI Promotion Act and the AI Basic Plan

The Act on Promotion of Research and Development, and Utilization of Artificial Intelligence-Related Technology (人工知能関連技術の研究開発及び活用の推進に関する法律, Act No. 53 of 2025) was enacted on 28 May 2025, partly took effect on 4 June 2025 and fully took effect on 1 September 2025, according to the Cabinet Office's outline. It is a promotion law. Article 7 asks "utilization business operators" (anyone developing, providing or using AI in business) to cooperate with government measures. Article 13 tells the government to set guidelines in line with international norms. Article 16 tells it to analyse cases where AI used for wrongful purposes or by inappropriate methods infringes people's rights, and to give guidance and advice to businesses. Article 18 requires an AI Basic Plan. The Cabinet adopted the first plan on 23 December 2025 and a revised plan on 14 July 2026; our post on the second AI Basic Plan covers its content.

There are no AI-specific fines. In practice, AI security duties in Japan come through the other rules on this page: the FSA's asset ledgers and third-party terms cover AI services a bank uses, APPI covers personal data sent to models, and the Active Cyber Defense law covers AI systems running on critical computers.

JC-STAR IoT security labels

JC-STAR (Japan Cyber-Security Technical Assessment Requirements) is IPA's labeling scheme for internet-connected products, based on METI's IoT Product Security Conformity Assessment Scheme Policy of 23 August 2024. STAR-1 sets baseline requirements for all IoT products; STAR-1 and STAR-2 work by vendor self-declaration, and STAR-3 and STAR-4 are for products used in government and critical infrastructure. IPA began accepting STAR-1 applications on 25 March 2025, released STAR-3 requirements for network devices and network cameras on 2 September 2026, started mutual recognition with Singapore's labeling scheme on 1 June 2026, and opened applications for products already compliant with the UK PSTI Act on 1 April 2026. See our STAR-1 requirements post for the checklist.

What the rules ask of software and open source

Put the rules side by side and they ask for the same few things in different words: know what software you run down to version, know who supplied it, fix what matters on a clock, report fast, and keep proof.

SBOMs. No Japanese law yet mandates an SBOM. The FSA recommends one for in-house software, METI's guide is the method, and the asset notification asks for product names and manufacturers. An SBOM per system answers all three, and the explainer's follow-up question too: which version of which software was attacked.

Vulnerability handling. The FSA wants procedures, deadlines by criticality, records and approved exceptions. Economic security risk measures ask for pre-installation vulnerability tests and patching. ISMAP asks cloud providers to act on vulnerability information.

Suppliers. FSA section 2.6, the economic security supplier disclosures, APPI Article 25 and ISMAP supplier controls all point to one supplier list, with what each provides and what data it touches.

Residency and AI. No rule here imposes general data localization, but APPI Article 28 restricts transfers abroad and the FSA wants data location in contracts. There are no AI-specific security duties yet, so treat models, SDKs, agents and AI services as software assets and third parties.

Real public incidents in or affecting Japan

These are drawn from official or company statements. We describe what the sources say and do not draw conclusions about what any organisation should have done.

MirrorFace campaign, alert of 8 January 2025. The National Police Agency and NISC published an alert that a campaign attributed to the group called MirrorFace (also tracked as Earth Kasha) had targeted organisations, businesses and individuals in Japan from around 2019, mainly those connected to national security and advanced technology. The alert's annexes describe techniques that abuse Windows Sandbox and VS Code, with traces and detection measures.

Yamato Transport deferred payment service, September and October 2026. Yamato Holdings reported that on 28 September 2026 Yamato Transport confirmed unauthorized access by a third party to its "Kuroneko deferred payment service". Its fourth report says an investigation with outside security specialists found some service information had been taken, including names, addresses, phone numbers, email addresses (about 490,000 records include an email address) and order details. Its third report, of 9 October, announced that the service had resumed.

Nikkei Inc., October 2026. Nikkei announced that a cloud service it uses for system development was accessed without authorization early on the 7th using stolen authentication credentials, and that about 1.83 million items of personal information had leaked as of 16 October 2026. It reported to the PPC on the 11th. Our post on the October 2026 breach wave in Japan covers these and related incidents in more depth.

The personas who own the problem

CISO. Owns the 1 October 2026 reporting duty and the board's question about it. Needs a tested path from detection to a first report inside three to five days, and a complete asset notification by 31 March 2027. Trigger: the first incident, or a ministry follow-up.

Head of AppSec or VP of Engineering. Owns the software side of the asset list and the FSA's patch deadlines. Needs SBOMs generated in the build and a ranked fix list that respects releases. Trigger: a severe vulnerability that must be traced to affected systems fast.

GRC and regulatory affairs. Owns the mapping from FSA sections, APPI articles and ISMAP controls to evidence, kept in one place. Trigger: an FSA inspection, an ISMAP audit or a report order.

Procurement and vendor risk. Owns introduction plans and the FSA's third-party ledger. Needs supplier SBOMs and vulnerability terms before signing. Trigger: a critical purchase or a renewal.

DPO or privacy lead. Owns APPI Article 26 reports and Article 28 transfers, so needs to know which systems and suppliers process personal data, and where. Trigger: a leak or a new overseas processor.

Product security lead at a device or software maker. Owns JC-STAR declarations and supplier answers to designated operators. Trigger: an operator's tender.

A practical 30/60/90-day plan

This plan assumes you are a designated operator, a financial institution, or a supplier to one. Cut what does not apply to you.

Days 1 to 30: know what you have and fix the clocks

1. Confirm your status. Check the Cabinet Office's list of designated providers. If you supply one, find out which of your products sit on its specified important computers.
2. Write the incident clock down. One page: who decides an event is reportable, who drafts the first report, who sends it to the competent minister and the Prime Minister, and the deadlines (DDoS as soon as possible; ransomware and other attacks within three to five days; detailed report within 30 days; APPI promptly, then 30 or 60 days). Use the interministerial report formats.
3. Start the asset list from systems, not spreadsheets. For each critical system, record product name, manufacturer, category (appliance, software, cloud service, other), and the software running on it with versions. Use the system diagram the notification needs as your scope boundary.
4. Generate SBOMs for in-house software. Start with the applications on your critical systems. Use SPDX or CycloneDX, generated in the build so they stay current.
5. List your third parties. For each: name, what they provide, their access to your systems, and the type, sensitivity and location of your data they hold. That is the FSA's section 2.6(5) list and the starting point for APPI Article 25.

A template for the incident clock:

Days 31 to 60: turn inventory into decisions

1. Match SBOMs to vulnerability data daily. Enrich with CISA KEV and EPSS so severity is not the only signal.
2. Set patch deadlines by criticality. Write a deadline table that crosses system criticality with vulnerability severity, as section 2.2.3(3) asks, and keep records of status.
3. Build the exception path. Any patch you will not apply on time needs a documented risk assessment and senior management approval. Make that a form, not an email thread.
4. Ask suppliers for SBOMs and vulnerability statements. Start with suppliers on critical systems. Ask for SPDX or CycloneDX, and for VEX or CSAF statements on whether listed vulnerabilities affect the product.
5. Rewrite contract terms at renewal. Add the FSA's list: audit rights, subcontracting, incident reporting, reporting when serious vulnerabilities are found, vulnerability assessments, and data location and disposal.
6. Inventory AI. List AI SDKs, models, agents and AI services in your systems and treat them as software assets and third parties.

Days 61 to 90: make it repeatable and auditable

1. Gate releases. Stop builds that introduce known exploited vulnerabilities or unapproved licenses on critical systems, with a time-boxed exception route.
2. Run a reporting drill. Take a ransomware scenario on one critical system and time the first report against the three-to-five-day window. Check that you can name the affected software and version from your records.
3. File or prepare the asset notification. For computers in use on 1 October 2026 the deadline is 31 March 2027. Leave time for the ministry's questions.
4. Map evidence to clauses. For each FSA section, APPI article and ISMAP control that applies to you, link the evidence and its owner.
5. Report to the board. Coverage of SBOMs on critical systems, open critical vulnerabilities past deadline, exceptions signed, suppliers without SBOMs, and the drill result.

Illustrative scenario: a bank finds that 12 of its 40 critical systems run contractor-managed software it cannot version. It records them as "other", as the explainer allows, and makes SBOM delivery a renewal condition. The numbers are invented.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh, and every capability named is GA. Safeguard helps a team produce and keep the evidence these rules ask for. It does not make an organisation compliant, and it holds no Japanese certification, registration or listing, including ISMAP.

1. Choose where Safeguard runs. SaaS is multi-region (US, EU and Gov); there is no Japan region. For teams that need code and data to stay inside their own perimeter, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped deployment with the AI models running inside your environment and signed offline snapshot delivery. The air-gapped deployment docs describe a receiver that verifies signed bundles and a control plane in which no component calls outbound, which suits designated operators that keep critical systems off the internet.
2. Keep source code on your machines. The Safeguard CLI (GA) installs with curl -fsSL https://cli.safeguard.sh/install | bash. safeguard scan builds an SBOM and matches it against vulnerability databases, and safeguard validate checks CycloneDX, SPDX and VEX documents. The local runner (GA) is part of the CLI: sign in with /login, and the machine polls the platform for jobs, runs scans locally and uploads only the SBOM and findings, never source code. All traffic is outbound HTTPS that the runner opens. Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) lets you use an approved provider instead.
3. Generate SBOMs for every critical system. SBOM generation and analysis (GA) produces SPDX and CycloneDX from connected repositories, container registries, uploaded manifests and AI models, with continuous scanning on push, on schedule or on release. These SBOMs are the version-level detail behind an asset notification and the FSA's recommended SBOM.
4. Turn on the Japan framework pages. In Compliance, the Japan METI SBOM Guidelines, Japan APPI and Japan ISMAP frameworks are on unless you switch them off in Compliance › Manage. Each product scan checks requirements such as JP-METI-NAMEVER (component name and version), JP-METI-SUP (supplier) and JP-METI-VULN (use for vulnerability management); JP-APPI-23-INV (knowing which components handle personal data) and JP-APPI-26 (breach reporting readiness); and JP-ISMAP-ASSET and JP-ISMAP-SUP. Catalog controls sit alongside, with templates such as an SBOM Lifecycle Management Policy and an APPI Cross-Border Personal Data Transfer Policy. The Compliance and GRC suite (GA) keeps controls, evidence, tests, questionnaires, risks and vendors in one place. There is no dedicated framework page for the FSA guidelines or the Active Cyber Defense law, so map those sections to controls yourself.
5. Rank and fix vulnerabilities. SCA with deep transitive dependency scanning (GA) and vulnerability management with EPSS and CISA KEV enrichment (GA) give you the list. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, which helps you set FSA-style deadlines on the findings that matter. Autonomous remediation (GA) opens tested, policy-gated upgrade pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.
6. Gate releases and record exceptions. Policies, gates and guardrails (GA) evaluate scans with Block, Warn and Notify actions, and approvals run through time-boxed exceptions, which gives you the record section 2.2.3(3) asks for when a patch is deferred. Policies can be written in plain English. License compliance (GA) covers SPDX expressions and attribution.
7. Collect supplier SBOMs. In the Third-Party Risk Manager (GA), SBOM requests go to one vendor or many with format requirements, automatic reminders, format and completeness validation, an automatic vulnerability scan on receipt and a correction request when an SBOM falls short. CSAF and VEX upload (GA) puts a supplier's exploitability statements next to the findings. This supports the FSA's section 2.6 monitoring and the supplier questions in an introduction plan.
8. Stop risky packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build.
9. Inventory and govern AI. AI-BOM discovery (GA) finds AI SDK imports, model weight files, prompts, notebooks, MCP server configuration, managed inference endpoints, vector stores and agents, and assembles them into an AI-BOM. AI-SPM (GA) scans model artifacts. AI Gateway (GA) puts prompt injection, jailbreak and PII egress guardrails in front of LLM calls, MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access. That turns AI into assets and third parties you can list under the FSA guidelines and APPI.
10. Answer customers once. Trust Center (GA) publishes your security posture and answers questionnaires, which helps suppliers facing questions from designated operators and banks. Safeguard's own posture wording is "SOC 2 Type II audit in progress" and "designed for FedRAMP High".

What Safeguard does not do

• It does not file reports for you. The Active Cyber Defense first and detailed reports, the asset notification and APPI reports to the PPC are your organisation's duties. Safeguard can hold the procedure, findings and software versions that feed a report; a person files it.
• It does not make or screen introduction plans. Economic Security Promotion Act filings, and the ministry's screening, sit outside any tool. Safeguard can supply SBOMs and supplier data you attach.
• It has no Japan SaaS region and no ISMAP registration. If you need everything inside your own environment, use private VPC or dedicated tenancy, on-prem or air-gapped deployment, or the local runner.
• It does not inventory hardware or appliances for you. The asset notification covers appliances and contractor-managed systems that no software scan can see. Your CMDB and network diagrams stay the source for those.
• It does not replace penetration tests or JC-STAR assessment. The FSA's section 2.2.4 testing and any third-party label assessment need their own testers. Safeguard's scanners support that work.
• It does not interpret the law. Framework pages map requirements to evidence. Whether a clause applies to you is a question for counsel or your competent ministry.

Common mistakes

• Treating the asset notification as a hardware list. The explainer says the program on the computer counts. A list without software and versions will not support the government's vulnerability warnings.
• Starting the reporting clock at confirmation, not awareness. Both the Active Cyber Defense deadlines and the APPI deadlines run from awareness or discovery.
• Reading "recommended" as optional forever. The FSA's SBOM item is a recommended measure today. Supervisors still ask how you identify affected systems promptly, and an SBOM is how most teams answer.
• Signing supplier contracts without vulnerability terms. Section 2.6(8) lists reporting when serious vulnerabilities are found. Add it at renewal, not after the next incident.
• Forgetting contractor-managed and overseas systems. The FSA puts group companies, overseas offices and contractor-managed assets in scope.
• Leaving AI out of the inventory. No AI law forces it, but AI services handle personal data and run on critical systems like any other software.

FAQ

What is Japan's Active Cyber Defense law?

It is Act No. 42 of 2025, formally the Act on the Prevention of Damage Caused by Unauthorized Acts against Important Electronic Computers (our translation). It makes designated essential infrastructure operators notify their critical computers and report cyber incidents to the government, sets up a public-private council, and allows access and neutralization measures against attack servers. The reporting and notification duties apply from 1 October 2026.

How fast must a cyber incident be reported in Japan?

For designated operators under the Active Cyber Defense law: a first report promptly (DDoS as soon as possible, ransomware and other attacks within three to five days of awareness) and a detailed report within 30 days. For personal data leaks under APPI: promptly to the PPC, then a full report within 30 days, or 60 days where the leak may have been caused with unauthorized intent.

Is an SBOM mandatory in Japan?

Not by statute. The FSA lists SBOMs for in-house software as a recommended measure for financial institutions, and METI's SBOM guide is voluntary. The Active Cyber Defense law's asset notification asks for product names and manufacturers, and SBOMs are the practical way to keep that list accurate down to software versions.

Who must file an asset notification, and by when?

Designated operators, for each specified important computer. Computers already in use on 1 October 2026 must be notified by 31 March 2027; new ones within four months of installation.

Does the Economic Security Promotion Act affect software suppliers?

Yes, indirectly. Designated operators must name the suppliers of critical facilities and their components, and all contractors and subcontractors for critical maintenance, in an introduction plan that a ministry screens before installation.

Does Japan have an AI law?

Yes, the AI Promotion Act (Act No. 53 of 2025), fully in force since 1 September 2025. It promotes AI and asks businesses to cooperate with government measures; it has no AI-specific fines. The AI Basic Plan was adopted on 23 December 2025 and revised on 14 July 2026.

Must data be stored in Japan?

None of the rules covered here imposes a general localization duty. APPI Article 28 restricts transfers to third parties abroad, and the FSA wants data location agreed in third-party contracts. Check sector rules that apply to you.

Can Safeguard run without our code leaving Japan?

Yes, through deployment rather than a Japan region. The local runner scans on your machines and uploads only SBOMs and findings. On-prem and air-gapped deployments keep the whole platform, including the AI models, inside your environment, and Zero AI mode removes LLMs from the loop.

Before you fix anything

Every rule in this guide comes back to one question: when a component in a critical system is vulnerable, how fast does the fix reach production, and what do you do when no fix exists yet? The section below covers how Safeguard closes both gaps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session that fixes a vulnerable dependency in a repository. It reads the finding and advisory, asks before any command that changes something, edits the manifest, runs the install and tests with approval, and pushes nothing. That is the shape of a deadline-driven fix under the FSA's section 2.2.3.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it, and scans from the terminal. For Japanese banks and designated operators that will not grant repository access to an outside platform, this is how SBOMs and findings are produced while source code stays on your systems.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It shows the kind of scoped agent access worth inventorying as AI tools spread through engineering teams.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Cabinet Office: Cyber security (Active Cyber Defense law documents)
• Cabinet Office and NCO: Enforcement of the Cyber Response Capability Enhancement Act, September 2026
• Joint ministerial explainer on asset notification and incident reporting, 1 October 2026
• Cabinet Office: Essential infrastructure system under the Economic Security Promotion Act
• Cabinet Office: System for Ensuring Stable Provision of Specified Essential Infrastructure Services, July 2026 (tentative translation)
• National Cybersecurity Office
• FSA: Guidelines on Cybersecurity for the Financial Sector, 4 October 2024 (provisional translation)
• Digital Agency: ISMAP-LIU
• MIC: Commencement of ISMAP-LIU operation, 1 November 2022
• Japanese Law Translation: Act on the Protection of Personal Information
• PPC: Responding to personal data leaks
• Japanese Law Translation: AI Promotion Act
• Cabinet Office: Outline of the AI Act
• Cabinet Office: AI Basic Plan
• IPA: Japan Cyber STAR (JC-STAR)
• National Police Agency: Alert on cyberattacks by MirrorFace, 8 January 2025
• Yamato Holdings: Fourth report on unauthorized access to the Kuroneko deferred payment service
• Nikkei Inc.: Personal information leak caused by unauthorized access
• Safeguard docs: Japan METI SBOM Guidelines framework
• Safeguard docs: Japan APPI framework
• Safeguard docs: Japan ISMAP framework
• Safeguard docs: Safeguard CLI
• Safeguard docs: Local runner
• Safeguard docs: Air-gapped deployment
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: AI-BOM discovery
• Safeguard docs: Compliance

Related reading: Japan's cybersecurity rules and the software supply chain, Active Cyber Defense law incident reporting from October 2026 and AMED software supply chain guidance.

To try it, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.