Sicherheit & Vertrauen bei OpsCodex

OpsCodex wird single-tenant und on-premise in Ihrer eigenen Umgebung betrieben. Ihre Dokumente und Prozessmodelle werden nur in Ihrer Umgebung gespeichert. An ein KI-Modell gehen sie nur dorthin, wo Sie es festlegen, auf Wunsch nur ins eigene Netz. Es gibt keine geteilte, mandantenübergreifende Datenebene.

Docker Compose auf einem Server

Die gesamte Anwendung läuft mit Docker Compose auf einem Server. Für einen Piloten genügt ein kleiner Server; Voraussetzungen, Backup-Routine und Update-Ablauf stehen auf der Seite OpsCodex bewerten.

Kubernetes mit Helm-Chart

Das Chart installiert OpsCodex in einen Namespace und braucht keine clusterweiten Rechte. Jeder Container läuft als Nicht-Root-Benutzer mit fester UID, auf einem schreibgeschützten Root-Dateisystem und ohne Linux-Capabilities; getestet ist das Chart mit erzwungenem Pod-Security-Standard restricted auf seinem Namespace. PostgreSQL und S3-kompatibler Speicher kommen von Ihrer Plattform oder laufen als Container im selben Namespace — unser eigenes Datenbank-Image, das ohne Root läuft, und ein S3-Server unter Apache-2.0-Lizenz. Der Verkehr erreicht OpsCodex über Ihren Ingress oder die Gateway API.

Rollenbasierte Zugriffskontrolle

Granulare Rollen bilden den Governance-Workflow ab — Autor, Prüfer, Freigeber, Administrator, Auditor und Dokumentations-Redakteur. Jeder sieht und tut genau das, was seine Rolle erlaubt, und nicht mehr.

Single Sign-on

Anmeldung über Ihren Identity Provider (OIDC, SAML) ist in Arbeit. Bis dahin: lokale Konten mit Passwortregeln nach NIST, Sperre nach Fehlversuchen, Abmeldung bei Inaktivität.

Passwörter

Die Passwortregeln folgen NIST SP 800-63B-4: standardmäßig mindestens 15 Zeichen — so viel verlangt der Standard von einem Passwort, das der einzige Anmeldefaktor ist —, ohne erzwungene Zeichenklassen und ohne erzwungenen periodischen Wechsel. Gängige und geleakte Passwörter werden abgelehnt, geprüft gegen eine Liste, die mit dem Produkt ausgeliefert wird; die Prüfung braucht also keine Verbindung nach außen. Zehn Fehlversuche in Folge sperren das Konto für 15 Minuten gegenüber der Adresse, von der sie kamen (beides einstellbar), sodass ein Fremder den Inhaber nicht aussperren kann. Passwörter werden per Einweg-Hash (bcrypt) gespeichert; eine Änderung erfordert das aktuelle Passwort und beendet bestehende Sitzungen.

Sitzungen

Sitzungen nutzen kurzlebige, HttpOnly- und Secure-Cookies und enden nach einer Zeit ohne Aktivität — standardmäßig zwei Stunden, von einem Administrator einstellbar —, was der Server bei jeder Anfrage prüft. Abmeldung, Deaktivierung und Rollenwechsel wirken sofort.

Mitarbeiterportal

Das schreibgeschützte Portal, in dem Mitarbeitende freigegebene Prozesse nachschlagen, ist entweder für alle offen, die es in Ihrem Netz erreichen, oder — über eine Administrator-Einstellung — nur für angemeldete Nutzer. Es zeigt ausschließlich freigegebene Versionen; Entwürfe und laufende Bearbeitungen stehen nie darin.

Zugriff für KI-Agenten

Ein schreibgeschützter Endpunkt über das Model Context Protocol (MCP) lässt KI-Agenten freigegebene Prozesse lesen, jede Antwort mit Revision, Freigeber und Freigabedatum. Er ist aus, bis er in der Konfiguration der Installation eingeschaltet wird. Jeder Client braucht ein eigenes Token, das ein Administrator ausstellt und widerrufen kann; der Endpunkt kennt keinerlei Schreiboperation, und jeder Zugriff wird protokolliert.

Bei der Übertragung

Der gesamte Verkehr ist mit modernem TLS verschlüsselt; schwache Cipher werden nicht angeboten.

Im Ruhezustand

Anwendungs-Secrets — etwa Schlüssel von KI-Anbietern — sind mit AES-256-GCM verschlüsselt, Konto-Passwörter sind per Einweg-Hash gespeichert. Im On-Premise-Betrieb halten Sie sämtliches Schlüsselmaterial selbst.

Hochgeladene Dateien

