## Source-Root- und Archivgrenzen ab 1.41.1 Historische Übergabe- und Featurepakete unter `Archiv/`, `archive/` oder `archives/` sind keine ausführbare Produktquelle. Sie werden aus Git-Staging, Release-Staging, Secret-Scan und ESM-Vertragsprüfung ausgeschlossen. Der produktive Source-Root bleibt separat vollständig geprüft; fehlende reale Moduldateien blockieren CI und Release. # Sicherheit ## Vertrauliche Dateien Folgende Dateien dürfen niemals in Git oder öffentliche Pakete gelangen: - `.env` - `db/*.db`, `db/*.db-wal`, `db/*.db-shm` - `uploads/` - Backups, Logs und Session-Daten - private Schlüssel und Zertifikate ## Online-Betrieb Vendoo darf nicht durch eine direkte Portfreigabe von Port 8124 veröffentlicht werden. Für öffentliche Nutzer ist eine getrennte Server-/VPS-Instanz hinter HTTPS und Reverse Proxy vorgesehen. ## Meldung von Sicherheitsproblemen Sicherheitsprobleme nicht mit Zugangsdaten oder personenbezogenen Daten in öffentliche Issues schreiben. ## Lokaler FLUX / ComfyUI - ComfyUI wird standardmäßig nur an `127.0.0.1` gebunden. - Vendoo blockiert Remote-ComfyUI-URLs, solange `LOCAL_IMAGE_ALLOW_REMOTE` nicht ausdrücklich aktiviert wird. - Die ComfyUI-Oberfläche wird nicht über das LAN veröffentlicht. - API-Aufrufe erfolgen serverseitig durch Vendoo. - Ein zufälliger Token wird für die lokale Integrationskonfiguration erzeugt. - Andere Prozesse auf demselben Windows-Rechner können theoretisch ebenfalls auf einen localhost-Dienst zugreifen; für echte Prozessisolation wäre ein separates Windows-Konto oder eine VM erforderlich. ## ESM-Modulverträge ab 1.41.0 - lokale benannte ESM-Imports werden vor CI und Release gegen die tatsächlich exportierten Symbole geprüft - fehlende Exporte blockieren den Build vor der Auslieferung - Worker-Start- und Stop-Verträge werden separat geprüft ## FLUX Studio - ComfyUI bleibt standardmäßig ausschließlich an `127.0.0.1` gebunden. - Das FLUX Studio akzeptiert nur Textprompts und erzeugt Dateien unter `uploads/ai-generated`. - API-Pfade für Bibliothek und Bearbeitungen werden serverseitig auf dieses Verzeichnis begrenzt. - Start und Stopp der lokalen Engine erfordern eine Admin-Rolle. - Bearbeitungen erzeugen neue Dateien; Originalausgaben werden nicht still überschrieben. ## Operations Center, Backups und Updates - Backups werden mit einem Manifest und SHA-256-Prüfsummen erzeugt und vor der Freigabe verifiziert. - Sicherungen, die `.env` enthalten, enthalten möglicherweise API-Schlüssel, Tokens und Zugangsdaten. Sie sind wie Passwörter zu behandeln und dürfen nicht unverschlüsselt weitergegeben werden. - Restore- und Update-Archive werden vor der Anwendung in einem lokalen Staging-Bereich geprüft. - Archive mit Pfad-Traversal, absoluten Pfaden oder unzulässigen Laufzeitdaten werden abgewiesen. - Updates dürfen keine `.env`, produktive Datenbank, Uploads, Backups, Logs, Modelle oder `node_modules` mitbringen. - Das eigentliche Anwenden erfolgt nur bei gestopptem Vendoo über `setup.bat` und erzeugt vorher einen Rollback-Snapshot. - Eine optionale Update-Manifest-URL sollte ausschließlich über HTTPS und aus einer kontrollierten Quelle verwendet werden. - Extension-Heartbeats enthalten nur Diagnosemetadaten wie Browser, Version, Plattform und Zeitpunkt; keine Formularinhalte oder Zugangsdaten. ## Mehrbenutzer- und Server-Sicherheit ab 1.31.0 - Vendoo bindet standardmäßig an `127.0.0.1`. LAN-Zugriff muss ausdrücklich über `VENDOO_BIND_HOST=0.0.0.0` aktiviert werden. - Öffentlicher Betrieb ausschließlich über HTTPS und einen korrekt konfigurierten Reverse Proxy. `VENDOO_TRUST_PROXY=true` nur setzen, wenn der Proxy vertrauenswürdig ist und Client-IP-Header kontrolliert. - `VENDOO_ALLOWED_HOSTS` und `VENDOO_ALLOWED_ORIGINS` eng begrenzen. - Rollen ersetzen keine Betriebssystemrechte: Datenbank, `.env`, Backups und Uploads müssen auf Dateisystemebene geschützt bleiben. - Bearbeitungssperren verhindern parallele Änderungen, ersetzen aber keine Backups. - Audit-Logs können personenbezogene Betriebsdaten wie Benutzer, IP und Aktionen enthalten; Aufbewahrung und Zugriff müssen organisatorisch geregelt werden. ## Architektur-Sicherheitsregeln ab 1.35.0 - Neue Kernel-Routen sind Deny-by-default und benötigen eine registrierte Policy. - Modulmanifeste, Abhängigkeiten, Capabilities und Ownership werden vor dem Start validiert. - Zyklische Abhängigkeiten, fehlende Capabilities und doppelte Ressourcen-Ownership blockieren den Kernelstart. - Drittanbieter-Erweiterungen dürfen nicht im Vendoo-Hauptprozess ausgeführt werden. - Themes dürfen nur freigegebene, typisierte Design Tokens verändern; freies CSS, JavaScript und externe URLs sind verboten. - Der Event Bus ordnet Listener einem Owner zu, damit Module beim Stoppen ihre Listener vollständig entfernen können. - Das Architektur-Gate `npm run verify:architecture` ist verpflichtender Bestandteil von CI und Releases. ## Theme-Sicherheit ab 1.36.0 - Theme-Profile akzeptieren ausschließlich bekannte, typisierte Design Tokens. - Freies CSS, JavaScript, HTML, URLs und Dateipfade sind nicht zulässig. - Alle Werte werden im Browser zur Benutzerführung und erneut auf dem Server validiert. - Normale Benutzer können nur die eigene Theme-Präferenz verändern. - Theme-Profile und Systemstandard erfordern `settings.manage`. - Theme-Änderungen werden auditiert. - Importierte Profile durchlaufen dieselbe Validierung wie manuell erstellte Profile. - Kontrastprüfungen verhindern nicht automatisch jede bewusste administrative Gestaltung, zeigen problematische Paare aber vor dem Speichern deutlich an. ## Security Foundation ab 1.37.0 Zugangsdaten werden bevorzugt im verschlüsselten Secret-Speicher unter dem persistenten Konfigurationsbereich abgelegt. Die Verschlüsselung verwendet AES-256-GCM; der Master-Key liegt getrennt und wird nicht in Git oder Release-Pakete aufgenommen. Bestehende Secrets aus der Runtime-Konfiguration werden beim ersten Start gesichert, verschlüsselt migriert und aus der Klartextdatei entfernt. Die Weboberfläche verwendet eine erzwungene Content Security Policy ohne Inline-Skripte und Inline-Eventhandler. Request- und Correlation-IDs werden in Antworten ausgegeben und in der strukturierten Telemetrie geführt. ## Identity- und Settings-Sicherheit ab 1.38.0 - Auth, Benutzer, Sitzungen und Einstellungen laufen als native Module über explizite Policies und Eingabeschemata. - Der letzte aktive Administrator kann nicht gelöscht, deaktiviert oder zu einer Nicht-Admin-Rolle herabgestuft werden. - Benutzer können nur Sitzungen widerrufen, die ihrer eigenen Benutzer-ID gehören; administrative globale Revocation erfordert `sessions.manage`. - Login-Historie erfordert `users.manage`, SMTP-Verwaltung `settings.manage`. - Die Settings-Allowlist weist unbekannte oder nicht freigegebene Felder zurück. - Passwort-Hashes, Session-Tokens und Secret-Klarwerte dürfen nicht in Listen-, Status- oder Audit-Antworten erscheinen. - `lib/auth.mjs` ist nur noch eine Kompatibilitätsfassade; neue Identitätslogik gehört in die nativen Module. ## Catalog- und Medien-Sicherheit ab 1.39.0 - Artikelrouten verwenden explizite Policies für Lesen, Bearbeiten, Papierkorb und endgültiges Löschen. - Unbekannte Artikel-, Lager- und Medienfelder werden abgewiesen. - Rich-HTML wird serverseitig bereinigt; Preise, Texte, Tags und Fotolisten besitzen feste Grenzen. - Endgültiges Löschen ist nur für bereits im Papierkorb befindliche Artikel möglich. - Lager-Bulk-Aktionen sind auf 500 eindeutige positive Artikel-IDs begrenzt. - Medienpfade werden normalisiert und gegen Traversal, Nullbytes sowie Zeilenumbrüche geprüft. - Von aktiven Artikeln referenzierte Bilder sind beim Löschen geschützt. - Modulimporte initialisieren keine Datenbank; Repositories werden beim Serverstart injiziert. ## Modulsicherheit ab 1.40.0 - Kernmodule sind geschützt und können weder deaktiviert noch gelöscht werden. - Aktivierungszustände werden atomar im persistenten Konfigurationsbereich gespeichert. - `.vmod`-Pakete werden auf Format, Manifest, Pfade, Dateigrößen, Einzeldatei-SHA-256 und Gesamtintegrität geprüft. - Installierbare Fremdmodule müssen den Typ `extension-host` verwenden. - Deklarative Pakete dürfen keine JavaScript-, Shell-, Native- oder Binärdateien enthalten. - Ausführbare Pakete benötigen eine vertrauenswürdige Ed25519-Signatur und dürfen ausschließlich in einem isolierten Extension-Host laufen. Solange dieser Host nicht freigegeben ist, bleiben solche Pakete deaktiviert und quarantänisiert. - Fremdmodule werden niemals durch bloßes Kopieren automatisch registriert oder aktiviert. - Abhängigkeiten werden vor Aktivierung geprüft; geschützte Abhängigkeiten verhindern unsichere Deaktivierung. - Installierte Modulpakete und `modules-state.json` werden gemeinsam gesichert und wiederhergestellt. - Der Laufzeitordner `modules/` ist von Git-Import und Release-Paketen ausgeschlossen. ## Produktionsdeployments über Coolify (1.41.0) - der Vendoo-Container erhält keinen Zugriff auf `/var/run/docker.sock` - Vendoo verändert seinen eigenen Container nicht und führt kein `git pull` aus - Coolify-API-Token und Deploy-Webhook liegen ausschließlich im verschlüsselten Secret Store - Deploymentrouten benötigen `updates.manage`, CSRF-Schutz, Rate Limit und Audit - ein Deployment erfordert die exakte Bestätigung `DEPLOY` - standardmäßig wird vor jedem Auftrag ein Backup einschließlich Konfiguration erzeugt - Produktionsendpunkte müssen HTTPS verwenden - Antworten externer Deploymentdienste werden begrenzt und Redirects nicht automatisch verfolgt - der Initialwert für deaktivierte Module überschreibt keine spätere persistente Administratorentscheidung ## Git-Ignore-Grenzen Lokale Runtimeordner werden ausschließlich als Root-Pfade (`/modules/`, `/sessions/`, `/logs/` usw.) ignoriert. Produktive Quellpfade unter `app/modules/` dürfen weder ignoriert noch ungetrackt sein; CI und Deploy-Assistent erzwingen diese Grenze.