Vendere software alle infrastrutture critiche giapponesi

Che cosa è cambiato il 1° ottobre 2026

Le due novità vengono spesso descritte come una sola, ma hanno basi giuridiche e destinatari diversi.

	Legge sulla difesa cibernetica attiva	Standard unificati
Che cos'è	Legge n. 42 del 2025, in giapponese サイバー対処能力強化法	Uno standard adottato dal Cybersecurity Strategic Headquarters il 31 luglio 2026
A chi si rivolge	Operatori designati di infrastrutture fondamentali (基幹インフラ)	Enti pubblici e, tramite loro, operatori di 16 settori di infrastrutture critiche
Che cosa chiede	Notificare gli asset chiave e segnalare gli incidenti al governo	Misure di sicurezza trasversali, dalla governance e dal rischio della supply chain alla gestione delle vulnerabilità
Come vincola	Obblighi di legge con sanzioni	Non ha efficacia cogente di per sé. Raggiunge gli operatori tramite gli standard di sicurezza di ciascun settore

I 16 settori sono informazione e comunicazioni, finanza, aviazione, aeroporti, ferrovie, energia elettrica, gas, servizi governativi, servizi sanitari, acqua, logistica, chimica, credito, petrolio, porti e servizi postali.

Oltre agli standard, il National Cybersecurity Office giapponese ha pubblicato linee guida per la redazione di questi standard di sicurezza, anch'esse in vigore dal 1° ottobre. Sono il documento più utile per un fornitore, perché spiegano nel dettaglio che cosa ci si aspetta che gli operatori facciano nei confronti delle aziende da cui acquistano.

Perché questo riguarda i fornitori

Gli obblighi ricadono sull'operatore, quindi l'effetto per Lei è commerciale più che legale: arriva sotto forma di clausole contrattuali, criteri di procurement e questionari. Ciò che si applica a un determinato cliente dipende dal suo settore e dai suoi standard di sicurezza, quindi chieda al cliente invece di dare nulla per scontato.

Gli Standard unificati chiedono agli operatori di capire come i loro sistemi critici dipendono dalla supply chain, di conoscere la posizione di sicurezza dei fornitori e di definire requisiti di sicurezza quando acquistano prodotti e servizi. Le linee guida traducono tutto questo in punti specifici.

Che cosa possono chiederLe gli operatori

Le linee guida distinguono le misure che gli operatori dovrebbero adottare da quelle auspicabili. La tabella mostra entrambe, con la parte delle evidenze che può provenire dalla Sua build.

Che cosa descrivono le linee guida	Livello	Evidenze dalla build
Requisiti di sicurezza inseriti nei contratti, con esempi come la gestione e la segnalazione delle vulnerabilità gravi (2.9 ②-2)	Da adottare	Una registrazione di ogni vulnerabilità, dal triage alla release corretta
I fornitori dei sistemi acquistati segnalano, gestiscono e divulgano le vulnerabilità nell'ambito del contratto di manutenzione (3.6 ①-2)	Da adottare	Il monitoraggio continuo di ciò che ha distribuito e delle release interessate da ogni vulnerabilità
Un modo per condividere rapidamente le informazioni con il fornitore quando viene individuata una vulnerabilità o un incidente (2.9 ③-3)	Da adottare	Una cronologia delle build che mostra quali release contengono un pacchetto
Quando il procurement richiede trasparenza, chiedere al fornitore di creare e fornire una SBOM (2.9 ③-4)	Auspicabile	Una SBOM di ogni build, esportata in CycloneDX o SPDX
Verificare che il fornitore sviluppi secondo pratiche di sviluppo sicuro del software (2.9 ③-4)	Auspicabile	Job di build isolati e una policy di egress applicata

Il Giappone richiede una SBOM?

Non in base agli Standard unificati, che non menzionano le SBOM. Le linee guida le indicano come un'opzione: un operatore che ha bisogno di trasparenza nel procurement può chiedere a un fornitore di crearne e fornirne una, e rimandano alla guida SBOM del METI, versione 2.0. Probabilmente conviene comunque soddisfare una richiesta di questo tipo, perché un contratto può rendere un'opzione vincolante per Lei.