Von Nutzern hochgeladene Inhalte werden als Download mit deaktiviertem MIME-Sniffing ausgeliefert, damit nicht vertrauenswürdige Dateien nicht im Browser ausgeführt werden können.

Governance-Aktionen werden in einen Append-only-Audit-Trail geschrieben. Das wird in der Datenbank erzwungen, nicht im Anwendungscode: Ein Trigger auf der Audit-Tabelle weist jedes UPDATE und DELETE zurück, und der Datenbank-Rolle, unter der die Anwendung läuft, sind diese Rechte entzogen. Die Anwendung kann ihre eigene Audit-Historie selbst dann nicht umschreiben, wenn sie kompromittiert ist — das kann nur die separate Migrations-Rolle für Schema-Änderungen und Test-Teardown, und diese Rolle bedient nie eine Anfrage.

Um die Grenze präzise zu benennen: Der Trigger deckt Änderung und Löschung auf Zeilenebene ab. Er deckt TRUNCATE nicht ab, und er schützt nicht gegen jemanden mit Superuser-Zugriff auf Ihren eigenen Datenbankserver — das kann keine Kontrolle auf Anwendungsebene. Betrachten Sie den Nachweis als manipulationserkennend innerhalb der Reichweite der Anwendung, und flankieren Sie ihn mit den Backup- und Datenbank-Zugriffskontrollen, die Sie für andere führende Systeme ohnehin betreiben.

Fragt ein Auditor, wer ein Modell wann freigegeben hat, steht die Antwort im Protokoll: Autor, Prüfer, Freigeber, Zeitstempel und der Export-Hash dessen, was freigegeben wurde.

Jede Antwort trägt moderne Browser-Sicherheits-Header — Content-Security-Policy, HTTP Strict Transport Security, Schutz gegen Clickjacking und MIME-Sniffing sowie eine restriktive Permissions-Policy. Rate-Limiting schützt die Authentifizierung und andere sensible Endpunkte, und Abhängigkeits- und Sicherheitsprüfungen laufen in der Continuous Integration.

Release-Gate

Ein Release wird nur veröffentlicht, wenn sein Gate bestanden ist: Die Produktionskonfiguration startet kalt auf leeren Volumes und wird per Smoke-Test geprüft, jedes Container-Image wird mit Trivy gescannt — ein HIGH- oder CRITICAL-Befund, für den es einen Fix gibt, stoppt das Release —, und die laufende Anwendung wird mit OWASP ZAP von außen angegriffen, wobei ein schwerer Befund das Release ebenfalls stoppt. Ausgeliefert werden genau die getesteten Images; sie werden danach nicht neu gebaut.

Software-Stückliste (SBOM)

Jedes Release enthält eine CycloneDX-SBOM pro Image und eine für den vollständigen Abhängigkeitsgraphen, damit Sie das Gelieferte gegen Ihre eigenen Schwachstellen-Feeds prüfen können.

Release-Rhythmus und Support

Releases tragen den Monat ihrer Veröffentlichung im Namen, etwa 2026.11, und erscheinen etwa einmal pro Quartal. Jedes erhält neun Monate ab Veröffentlichung Fixes für hohe und kritische Schwachstellen. Patches erscheinen an einem monatlichen Patchday; ein Fix für eine kritische Schwachstelle wartet nicht darauf. Nichts aktualisiert sich selbst: Sie entscheiden, wann eine Installation auf ein neues Release wechselt.

Ihre Daten gehören Ihnen

Ihre Inhalte gehören Ihnen. Sie sind jederzeit exportierbar; bei Vertragsende können sie sofort exportiert und auf Wunsch gelöscht werden. On-premise steuern Sie die Löschung unmittelbar selbst.

DSGVO

Der Betreiber sitzt in der EU (Mews Group SAS, Frankreich). On-premise bleiben Ihre Prozessdaten in Ihrer eigenen Infrastruktur und Ihrer eigenen Jurisdiktion — sie werden nicht an uns übertragen, es gibt auf unserer Seite also keine Drittlandübermittlung zu begründen.

Kein Tracking durch Dritte

Keine Weitergabe personenbezogener Daten an Dritte, keine Drittanbieter-Cookies und kein Zugriff auf Kontakte, Kalender oder andere Gerätedaten.

KI ist eine optionale Assistenzschicht: Sie schlägt vor, ein Mensch gibt frei. Ab Werk wird der Inhalt Ihrer Prompts nicht gespeichert; schaltet ein Administrator den Chatverlauf ein, bleibt er in Ihrer eigenen Datenbank. Wie Anbieter-Schlüssel, Datenspeicherung und private oder selbst gehostete Inferenz funktionieren, steht unter KI-Governance.

