Sælg software til japansk kritisk infrastruktur

Det ændrede sig den 1. oktober 2026

De to ændringer beskrives ofte som én, men de har forskelligt retsgrundlag og forskellige målgrupper.

	Active Cyber Defense-loven	Fælles standarder
Hvad det er	Act No. 42 of 2025, på japansk サイバー対処能力強化法	En standard, som Cybersecurity Strategic Headquarters vedtog den 31. juli 2026
Hvem det retter sig mod	Udpegede operatører af kerneinfrastruktur (基幹インフラ)	Statslige myndigheder og, gennem dem, operatører i 16 sektorer inden for kritisk infrastruktur
Hvad det beder om	Anmeldelse af vigtige aktiver og rapportering af hændelser til regeringen	Tværsektorielle sikkerhedsforanstaltninger, fra governance og forsyningskæderisici til sårbarhedsstyring
Bindende virkning	Retlige pligter med sanktioner	Kan ikke håndhæves i sig selv. Den når operatørerne gennem hver sektors sikkerhedsstandarder

De 16 sektorer er information og kommunikation, finans, luftfart, lufthavne, jernbaner, elektricitet, gas, offentlige tjenester, sundhedsydelser, vand, logistik, kemikalier, kredit, olie, havne og posttjenester.

Ud over standarderne har Japans National Cybersecurity Office offentliggjort en vejledning i at udforme de sikkerhedsstandarder, som også gælder fra den 1. oktober. Den er det mest nyttige dokument for en leverandør, fordi den beskriver, hvad operatører forventes at gøre i forhold til de virksomheder, de køber af.

Derfor når det leverandørerne

Forpligtelserne ligger hos operatøren, så virkningen for dig er kommerciel snarere end juridisk: Den kommer som kontraktvilkår, indkøbskriterier og spørgeskemaer. Hvad der gælder for en bestemt kunde, afhænger af kundens sektor og egne sikkerhedsstandarder, så spørg kunden i stedet for at antage noget.

De fælles standarder beder operatører om at forstå, hvordan deres kritiske systemer afhænger af forsyningskæden, at kende leverandørernes sikkerhedsniveau og at stille sikkerhedskrav, når de køber produkter og tjenester. Vejledningen omsætter det til konkrete punkter.

Hvad operatører kan bede dig om

Vejledningen skelner mellem foranstaltninger, som operatører bør træffe, og foranstaltninger, der er ønskelige. Tabellen viser begge dele sammen med den del af dokumentationen, der kan komme fra dit build.

Hvad vejledningen beskriver	Niveau	Dokumentation fra buildet
Sikkerhedskrav skrevet ind i kontrakter, med eksempler som hvordan alvorlige sårbarheder håndteres og rapporteres (2.9 ②-2)	Bør træffes	En registrering af hver sårbarhed fra triage til rettet release
Leverandører af indkøbte systemer rapporterer, håndterer og offentliggør sårbarheder under vedligeholdelseskontrakten (3.6 ①-2)	Bør træffes	Løbende overvågning af det, du har leveret, og de releases, hver sårbarhed berører
En måde at dele oplysninger hurtigt med leverandøren på, når en sårbarhed eller hændelse opdages (2.9 ③-3)	Bør træffes	Build-historik, der viser, hvilke releases der indeholder en pakke
Hvor indkøbet kræver gennemsigtighed: at bede leverandøren om at udarbejde og levere en SBOM (2.9 ③-4)	Ønskeligt	En SBOM fra hvert build, eksporteret som CycloneDX eller SPDX
At bekræfte, at leverandøren udvikler efter sikre softwareudviklingspraksisser (2.9 ③-4)	Ønskeligt	Isolerede build-jobs og en håndhævet egress-politik

Kræver Japan en SBOM?

Ikke ifølge de fælles standarder, som ikke nævner SBOM'er. Vejledningen nævner dem som en mulighed: En operatør, der har brug for gennemsigtighed i indkøbet, kan bede en leverandør om at udarbejde og levere en, og vejledningen henviser til METI's SBOM-vejledning, version 2.0. Det er alligevel sandsynligvis værd at imødekomme en sådan anmodning, fordi en kontrakt kan gøre en mulighed bindende for dig.