Altri aspetti che il Suo cliente può valutare

• Valutazione di terze parti. Le linee guida suggeriscono di ricorrere a valutazioni esterne per ridurre il lavoro di verifica dei fornitori. Citano la valutazione di conformità ISMS e lo schema di valutazione SCS del METI e del National Cybersecurity Office, il cui avvio è previsto intorno alla fine dell'anno fiscale giapponese 2026.
• Schemi per prodotti e servizi. Indirizzano inoltre gli operatori verso JC-STAR per i prodotti IoT, ISMAP per i servizi cloud e JISEC per i prodotti IT quando definiscono i criteri di selezione.
• Valutazioni delle vulnerabilità. Gli operatori svolgono valutazioni periodiche dei propri sistemi e le clausole contrattuali possono estendere a Lei valutazione e segnalazione.
• Clausole sui dati. I contratti possono disciplinare dove i dati si trovano e come vengono archiviati, conservati, trasferiti ed eliminati.

Che cosa significa se si sta già preparando al CRA

Gran parte del lavoro è riutilizzabile. Il Cyber Resilience Act dell'UE è un regime distinto con obblighi propri, quindi rispettarlo non soddisfa ciò che chiede un cliente giapponese. Ma entrambi si riducono alle stesse domande: che cosa c'è nel software che ha distribuito, quali release sono interessate da una vulnerabilità e che cosa ha fatto al riguardo. Se queste risposte vengono dalla Sua build, può riutilizzarle per un cliente giapponese invece di raccoglierle di nuovo.

Il ruolo di CRACI

CRACI registra ciò che ogni job di GitHub Actions ha effettivamente scaricato e produce una SBOM dalla build, poi monitora ciò che è stato distribuito e traccia le vulnerabilità dal triage a una release corretta. Questo Le fornisce evidenze per le richieste della tabella qui sopra.

CRACI copre solo una parte di ciò che un operatore può aspettarsi. Non esegue valutazioni delle vulnerabilità né penetration test, non applica patch ai sistemi distribuiti e non effettua segnalazioni alle autorità giapponesi. Non La rende conforme ad alcuno standard di settore. CRACI è ospitato in Europa e ISO/IEC 27001 è l'unica certificazione che possiede, quindi verifichi entrambi gli aspetti rispetto alle clausole sui dati e ai criteri di selezione del Suo cliente.

Infrastrutture critiche in Giappone: domande frequenti

La legge giapponese sulla difesa cibernetica attiva si applica ai vendor di software stranieri?

Gli obblighi di notifica e di segnalazione degli incidenti ricadono sugli operatori di infrastrutture designati. È più probabile che un fornitore ne avverta gli effetti attraverso ciò che questi clienti chiedono nei contratti, quindi verifichi con il cliente e con il Suo consulente legale.

Gli Standard unificati sono obbligatori?

Non di per sé. Si rivolgono principalmente agli enti pubblici e stabiliscono che cosa dovrebbero contenere gli standard di sicurezza di settore, quindi ciò che vincola un operatore dipende dal suo settore.

Quali settori sono interessati?

Sedici: informazione e comunicazioni, finanza, aviazione, aeroporti, ferrovie, energia elettrica, gas, servizi governativi, servizi sanitari, acqua, logistica, chimica, credito, petrolio, porti e servizi postali.

Il Giappone richiede una SBOM?

Non in base agli Standard unificati, che non menzionano le SBOM. Le linee guida per gli standard di sicurezza indicano la SBOM come qualcosa che un operatore può chiedere a un fornitore, e un contratto può renderla vincolante.

Che cosa chiede la sezione sulla gestione delle vulnerabilità?

La sezione 3.3.6 degli Standard unificati chiede agli operatori di verificare se le vulnerabilità riguardano i sistemi in esercizio, di valutare periodicamente i propri sistemi e di definire procedure di patching, tenendo conto del fatto che l'IA riduce il tempo tra la scoperta e lo sfruttamento.

La preparazione al CRA copre i requisiti giapponesi?

No, ma gran parte delle evidenze è riutilizzabile. Le SBOM, la registrazione delle release interessate da una vulnerabilità e quella di come è stata gestita sono utili in entrambi i casi.