Software an Japans kritische Infrastruktur verkaufen

Was sich am 1. Oktober 2026 geändert hat

Die beiden Änderungen werden oft in einem Atemzug genannt, haben aber unterschiedliche Rechtsgrundlagen und richten sich an unterschiedliche Adressaten.

	Active-Cyber-Defense-Gesetz	Einheitliche Standards
Was es ist	Gesetz Nr. 42 von 2025, auf Japanisch サイバー対処能力強化法	Ein Standard, den das Cybersecurity Strategic Headquarters am 31. Juli 2026 beschlossen hat
An wen es sich richtet	Benannte Betreiber von Kerninfrastruktur (基幹インフラ)	Regierungsbehörden und über sie Betreiber in 16 Sektoren kritischer Infrastruktur
Was es verlangt	Wichtige Anlagen anzeigen und Vorfälle an die Regierung melden	Sektorübergreifende Sicherheitsmaßnahmen, von Governance und Lieferkettenrisiken bis zum Schwachstellenmanagement
Verbindlichkeit	Gesetzliche Pflichten mit Sanktionen	Für sich genommen nicht durchsetzbar. Betreiber erreicht er über die Sicherheitsstandards der einzelnen Sektoren

Die 16 Sektoren sind Information und Kommunikation, Finanzen, Luftfahrt, Flughäfen, Eisenbahn, Stromversorgung, Gas, Verwaltungsdienste, medizinische Versorgung, Wasser, Logistik, Chemie, Kreditwesen, Öl, Häfen und Postdienste.

Neben den Standards hat Japans National Cybersecurity Office eine Leitlinie für das Verfassen dieser Sicherheitsstandards veröffentlicht, die ebenfalls seit dem 1. Oktober gilt. Für Lieferanten ist sie das nützlichste Dokument, denn sie legt dar, was Betreiber im Umgang mit den Unternehmen tun sollen, bei denen sie einkaufen.

Warum das auch Lieferanten betrifft

Die Pflichten liegen beim Betreiber. Für Sie ist die Wirkung deshalb kommerziell und nicht rechtlich: Sie kommt als Vertragsklauseln, Beschaffungskriterien und Fragebögen bei Ihnen an. Was für einen bestimmten Kunden gilt, hängt von seinem Sektor und seinen eigenen Sicherheitsstandards ab. Fragen Sie also den Kunden, statt etwas anzunehmen.

Die Einheitlichen Standards fordern Betreiber auf, zu verstehen, wie ihre kritischen Systeme von der Lieferkette abhängen, den Sicherheitsstand ihrer Lieferanten zu kennen und beim Einkauf von Produkten und Dienstleistungen Sicherheitsanforderungen festzulegen. Die Leitlinie macht daraus konkrete Punkte.

Was Betreiber von Ihnen anfordern können

Die Leitlinie unterscheidet Maßnahmen, die Betreiber ergreifen sollten, von Maßnahmen, die wünschenswert sind. Die Tabelle zeigt beide, zusammen mit dem Teil der Nachweise, der aus Ihrem Build kommen kann.

Was die Leitlinie beschreibt	Stufe	Nachweis aus dem Build
In Verträgen festgeschriebene Sicherheitsanforderungen, etwa dazu, wie schwerwiegende Schwachstellen behandelt und gemeldet werden (2.9 ②-2)	Sollte erfolgen	Eine Aufzeichnung jeder Schwachstelle von der Triage bis zum behobenen Release
Lieferanten gekaufter Systeme melden, behandeln und veröffentlichen Schwachstellen im Rahmen des Wartungsvertrags (3.6 ①-2)	Sollte erfolgen	Laufende Überwachung dessen, was Sie ausgeliefert haben, und der Releases, die jede Schwachstelle betrifft
Ein Weg, um Informationen schnell mit dem Lieferanten zu teilen, wenn eine Schwachstelle oder ein Vorfall entdeckt wird (2.9 ③-3)	Sollte erfolgen	Build-Historie, die zeigt, welche Releases ein Paket enthalten
Wenn die Beschaffung Transparenz erfordert: den Lieferanten bitten, eine SBOM zu erstellen und bereitzustellen (2.9 ③-4)	Wünschenswert	Eine SBOM aus jedem Build, exportiert als CycloneDX oder SPDX
Sich vergewissern, dass der Lieferant nach sicheren Verfahren der Softwareentwicklung arbeitet (2.9 ③-4)	Wünschenswert	Isolierte Build-Jobs und eine durchgesetzte Egress-Richtlinie

Verlangt Japan eine SBOM?

Nicht nach den Einheitlichen Standards, die SBOMs nicht erwähnen. Die Leitlinie nennt sie als Option: Ein Betreiber, der in der Beschaffung Transparenz braucht, kann einen Lieferanten bitten, eine SBOM zu erstellen und bereitzustellen. Dazu verweist die Leitlinie auf den SBOM-Leitfaden des METI, Version 2.0. Einer solchen Anfrage nachzukommen, dürfte sich trotzdem lohnen, denn ein Vertrag kann eine Option für Sie verbindlich machen.

