KONTROLLIERTE TECHNISCHE OFFENLEGUNG

Controlled Technical Disclosure

Sicherheitstransparenz und Sicherheitsexposition sind nicht dasselbe. immo.quick veröffentlicht die Eigenschaften, die Institutionen benötigen, um das architektonische Modell zu verstehen: was vor Ausführung schließen muss, welche Klassen von Vertrauenskonzentration reduziert werden, wie Software-Provenienz behandelt wird, wie sich verteilte Ausführung verhält und wie Sicherheitszustand versioniert wird.

Die öffentliche Website veröffentlicht bewusst keine vollständige Karte sicherheitskritischer Bindungen, interner Topologie, Invarianten-Implementierung, Threshold-Konfiguration oder adversarialer Testprozedur. Diese Grenze soll ernsthaftes Review nicht verhindern, sondern ermöglicht, dass technisches Review mit dem angemessenen Kontext, Zweck und der angemessenen Vertraulichkeit stattfindet.

Architektur-Review anfragen → NDA-Zugang anfragen

DREI OFFENLEGUNGSSTUFEN

Sicherheitseigenschaften sind öffentlich. Sicherheitskritisches Implementierungsdetail ist kontrolliert.

LEVEL 1

Öffentliche Sicherheitseigenschaften

Die öffentliche Schicht beschreibt die architektonischen Garantien und Designprinzipien. Sie erklärt kryptografische Souveränität, beweisgebundene Software, bewiesene Software-Lieferkette, verteilte deterministische Ausführung, Threshold-Privacy, adversariale Regression und die versiegelte Fortress Baseline. Diese Stufe genügt, um das Sicherheitsmodell zu verstehen, ohne Implementierungsdetails offenzulegen, die Reverse Engineering wesentlich vereinfachen würden.

LEVEL 2

Kontrolliertes Architektur-Briefing

Qualifizierte Reviewer können ein tieferes Architektur-Briefing erhalten oder an einer technischen Review-Sitzung teilnehmen. Diese Stufe erklärt, wie die wichtigsten Sicherheitsdomänen interagieren, welche Evidenzklassen existieren, wie Fail-Closed-Verhalten auf konzeptioneller Ebene durchgesetzt wird und wie historische Ausführung zu Beweis-, Build- und Deployment-Zustand aufgelöst werden kann. Sie bleibt bewusst abstrahiert von vollständigen Schemata, exakten Protokollkonstruktionen und detaillierter Angriffstopologie.

LEVEL 3

Vertrauliche definitive Architektur

Wo ein legitimer institutioneller, regulatorischer, Audit-, Transaktions- oder Due-Diligence-Zweck tiefere Prüfung erfordert, kann die definitive Architektur unter einer angemessenen NDA und einem kontrollierten Zugangsprozess geprüft werden. Dieses Material kann sicherheitskritische Zustandsübergangslogik, Beweisbindungsstrukturen, detaillierte Invariantendefinitionen, interne Zustandswurzeln, Threshold- und Teilnehmermodelle, adversariale Testspezifikationen, bewahrte Sicherheitsfunde und die versiegelte Baseline-Beweisstruktur umfassen.

ÖFFENTLICH VERSUS KONTROLLIERT

Sicherheitseigenschaften sind öffentlich. Sicherheitskritisches Implementierungsdetail bleibt kontrolliert.

ÖFFENTLICH OFFENGELEGT

Die Systemkategorie, das deterministische Ausführungsmodell, die Existenz beweisgebundener Software und Deployments, der Einsatz moderner klassischer und Post-Quanten-kryptografischer Standards, die Existenz von Lieferketten-Provenienz und reproduzierbaren Build-Kontrollen, der Einsatz verteilter deterministischer Ausführung für ausgewählte kritische Pfade, die Verfügbarkeit von Threshold-Berechnung für konfigurierte sensible Pfade, die Existenz adversarialer Regression und die versiegelte Sicherheitsbaseline. Ebenso die architektonische Grenze selbst: Autorität bleibt extern, Gates erzeugen keine Ausführungserlaubnis eigenständig, Beweise erzeugen keine Autorität, Witnesses legitimieren keine Ausführung, verteilte Knoten stimmen nicht über rechtliche Ergebnisse ab, und die Execution Plane regiert sich nicht selbst.

BLEIBT KONTROLLIERT

Exakte interne Entity- und Funktionsstrukturen, vollständige Invarianten-Register, detaillierte Forbidden-Edge-Definitionen, exakte Hash- und Commitment-Konstruktionen, Secret-Sharing-Parameter, Root-Holder-Vereinbarungen, Threshold-Topologien, Knoten- und Witness-Betriebstopologie, detaillierte Angriffsskripte, interne Block-Code-Abdeckung, vollständige Zustandswurzel-Zusammensetzung und der definitive Fortress-Baseline-Beweis.

Der Grund ist einfach: ernsthafte Reviewer sollten in der Lage sein, die Architektur zu verifizieren, aber die öffentliche Website sollte nicht als Rekonstruktionsanleitung für die defensive Topologie der Plattform dienen. Die Politik ist daher einfach: Sicherheitseigenschaften sind öffentlich, sicherheitskritisches Implementierungsdetail ist kontrolliert.

WER EIN REVIEW ANFRAGEN KANN

Kontrolliertes Review ist für Parteien mit einem legitimen technischen oder institutionellen Zweck bestimmt, einschließlich regulierter Finanzinstitute, Versicherer, Behörden, Aufsichtsgremien, unabhängiger Auditoren, Sicherheitsreviewer, strategischer Technologiepartner, Transaktionsgegenparteien und qualifizierter Investoren, die technische Due Diligence durchführen. Die Offenlegungstiefe wird an die Rolle und den Review-Zweck angepasst, statt ein Einheitsdokument zu verwenden.

Ein Regulator benötigt möglicherweise auflösbare Evidenz und Governance-Zustandssemantik. Ein CISO benötigt möglicherweise Fehlerdomänentrennung, Build-Provenienz und adversariales Testen. Ein Investor muss möglicherweise verstehen, welche Teile standardisierte Primitive sind und welcher Teil den architektonischen Burggraben bildet. Kontrollierte Offenlegung erlaubt es, jedes Review technisch bedeutsam zu machen, ohne jedes interne Detail öffentlich zu machen.