Vender software a infraestructuras críticas japonesas

Qué cambió el 1 de octubre de 2026

Los dos cambios suelen describirse como uno solo, pero tienen distinta base jurídica y distintos destinatarios.

	Ley de ciberdefensa activa	Normas Unificadas
Qué es	Act No. 42 of 2025, en japonés サイバー対処能力強化法	Una norma adoptada por el Cybersecurity Strategic Headquarters el 31 de julio de 2026
A quién se dirige	Operadores designados de infraestructuras básicas (基幹インフラ)	Organismos públicos y, a través de ellos, operadores de 16 sectores de infraestructuras críticas
Qué pide	Notificar los activos clave y comunicar los incidentes al Gobierno	Medidas de seguridad transversales, desde la gobernanza y el riesgo de la cadena de suministro hasta la gestión de vulnerabilidades
Cómo vincula	Obligaciones legales con sanciones	No son exigibles por sí mismas. Llegan a los operadores a través de las normas de seguridad de cada sector

Los 16 sectores son información y comunicaciones, finanzas, aviación, aeropuertos, ferrocarriles, energía eléctrica, gas, servicios gubernamentales, servicios médicos, agua, logística, química, crédito, petróleo, puertos y servicios postales.

Junto con las normas, el National Cybersecurity Office de Japón publicó unas directrices para redactar esas normas de seguridad, también vigentes desde el 1 de octubre. Son el documento más útil para un proveedor, porque detallan lo que se espera que los operadores hagan respecto a las empresas a las que compran.

Por qué esto afecta a los proveedores

Las obligaciones recaen en el operador, de modo que el efecto para usted es comercial más que legal: llega en forma de cláusulas contractuales, criterios de compra y cuestionarios. Lo que se aplica a un cliente concreto depende de su sector y de sus propias normas de seguridad, así que pregúntele al cliente en lugar de darlo por supuesto.

Las Normas Unificadas piden a los operadores que entiendan cómo dependen sus sistemas críticos de la cadena de suministro, que sepan en qué situación de seguridad están sus proveedores y que fijen requisitos de seguridad cuando compren productos y servicios. Las directrices lo concretan en puntos específicos.

Qué pueden pedirle los operadores

Las directrices separan las medidas que los operadores deberían adoptar de las que son deseables. La tabla muestra ambas, junto con la parte de la evidencia que puede salir de su build.

Qué describen las directrices	Nivel	Evidencia del build
Requisitos de seguridad incluidos en los contratos, con ejemplos como la forma de gestionar y notificar las vulnerabilidades graves (2.9 ②-2)	Debería adoptarse	Un registro de cada vulnerabilidad, desde el triaje hasta la versión corregida
Los proveedores de sistemas adquiridos notifican, gestionan y divulgan las vulnerabilidades en virtud del contrato de mantenimiento (3.6 ①-2)	Debería adoptarse	Supervisión continua de lo que ha distribuido y de las versiones a las que afecta cada vulnerabilidad
Una forma de compartir información rápidamente con el proveedor cuando se detecta una vulnerabilidad o un incidente (2.9 ③-3)	Debería adoptarse	Un historial de builds que muestra qué versiones contienen un paquete
Cuando la compra requiere transparencia, pedir al proveedor que cree y entregue una SBOM (2.9 ③-4)	Deseable	Una SBOM de cada build, exportada en CycloneDX o SPDX
Confirmar que el proveedor desarrolla con prácticas de desarrollo seguro de software (2.9 ③-4)	Deseable	Jobs de build aislados y una política de egress aplicada

¿Exige Japón una SBOM?

No según las Normas Unificadas, que no mencionan las SBOM. Las directrices las citan como una opción: un operador que necesite transparencia en sus compras puede pedir a un proveedor que cree y entregue una, y remiten a la guía de SBOM del METI, versión 2.0. Aun así, probablemente merezca la pena atender esa solicitud, porque un contrato puede hacer que una opción sea vinculante para usted.

Otros aspectos que su cliente puede tener en cuenta