Worauf Ihr Kunde außerdem achten könnte

• Externe Bewertung. Die Leitlinie schlägt vor, externe Bewertungen zu nutzen, um den Aufwand für die Prüfung von Lieferanten zu senken. Sie nennt die ISMS-Konformitätsbewertung und das SCS-Bewertungsschema von METI und National Cybersecurity Office, dessen Start um das Ende des japanischen Haushaltsjahres 2026 geplant ist.
• Programme für Produkte und Dienste. Außerdem verweist sie Betreiber bei der Festlegung von Auswahlkriterien auf JC-STAR für IoT-Produkte, ISMAP für Cloud-Dienste und JISEC für IT-Produkte.
• Schwachstellenbewertungen. Betreiber bewerten ihre eigenen Systeme regelmäßig, und Vertragsklauseln können Bewertung und Berichterstattung auf Sie ausdehnen.
• Datenklauseln. Verträge können den Standort von Daten sowie deren Speicherung, Aufbewahrung, Übertragung und Löschung regeln.

Was das bedeutet, wenn Sie sich bereits auf den CRA vorbereiten

Vieles lässt sich übertragen. Der EU Cyber Resilience Act ist ein eigenes Regelwerk mit eigenen Pflichten. Wer ihn einhält, erfüllt daher noch nicht, was ein japanischer Kunde verlangt. Beide laufen aber auf dieselben Fragen hinaus: Was steckt in der Software, die Sie ausgeliefert haben, welche Releases betrifft eine Schwachstelle, und was haben Sie dagegen unternommen? Wenn diese Antworten aus Ihrem Build kommen, können Sie sie für einen japanischen Kunden wiederverwenden, statt sie neu zusammenzustellen.

Wo CRACI ins Spiel kommt

CRACI zeichnet auf, was jeder GitHub-Actions-Job tatsächlich geladen hat, und erzeugt eine SBOM aus dem Build. Danach überwacht es, was ausgeliefert wurde, und verfolgt Schwachstellen von der Triage bis zum behobenen Release. Das liefert Ihnen Nachweise für die Anfragen in der Tabelle oben.

Damit deckt es nur einen Teil dessen ab, was ein Betreiber erwarten könnte. CRACI führt keine Schwachstellenbewertungen oder Penetrationstests durch, patcht keine bereitgestellten Systeme und meldet nichts an japanische Behörden. Es macht Sie mit keinem Sektorstandard konform. CRACI wird in Europa gehostet, und ISO/IEC 27001 ist die einzige Zertifizierung, die es besitzt. Prüfen Sie daher beides anhand der Datenklauseln und Auswahlkriterien Ihres Kunden.

Japans kritische Infrastruktur: häufig gestellte Fragen

Gilt Japans Active-Cyber-Defense-Gesetz für ausländische Softwareanbieter?

Seine Anzeige- und Meldepflichten für Vorfälle treffen benannte Infrastrukturbetreiber. Ein Lieferant spürt es eher durch das, was diese Kunden in Verträgen fordern. Klären Sie das also mit dem Kunden und Ihrem Rechtsberater.

Sind die Einheitlichen Standards verbindlich?

Für sich genommen nicht. Sie richten sich vor allem an Regierungsbehörden und legen fest, was die Sicherheitsstandards der Sektoren enthalten sollten. Was einen Betreiber bindet, hängt also von seinem Sektor ab.

Welche Sektoren sind erfasst?

Sechzehn: Information und Kommunikation, Finanzen, Luftfahrt, Flughäfen, Eisenbahn, Stromversorgung, Gas, Verwaltungsdienste, medizinische Versorgung, Wasser, Logistik, Chemie, Kreditwesen, Öl, Häfen und Postdienste.

Verlangt Japan eine SBOM?

Nicht nach den Einheitlichen Standards, die SBOMs nicht erwähnen. Die Leitlinie für Sicherheitsstandards nennt eine SBOM als etwas, worum ein Betreiber einen Lieferanten bitten kann, und ein Vertrag kann das verbindlich machen.

Was verlangt der Abschnitt zum Schwachstellenmanagement?

Abschnitt 3.3.6 der Einheitlichen Standards fordert Betreiber auf, zu prüfen, ob Schwachstellen Systeme im Betrieb betreffen, ihre Systeme regelmäßig zu bewerten und Patch-Verfahren festzulegen, und zwar mit Blick darauf, dass KI die Zeit von der Entdeckung bis zur Ausnutzung verkürzt.

Deckt die CRA-Vorbereitung japanische Anforderungen ab?

Nein, aber viele Nachweise lassen sich übertragen. SBOMs, die Aufzeichnung, welche Releases eine Schwachstelle betrifft, und die Aufzeichnung, wie sie behandelt wurde, sind in beiden Fällen nützlich.