Wir prüfen OpsCodex selbst gegen den OWASP Application Security Verification Standard (ASVS) 5.0.0 auf Level 2. Level 2 schließt Level 1 ein, also werden alle 253 Anforderungen beider Level einzeln geprüft, gegen den Quellcode, die Tests, die Container-Images und die Auslieferungsartefakte des Releases. Jede erfüllte Anforderung nennt die Stelle in Code, Test oder Konfiguration, die sie durchsetzt; jede nicht erfüllte nennt den offenen Punkt, der sie schließt.

Was sie nicht ist. Dies ist die eigene White-Box-Prüfung des Herstellers, erstellt mit KI-gestütztem Code-Review und von Hand nachgeprüft. Sie ist kein unabhängiger Penetrationstest und keine Zertifizierung. Sie wird für jedes Feature-Release erneuert und beschreibt damit das Release, das Sie installieren.

Geprüft am 29. Oktober 2026, für Release 2026.11.

Ergebnis je Level

Level	Anforde­rungen	Erfüllt	Teil­weise	Nicht erfüllt	N/A
Level 1, die Grundstufe	70	42	23	0	5
Level 2, einschließlich Level 1	253	92	88	11	62

Erfüllt gilt für jeden betroffenen Teil von OpsCodex; Teilweise für einige davon; N/A heißt, dass es den Gegenstand der Anforderung in OpsCodex nicht gibt (etwa WebRTC oder einen OAuth-Autorisierungsserver). Manche Anforderungen hängen von der Installation ab (etwa TLS an Ihrem Netzrand oder die Mehrfaktor-Anmeldung bei Ihrem Identitätsanbieter); sie werden danach beurteilt, was OpsCodex ausliefert und dokumentiert, und nie als N/A gezählt.

Teilweise heißt meist eines von zwei Dingen: Der Code erfüllt die Anforderung, ASVS verlangt dazu aber ein Dokument, das es so noch nicht gibt. Oder sie ist an den meisten Stellen erfüllt, an einer noch nicht.

20 Punkte sind noch offen, keiner davon mit hoher Priorität. Jeder ist bei uns als Aufgabe erfasst.

Die vollständige Prüfung — eine Zeile je Anforderung, mit den Belegen und den Einzelheiten jeder Lücke — erhält Ihr Sicherheitsteam unter NDA: [email protected].

Eine Sicherheitsseite, die nur aufzählt, was es gibt, sagt Ihnen die Hälfte dessen, was Sie brauchen. Dies sind die Lücken, die Sie sonst durch Nachfragen finden müssten — hier benannt, damit Sie sie früh statt spät abwägen können.

Zertifizierungen

Keine ISO 27001, kein SOC 2, kein TISAX. OpsCodex läuft on-premise in Ihrer eigenen, zertifizierten Umgebung, deshalb war das bisher keine Hürde. Ist ein Zertifikat in Ihrer Beschaffung Pflicht, sprechen Sie es früh an.

Unabhängiger Penetrationstest

Bisher keiner beauftragt. OpsCodex läuft on-premise in Ihrem eigenen Perimeter und nicht als Dienst im offenen Internet. Deshalb kann Ihr Sicherheitsteam oder Ihr gewohnter Dienstleister genau die Installation testen, die Sie betreiben, und wir unterstützen das direkt. Auf unserer Seite laufen: ein täglicher Scan aller Abhängigkeiten und der Basis-Images, auf denen die Releases aufbauen, eine wöchentliche statische Analyse des Codes, der Container-Scan und ein automatischer Angriff von außen auf die laufende Anwendung in jedem Release-Gate und ein Regressionstest, der den Build scheitern lässt, wenn die oben genannten Security-Header wegfallen. Die ASVS-Selbstprüfung oben ist unsere eigene und ersetzt keinen unabhängigen Test.

Datenklassifizierung und DLP-Kennzeichnung

Keine Funktion für Sensitivitätskennzeichen oder DLP. Der Zugriff wird stattdessen strukturell gesteuert: über Rollen, teambezogene Berechtigungen und eine harte Grenze zwischen internen Entwürfen und dem veröffentlichten Portal.

Verwalteter Schlüsseldienst

Jedes Geheimnis liegt in Ihrer eigenen Umgebung, und wir halten keines davon — es gibt aber keine Anbindung an ein verwaltetes KMS oder HSM, falls Ihre Organisation Schlüssel lieber so verwahrt.

Finden Sie eine Lücke, die weder diese Liste noch die offenen Punkte der ASVS-Selbstprüfung nennen, sagen Sie es uns — dann kommt sie auf die Liste. Eine solche Seite ist nur dann lesenswert, wenn sie vollständig ist.

Eine Sicherheitslücke gefunden? Bitte schreiben Sie an [email protected].