Selge programvare til japansk kritisk infrastruktur

Dette ble endret 1. oktober 2026

De to endringene beskrives ofte som én, men de har ulikt rettslig grunnlag og ulike målgrupper.

	Active Cyber Defense-loven	Enhetlige standarder
Hva det er	Act No. 42 of 2025, på japansk サイバー対処能力強化法	En standard Cybersecurity Strategic Headquarters vedtok 31. juli 2026
Hvem det retter seg mot	Utpekte operatører av kjerneinfrastruktur (基幹インフラ)	Statlige myndigheter og, gjennom dem, operatører i 16 sektorer innen kritisk infrastruktur
Hva det ber om	Melding om viktige eiendeler og rapportering av hendelser til myndighetene	Sektorovergripende sikkerhetstiltak, fra styring og leverandørkjederisiko til sårbarhetshåndtering
Bindende virkning	Rettslige plikter med sanksjoner	Kan ikke håndheves i seg selv. Den når operatørene gjennom sikkerhetsstandardene i hver sektor

De 16 sektorene er informasjon og kommunikasjon, finans, luftfart, flyplasser, jernbane, elektrisk kraft, gass, offentlige tjenester, helsetjenester, vann, logistikk, kjemikalier, kreditt, olje, havner og posttjenester.

I tillegg til standardene har Japans National Cybersecurity Office publisert en veiledning for hvordan disse sikkerhetsstandardene skal skrives, som også gjelder fra 1. oktober. Den er det mest nyttige dokumentet for en leverandør, fordi den beskriver hva operatører forventes å gjøre med selskapene de kjøper fra.

Hvorfor dette når leverandørene

Forpliktelsene ligger hos operatøren, så virkningen for deg er kommersiell snarere enn rettslig: Den kommer som kontraktsvilkår, innkjøpskriterier og spørreskjemaer. Hva som gjelder for en bestemt kunde, avhenger av kundens sektor og egne sikkerhetsstandarder, så spør kunden i stedet for å anta.

De enhetlige standardene ber operatører forstå hvordan de kritiske systemene deres avhenger av leverandørkjeden, vite hvor leverandørene står på sikkerhet, og stille sikkerhetskrav når de kjøper produkter og tjenester. Veiledningen gjør dette om til konkrete punkter.

Hva operatører kan be deg om

Veiledningen skiller mellom tiltak operatører bør iverksette, og tiltak som er ønskelige. Tabellen viser begge, sammen med den delen av dokumentasjonen som kan komme fra bygget ditt.

Hva veiledningen beskriver	Nivå	Dokumentasjon fra bygget
Sikkerhetskrav skrevet inn i kontrakter, med eksempler som hvordan alvorlige sårbarheter håndteres og rapporteres (2.9 ②-2)	Bør iverksettes	En registrering av hver sårbarhet fra triage til rettet utgivelse
Leverandører av innkjøpte systemer rapporterer, håndterer og offentliggjør sårbarheter under vedlikeholdskontrakten (3.6 ①-2)	Bør iverksettes	Løpende overvåking av det du har levert, og utgivelsene hver sårbarhet berører
En måte å dele informasjon raskt med leverandøren på når en sårbarhet eller hendelse oppdages (2.9 ③-3)	Bør iverksettes	Byggehistorikk som viser hvilke utgivelser som inneholder en pakke
Der innkjøpet trenger åpenhet: å be leverandøren lage og levere en SBOM (2.9 ③-4)	Ønskelig	En SBOM fra hvert bygg, eksportert som CycloneDX eller SPDX
Å bekrefte at leverandøren utvikler etter sikre metoder for programvareutvikling (2.9 ③-4)	Ønskelig	Isolerte byggejobber og en håndhevet egress-policy

Krever Japan en SBOM?

Ikke etter de enhetlige standardene, som ikke nevner SBOM-er. Veiledningen nevner dem som et alternativ: En operatør som trenger åpenhet i innkjøpet, kan be en leverandør lage og levere en, og veiledningen viser til METIs SBOM-veiledning, versjon 2.0. Det er likevel trolig verdt å imøtekomme en slik forespørsel, fordi en kontrakt kan gjøre et alternativ bindende for deg.