Andet, din kunde kan se efter

• Tredjepartsevaluering. Vejledningen foreslår eksterne evalueringer for at mindske arbejdet med at kontrollere leverandører. Den nævner ISMS-overensstemmelsesvurdering og SCS-evalueringsordningen fra METI og National Cybersecurity Office, som efter planen starter omkring slutningen af det japanske finansår 2026.
• Ordninger for produkter og tjenester. Den henviser også operatører til JC-STAR for IoT-produkter, ISMAP for cloudtjenester og JISEC for it-produkter, når de fastsætter udvælgelseskriterier.
• Sårbarhedsvurderinger. Operatører vurderer jævnligt deres egne systemer, og kontraktvilkår kan udvide vurdering og rapportering til dig.
• Datavilkår. Kontrakter kan omfatte, hvor data befinder sig, og hvordan de lagres, opbevares, overføres og bortskaffes.

Det betyder det, hvis du allerede forbereder dig på CRA

Meget af arbejdet kan genbruges. EU's Cyber Resilience Act er et selvstændigt regelsæt med egne forpligtelser, så overholdelse af den opfylder ikke det, en japansk kunde beder om. Men begge handler om de samme spørgsmål: hvad der er i den software, du har leveret, hvilke releases en sårbarhed berører, og hvad du gjorde ved den. Hvis svarene kommer fra dit build, kan du genbruge dem til en japansk kunde i stedet for at samle dem igen.

Her passer CRACI ind

CRACI registrerer, hvad hvert GitHub Actions-job faktisk hentede, og producerer en SBOM fra buildet. Derefter overvåger det, hvad der er leveret, og sporer sårbarheder fra triage til en rettet release. Det giver dig dokumentation til ønskerne i tabellen ovenfor.

Det dækker kun en del af, hvad en operatør kan forvente. CRACI udfører ikke sårbarhedsvurderinger eller penetrationstest, patcher ikke udrullede systemer og rapporterer ikke til japanske myndigheder. CRACI gør dig ikke compliant med nogen sektorstandard. CRACI hostes i Europa, og ISO/IEC 27001 er den eneste certificering, det har, så tjek begge dele op mod din kundes datavilkår og udvælgelseskriterier.

Kritisk infrastruktur i Japan: ofte stillede spørgsmål

Gælder Japans Active Cyber Defense-lov for udenlandske softwareleverandører?

Pligterne til anmeldelse og rapportering af hændelser påhviler udpegede infrastrukturoperatører. En leverandør mærker den snarere gennem det, de kunder beder om i kontrakter, så afklar det med kunden og med din juridiske rådgiver.

Er de fælles standarder obligatoriske?

Ikke i sig selv. De henvender sig primært til statslige myndigheder og beskriver, hvad sektorernes sikkerhedsstandarder bør indeholde, så hvad der binder en operatør, afhænger af dens sektor.

Hvilke sektorer er omfattet?

Seksten: information og kommunikation, finans, luftfart, lufthavne, jernbaner, elektricitet, gas, offentlige tjenester, sundhedsydelser, vand, logistik, kemikalier, kredit, olie, havne og posttjenester.

Kræver Japan en SBOM?

Ikke ifølge de fælles standarder, som ikke nævner SBOM'er. Vejledningen til sikkerhedsstandarder nævner en SBOM som noget, en operatør kan bede en leverandør om, og en kontrakt kan gøre det bindende.

Hvad beder afsnittet om sårbarhedsstyring om?

Afsnit 3.3.6 i de fælles standarder beder operatører om at kontrollere, om sårbarheder berører systemer i drift, at vurdere deres systemer jævnligt og at fastlægge procedurer for patching, under hensyn til, at AI forkorter tiden fra opdagelse til udnyttelse.

Dækker CRA-forberedelse de japanske krav?

Nej, men meget af dokumentationen kan genbruges. SBOM'er, registreringen af, hvilke releases en sårbarhed berører, og registreringen af, hvordan den blev håndteret, er nyttige i begge tilfælde.