Cadeia de abastecimento
Vender software a infraestruturas críticas japonesas
Duas alterações japonesas em matéria de cibersegurança entraram em vigor a 1 de outubro de 2026. Nenhuma se dirige a fornecedores de software estrangeiros, mas ambas elevam o que os operadores de infraestruturas críticas esperam das empresas que os abastecem. Eis o que mudou, o que os seus clientes podem agora pedir à sua empresa e a quais desses pedidos o seu build pode responder.
Atualizado a
O que mudou a 1 de outubro de 2026
As duas alterações são muitas vezes descritas como uma só, mas têm bases jurídicas e destinatários diferentes.
| Lei de ciberdefesa ativa | Normas Unificadas | |
|---|---|---|
| O que é | Act No. 42 of 2025, em japonês サイバー対処能力強化法 | Uma norma adotada pelo Cybersecurity Strategic Headquarters a 31 de julho de 2026 |
| A quem se dirige | Operadores designados de infraestruturas fundamentais (基幹インフラ) | Organismos públicos e, através deles, operadores de 16 setores de infraestruturas críticas |
| O que pede | Notificar os ativos-chave e comunicar incidentes ao governo | Medidas de segurança transversais, da governação e do risco da cadeia de abastecimento à gestão de vulnerabilidades |
| Como vincula | Deveres legais com sanções | Não são exigíveis por si só. Chegam aos operadores através das normas de segurança de cada setor |
Os 16 setores são informação e comunicações, finanças, aviação, aeroportos, caminhos de ferro, energia elétrica, gás, serviços governamentais, serviços médicos, água, logística, química, crédito, petróleo, portos e serviços postais.
A par das normas, o National Cybersecurity Office do Japão publicou orientações para a redação dessas normas de segurança, também em vigor desde 1 de outubro. São o documento mais útil para um fornecedor, porque detalham o que se espera que os operadores façam em relação às empresas a quem compram.
Porque é que isto chega aos fornecedores
As obrigações recaem sobre o operador, pelo que o efeito na sua empresa é mais comercial do que jurídico: chega sob a forma de cláusulas contratuais, critérios de aquisição e questionários. O que se aplica a um determinado cliente depende do seu setor e das suas próprias normas de segurança, por isso pergunte ao cliente em vez de presumir.
As Normas Unificadas pedem aos operadores que compreendam como os seus sistemas críticos dependem da cadeia de abastecimento, que saibam qual a situação de segurança dos seus fornecedores e que definam requisitos de segurança quando compram produtos e serviços. As orientações traduzem isso em pontos específicos.
O que os operadores podem pedir à sua empresa
As orientações separam as medidas que os operadores deveriam adotar das medidas desejáveis. A tabela mostra ambas, com a parte das evidências que pode vir do seu build.
| O que as orientações descrevem | Nível | Evidências do build |
|---|---|---|
| Requisitos de segurança incluídos nos contratos, com exemplos como a forma de tratar e comunicar vulnerabilidades graves (2.9 ②-2) | A adotar | Um registo de cada vulnerabilidade, da triagem à versão corrigida |
| Os fornecedores de sistemas adquiridos comunicam, tratam e divulgam vulnerabilidades ao abrigo do contrato de manutenção (3.6 ①-2) | A adotar | Monitorização contínua do que lançou e das versões afetadas por cada vulnerabilidade |
| Uma forma de partilhar rapidamente informação com o fornecedor quando é detetada uma vulnerabilidade ou um incidente (2.9 ③-3) | A adotar | Um histórico de builds que mostra que versões contêm um pacote |
| Quando a aquisição exige transparência, pedir ao fornecedor que crie e entregue uma SBOM (2.9 ③-4) | Desejável | Uma SBOM de cada build, exportada em CycloneDX ou SPDX |
| Confirmar que o fornecedor desenvolve segundo práticas de desenvolvimento seguro de software (2.9 ③-4) | Desejável | Jobs de build isolados e uma política de egress aplicada |
O Japão exige uma SBOM?
Não ao abrigo das Normas Unificadas, que não mencionam as SBOM. As orientações referem-nas como uma opção: um operador que precise de transparência na aquisição pode pedir a um fornecedor que crie e entregue uma, e remetem para o guia SBOM do METI, versão 2.0. Ainda assim, é provável que valha a pena satisfazer esse pedido, porque um contrato pode tornar uma opção vinculativa para a sua empresa.
Outros aspetos que o seu cliente pode procurar
- Avaliação por terceiros. As orientações sugerem o recurso a avaliações externas para reduzir o trabalho de verificar os fornecedores. Referem a avaliação de conformidade ISMS e o esquema de avaliação SCS do METI e do National Cybersecurity Office, cujo início está previsto para perto do final do ano fiscal japonês de 2026.
- Esquemas para produtos e serviços. Remetem também os operadores para o JC-STAR para produtos IoT, o ISMAP para serviços cloud e o JISEC para produtos de TI, ao definirem critérios de seleção.
- Avaliações de vulnerabilidades. Os operadores fazem avaliações periódicas dos seus próprios sistemas, e as cláusulas contratuais podem alargar a avaliação e a comunicação à sua empresa.
- Condições sobre dados. Os contratos podem regular onde os dados estão localizados, armazenados, conservados, transferidos e eliminados.
O que isto significa se já se prepara para o CRA
Grande parte do trabalho é aproveitável. O Cyber Resilience Act da UE é um regime distinto com obrigações próprias, pelo que cumpri-lo não satisfaz o que um cliente japonês pede. Mas ambos se resumem às mesmas perguntas: o que está no software que lançou, que versões uma vulnerabilidade afeta e o que fez em relação a isso. Se essas respostas vierem do seu build, pode reutilizá-las para um cliente japonês em vez de as reunir novamente.
Qual é o papel do CRACI
O CRACI regista o que cada job de GitHub Actions efetivamente obteve e produz uma SBOM a partir do build, depois monitoriza o que foi lançado e acompanha as vulnerabilidades, da triagem a uma versão corrigida. Isso dá-lhe evidências para os pedidos da tabela acima.
Cobre apenas parte do que um operador pode esperar. O CRACI não faz avaliações de vulnerabilidades nem testes de intrusão, não aplica patches em sistemas implementados e não reporta às autoridades japonesas. Não torna a sua empresa conforme com nenhuma norma setorial. O CRACI está alojado na Europa e a ISO/IEC 27001 é a única certificação que detém, por isso confirme ambos os pontos face às condições sobre dados e aos critérios de seleção do seu cliente.
Infraestruturas críticas no Japão: perguntas frequentes
A lei japonesa de ciberdefesa ativa aplica-se a fornecedores de software estrangeiros?
Os seus deveres de notificação e de comunicação de incidentes recaem sobre os operadores de infraestruturas designados. É mais provável que um fornecedor a sinta através do que esses clientes pedem nos contratos, por isso confirme com o cliente e com o seu consultor jurídico.
As Normas Unificadas são obrigatórias?
Não por si só. Dirigem-se sobretudo a organismos públicos e estabelecem o que as normas de segurança setoriais deveriam conter, pelo que o que vincula um operador depende do seu setor.
Que setores são abrangidos?
Dezasseis: informação e comunicações, finanças, aviação, aeroportos, caminhos de ferro, energia elétrica, gás, serviços governamentais, serviços médicos, água, logística, química, crédito, petróleo, portos e serviços postais.
O Japão exige uma SBOM?
Não ao abrigo das Normas Unificadas, que não mencionam as SBOM. As orientações para as normas de segurança referem a SBOM como algo que um operador pode pedir a um fornecedor, e um contrato pode torná-lo vinculativo.
O que pede a secção sobre gestão de vulnerabilidades?
A secção 3.3.6 das Normas Unificadas pede aos operadores que verifiquem se as vulnerabilidades afetam sistemas em funcionamento, avaliem periodicamente os seus sistemas e definam procedimentos de aplicação de patches, tendo em conta que a IA encurta o tempo entre a descoberta e a exploração.
A preparação para o CRA cobre os requisitos japoneses?
Não, mas grande parte das evidências é aproveitável. As SBOM, o registo das versões afetadas por uma vulnerabilidade e o registo de como foi tratada são úteis em ambos os casos.
Evidências que os seus clientes podem pedir
Obtenha SBOM e registos de vulnerabilidades de cada job de GitHub Actions, sem os escrever à mão.
Marcar demo