Problem: Warum externe Reviews nötig sind
Ephraim möchte ausdrücklich externe Security-Reviews der Code- und Architektursicherheit gewinnen. Aktuell liegen solche externen Reviews noch nicht vor. Wer Architektur, Webanwendung oder Kryptografie unabhängig prüfen möchte, darf sich gerne melden. Die Plattform verarbeitet schulische Daten, Rollenrechte, Dateien, Projektkontexte und lokale KI-Anfragen. Deshalb braucht Vertrauen mehr als gute Absichten, gute Dokumentation und interne Prüfung.
1. Was mit Code-Sicherheit gemeint ist
Dieses Thema meint nicht die persönlichen Sicherheitseinstellungen eines Kontos, nicht die Datei-Sicherheitsseite im Adminbereich und nicht einzelne Betriebsfunktionen. Diese Bereiche haben eigene Handbuchartikel, weil sie Bedienung, Rollen und Betrieb erklären.
Hier geht es um die Sicherheit des Systems selbst. Ist die Architektur tragfähig? Sind Vertrauensgrenzen richtig gezogen? Halten Rollen- und Objektprüfungen? Gibt es Angriffswege über Webendpunkte, Sessions, CSRF, XSS, Uploads oder Exporte? Werden Schlüssel, Tokens, Signaturen, Zufall und Recovery richtig eingesetzt?
Ephraim unterscheidet dabei zwischen Security-Reviews und breiteren Audits. Security-Reviews prüfen gezielt Code-, Architektur- und Kryptografierisiken. Audits können zusätzlich Qualität, Bedienbarkeit, Betrieb oder Wartbarkeit betrachten. Beides ist wertvoll, aber nur ein Security-Review kann eine konkrete Sicherheitsannahme entlasten oder ein Sicherheitsfinding begründen.
2. Warum Selbsterklärung nicht reicht
Ephraim ist bewusst lokal gebaut. KI-Anfragen gehen nicht an öffentliche Modellanbieter, Vault-Inhalte werden verschlüsselt gespeichert und Rollen begrenzen Zugriffe. Das sind wichtige Schutzentscheidungen. Sie beweisen aber nicht automatisch, dass jede konkrete Codekante hält.
Sicherheitsprobleme entstehen oft dort, wo ein System im Alltag kleinteilig wird: ein Spezialpfad beim Passwortwechsel, ein Exportendpunkt, ein Projektbeitritt, ein Upload, ein Rollenwechsel, eine Fehlermeldung oder ein Recovery-Flow. Solche Stellen kann das eigene Team übersehen, gerade weil es die beabsichtigte Architektur gut kennt.
3. Warum Nähe blinde Flecken erzeugt
Nähe zur Schule ist eine Stärke von Ephraim. Die Anforderungen kommen aus echter pädagogischer Praxis und nicht aus einem abstrakten Produktkonzept. Dieselbe Nähe kann aber blinde Flecken erzeugen. Wer ein System gebaut hat, liest Abläufe häufig so, wie sie gemeint waren, nicht so, wie sie missbraucht werden könnten.
Externe Reviewer bringen eine andere Haltung mit. Sie fragen weniger, ob ein Ablauf sinnvoll gedacht ist. Sie fragen, ob ein Nutzer ihn umgehen kann, ob ein Token zu viel darf, ob eine Rolle einen fremden Gegenstand erreicht, ob ein Browserpayload gerendert wird oder ob ein Schlüssel für zu viele Zwecke verwendet wird.
4. Welche Grenzen wir offen benennen
Ephraim ist weit für ein schulisches Projekt, aber genau diese Breite ist auch ein Risiko. Chat, Projekte, Dateien, Basiswissen, TTS, Adminfunktionen, Kryptografie, Rollen und lokale KI greifen ineinander. Kein kleines Team kann aus eigener Nähe heraus behaupten, alle Wechselwirkungen vollständig zu sehen.
| Grenze | Warum sie relevant ist |
|---|---|
| Eigenes Team | Wer das System gebaut hat, kennt die Absicht. Externe Reviewer sehen eher, wie dieselbe Funktion missbraucht werden kann. |
| KI-gestützte Entwicklung | KI kann Code, Tests und Audits beschleunigen. Sie kann aber auch plausibel klingende Sicherheitserzählungen erzeugen. |
| Lokale Tests | Lokale DDEV- und Browserprüfungen sind wertvoll, ersetzen aber keine spätere Betriebsprüfung unter realen Zuständigkeiten. |
| Dokumentation | Handbücher schaffen Transparenz. Sie dürfen aber nicht schöner klingen als der geprüfte Stand tatsächlich ist. |
| Restunsicherheit | Auch nach behobenen Befunden bleiben neue Kombinationen, neue Funktionen, neue Konfigurationen und menschliche Fehler möglich. |
Diese Grenzen sind kein Argument gegen Ephraim. Sie sind der Grund, warum externe Reviews gesucht werden und warum die eigene Review-Struktur nicht als Zertifikat, sondern als Einladung zur Gegenprüfung verstanden wird.
5. Welche externen Reviews wir suchen
Für Ephraim sind drei Reviewarten besonders wichtig. Sie sind vorbereitet, aber aktuell noch nicht extern übernommen oder abgeschlossen. Zusammen würden sie dieselbe Plattform aus unterschiedlichen Richtungen betrachten und ein belastbareres Bild ergeben als ein pauschales Sicherheitsurteil.
Daneben kann Ephraim auch breitere Audits sammeln, etwa zu Systemzustand, Wartbarkeit, UI/UX oder Betrieb. Solche Audits helfen beim Gesamtbild, dürfen aber nicht als Sicherheitsfreigabe gelesen werden. Für die Code-Sicherheit bleiben die folgenden Reviewarten der harte Maßstab.
| Reviewart | Worauf der Blick fällt | Warum das für Schulen zählt |
|---|---|---|
| Architektur- und Threat-Model-Review | Komponenten, Rollen, Datenflüsse, Vertrauensgrenzen, Schutzannahmen und Missbrauchsszenarien. | Schulische KI braucht erklärbare Grenzen, nicht nur eine funktionierende Oberfläche. |
| Webanwendungs-Pentest | Anmeldung, 2FA, Sessions, CSRF, XSS, Uploads, Projektcodes, Exporte, Adminfunktionen und APIs. | Viele Risiken entstehen nicht im Modell, sondern an Formularen, Rechten, Endpunkten und Bedienwegen. |
| Kryptografisches Implementierungsreview | Schlüssel, Tokens, Signaturen, Zufall, Recovery, Vault, Zwecktrennung und Fehlerverhalten. | Verschlüsselung hilft nur, wenn Schlüsselwege, Token-Grenzen und Wiederherstellung sauber gebaut sind. |
6. Was ein externer Gegenblick leisten soll
Externe Reviews sollen Ephraim nicht einfach bestätigen. Sie sollen Annahmen angreifen, Lücken finden, falsche Sicherheit benennen und Prioritäten korrigieren. Ein guter Review kann auch Entwarnung geben, aber nur dort, wo ein konkreter Pfad wirklich nachvollziehbar geprüft wurde.
Entscheidend ist der Nachweis: Was wurde geprüft? Welcher Systemstand galt? Welche Rolle, welcher Datenfluss oder welcher Token war im Fokus? Welche Belege liegen vor? Welche Befunde bleiben offen? Genau diese Fragen führen zum zweiten Artikel: dem Lösungsansatz.