Annet kunden din kan se etter

• Tredjepartsevaluering. Veiledningen foreslår å bruke eksterne evalueringer for å redusere arbeidet med å kontrollere leverandører. Den nevner ISMS-samsvarsvurdering og SCS-evalueringsordningen fra METI og National Cybersecurity Office, som etter planen starter rundt slutten av det japanske budsjettåret 2026.
• Ordninger for produkter og tjenester. Den viser også operatører til JC-STAR for IoT-produkter, ISMAP for skytjenester og JISEC for IT-produkter når de fastsetter utvalgskriterier.
• Sårbarhetsvurderinger. Operatører vurderer egne systemer jevnlig, og kontraktsvilkår kan utvide vurdering og rapportering til å omfatte deg.
• Datavilkår. Kontrakter kan omfatte hvor data befinner seg, og hvordan de lagres, oppbevares, overføres og avhendes.

Dette betyr det hvis du allerede forbereder deg på CRA

Mye av arbeidet kan gjenbrukes. EUs Cyber Resilience Act er et eget regelverk med egne forpliktelser, så samsvar med den oppfyller ikke det en japansk kunde ber om. Men begge handler om de samme spørsmålene: hva som finnes i programvaren du leverte, hvilke utgivelser en sårbarhet berører, og hva du gjorde med den. Hvis svarene kommer fra bygget ditt, kan du gjenbruke dem for en japansk kunde i stedet for å sette dem sammen på nytt.

Her passer CRACI inn

CRACI registrerer hva hver GitHub Actions-jobb faktisk hentet inn, og lager en SBOM fra bygget. Deretter overvåker CRACI det som er levert, og sporer sårbarheter fra triage til en rettet utgivelse. Det gir deg dokumentasjon for forespørslene i tabellen over.

Det dekker bare en del av det en operatør kan forvente. CRACI utfører ikke sårbarhetsvurderinger eller penetrasjonstester, patcher ikke utrullede systemer og rapporterer ikke til japanske myndigheter. CRACI sørger ikke for at du oppfyller noen sektorstandard. CRACI hostes i Europa, og ISO/IEC 27001 er den eneste sertifiseringen det har, så sjekk begge deler mot kundens datavilkår og utvalgskriterier.

Kritisk infrastruktur i Japan: ofte stilte spørsmål

Gjelder Japans Active Cyber Defense-lov for utenlandske programvareleverandører?

Pliktene til å melde fra og rapportere hendelser ligger hos utpekte infrastrukturoperatører. En leverandør vil trolig heller merke loven gjennom det disse kundene ber om i kontrakter, så avklar med kunden og med din juridiske rådgiver.

Er de enhetlige standardene obligatoriske?

Ikke i seg selv. De retter seg hovedsakelig mot statlige myndigheter og beskriver hva sikkerhetsstandardene i sektorene bør inneholde, så hva som binder en operatør, avhenger av sektoren.

Hvilke sektorer er omfattet?

Seksten: informasjon og kommunikasjon, finans, luftfart, flyplasser, jernbane, elektrisk kraft, gass, offentlige tjenester, helsetjenester, vann, logistikk, kjemikalier, kreditt, olje, havner og posttjenester.

Krever Japan en SBOM?

Ikke etter de enhetlige standardene, som ikke nevner SBOM-er. Veiledningen for sikkerhetsstandarder nevner en SBOM som noe en operatør kan be en leverandør om, og en kontrakt kan gjøre det bindende.

Hva ber avsnittet om sårbarhetshåndtering om?

Avsnitt 3.3.6 i de enhetlige standardene ber operatører sjekke om sårbarheter berører systemer i drift, vurdere systemene sine jevnlig og fastsette prosedyrer for patching, og ta hensyn til at AI forkorter tiden fra oppdagelse til utnyttelse.

Dekker CRA-forberedelser de japanske kravene?

Nei, men mye av dokumentasjonen kan gjenbrukes. SBOM-er, registreringen av hvilke utgivelser en sårbarhet berører, og registreringen av hvordan den ble håndtert, er nyttige i begge tilfeller.