• Evaluación por terceros. Las directrices sugieren recurrir a evaluaciones externas para reducir el trabajo de comprobar a los proveedores. Citan la evaluación de conformidad ISMS y el esquema de evaluación SCS del METI y del National Cybersecurity Office, cuyo inicio está previsto hacia finales del año fiscal 2026 de Japón.
• Esquemas para productos y servicios. También remiten a los operadores a JC-STAR para productos IoT, ISMAP para servicios en la nube y JISEC para productos de TI a la hora de fijar criterios de selección.
• Evaluaciones de vulnerabilidades. Los operadores evalúan periódicamente sus propios sistemas, y las cláusulas contractuales pueden extender esa evaluación y la notificación a usted.
• Condiciones sobre datos. Los contratos pueden regular dónde se ubican, almacenan, conservan, transfieren y eliminan los datos.

Qué significa esto si ya se prepara para el CRA

Gran parte del trabajo es reutilizable. El Cyber Resilience Act de la UE es un régimen independiente con obligaciones propias, por lo que cumplirlo no satisface lo que pide un cliente japonés. Pero ambos se reducen a las mismas preguntas: qué contiene el software que distribuyó, a qué versiones afecta una vulnerabilidad y qué hizo al respecto. Si esas respuestas salen de su build, puede reutilizarlas para un cliente japonés en lugar de recopilarlas de nuevo.

Qué papel tiene CRACI

CRACI registra lo que cada job de GitHub Actions descargó realmente y produce una SBOM a partir del build; después supervisa lo que se ha distribuido y hace el seguimiento de las vulnerabilidades, desde el triaje hasta una versión corregida. Eso le proporciona evidencia para las solicitudes de la tabla anterior.

CRACI cubre solo una parte de lo que un operador puede esperar. No realiza evaluaciones de vulnerabilidades ni pruebas de penetración, no aplica parches en sistemas desplegados y no informa a las autoridades japonesas. No garantiza que cumpla ninguna norma sectorial. CRACI está alojado en Europa, e ISO/IEC 27001 es la única certificación que posee, así que compruebe ambos puntos con las condiciones sobre datos y los criterios de selección de su cliente.

Infraestructuras críticas en Japón: preguntas frecuentes

¿Se aplica la ley japonesa de ciberdefensa activa a los proveedores de software extranjeros?

Sus obligaciones de notificación y de comunicación de incidentes recaen en los operadores de infraestructuras designados. Es más probable que un proveedor la note a través de lo que esos clientes piden en los contratos, así que consulte con el cliente y con su asesor jurídico.

¿Son obligatorias las Normas Unificadas?

No por sí mismas. Se dirigen principalmente a los organismos públicos y establecen lo que deberían contener las normas de seguridad sectoriales, de modo que lo que vincula a un operador depende de su sector.

¿Qué sectores abarcan?

Dieciséis: información y comunicaciones, finanzas, aviación, aeropuertos, ferrocarriles, energía eléctrica, gas, servicios gubernamentales, servicios médicos, agua, logística, química, crédito, petróleo, puertos y servicios postales.

¿Exige Japón una SBOM?

No según las Normas Unificadas, que no mencionan las SBOM. Las directrices para las normas de seguridad citan la SBOM como algo que un operador puede pedir a un proveedor, y un contrato puede hacerlo vinculante.

¿Qué pide la sección de gestión de vulnerabilidades?

La sección 3.3.6 de las Normas Unificadas pide a los operadores que comprueben si las vulnerabilidades afectan a los sistemas en funcionamiento, que evalúen periódicamente sus sistemas y que establezcan procedimientos de parcheo, teniendo en cuenta que la IA acorta el tiempo entre el descubrimiento y la explotación.

¿La preparación para el CRA cubre los requisitos japoneses?

No, pero gran parte de la evidencia es reutilizable. Las SBOM, el registro de las versiones a las que afecta una vulnerabilidad y el registro de cómo se gestionó son útiles en ambos casos.