Lösungsansatz: Review-System, Audits und Verify
Ephraim bittet um externe Reviews und möchte sie ausdrücklich gewinnen. Damit ein unabhängiger Blick nicht bei null anfangen muss, hat das Projekt eine Struktur vorbereitet, in der Code- und Architektursicherheit streng prüfbar bleiben und breitere Audits nachvollziehbar danebenstehen: getrennte Reviewspuren, dokumentierte Freigaben, Befundregister, Fixlogs, Verify-Läufe, Reviewer-Packs und Seiten für Menschen.
1. Welche Vorarbeit bereits geleistet wurde
Wer ein externes Review übernehmen möchte, trifft nicht auf eine leere Bitte um Hilfe. Ephraim hat bereits eine Review-Struktur aufgebaut, damit externe Reviewer schnell sehen, welche Fragen das Projekt selbst gestellt hat und wo Gegenprüfung besonders wertvoll ist.
Die Security-Review-Spuren bleiben dabei der strengere Kern: Dort zählen Scope, Belege, Finding, Verify und Re-Verify. Breitere Audits nutzen dieselbe nachvollziehbare Dokumentationslogik, betrachten aber auch Systemzustand, Qualität, Bedienbarkeit oder Betrieb. Sie dürfen deshalb nicht automatisch als Sicherheitsfreigabe gelesen werden.
| Baustein | Wozu er dient |
|---|---|
| Reviewspuren | Architektur, Threat Model, Webanwendung und Kryptografie werden getrennt geprüft, damit Befunde nicht vermischt werden. |
| Freigabegrenzen | Aktive Tests sind lokal, defensiv und mit synthetischen Daten vorgesehen. Produktion und echte Nutzerdaten bleiben ausgeschlossen. |
| Befundregister | Findings haben Status, Schweregrad, Herkunft, Entscheidung und Nachweis statt nur lose Notizen. |
| Verify-Spur | Jedes Review-Ergebnis wird nachvollziehbar, weil Fund, Entwarnung, Verify, Fix und Re-Verify getrennt dokumentiert werden. |
| Seiten für Menschen | Für externe Reviewer gibt es eine Übersicht zu Security-Reviews und eine zweite Übersicht für breitere Audits, historische Stände und Folgeaufgaben. |
2. Welche Review- und Auditspuren vorbereitet sind
Ephraim trennt die Prüfung bewusst in mehrere Spuren. Dadurch kann ein Architekturproblem anders dokumentiert werden als ein XSS-Risiko, ein Kryptografieproblem oder eine offene Annahme im Threat Model. Zusätzlich gibt es breitere Auditspuren, damit Qualitäts-, UI-, Betriebs- und Systemfragen nicht in Sicherheitsfindings hineingedrückt werden.
| Spur | Typische Fragen |
|---|---|
| Architektur | Welche Komponenten sprechen miteinander? Wo liegen Rollen- und Objektgrenzen? Welche Annahmen müssen im Code bestätigt werden? |
| Threat Model | Welche Assets sind besonders schutzbedürftig? Welche Angreiferrollen sind realistisch? Welche Abuse-Cases müssen getestet werden? |
| Webanwendung | Halten Authentifizierung, Autorisierung, CSRF-Schutz, Rendering, Uploads, Exporte und Adminwege auch in negativen Tests? |
| Kryptografie | Sind Token, Schlüssel, Recovery-Codes, Signaturen und Vault-Flows zweckgebunden, zufallsstark und nachvollziehbar? |
| Verify | Trägt eine Entwarnung? Ist ein Fund wirklich ein Problem? Wurde ein Fix danach unabhängig re-verifiziert? |
| Systemaudit | Ist der Systemzustand nachvollziehbar, sind zentrale Pfade dokumentiert und bleiben bekannte Altstände sichtbar? |
| Qualität und Wartbarkeit | Wo entstehen technische Schulden, fragile Kopplungen, unklare Verantwortlichkeiten oder fehlende Tests? |
| UI/UX-Audit | Sind Bedienwege verständlich, barrierearm, konsistent und für die jeweiligen Rollen nachvollziehbar? |
| Betriebsaudit | Sind Logging, Backup, Wiederherstellung, Updates, Monitoring und Zuständigkeiten belastbar beschrieben? |
3. Architektur des Review-Systems
Ein Review beginnt mit einem abgegrenzten Prüffeld und einer dokumentierten
Freigabe für aktive Tests. Danach entstehen Bericht, menschliche
Zusammenfassung und Belege. Das erste Ergebnis ist ein Fund oder eine
vorläufige Entwarnung. Beides geht anschließend in Verify: Ein unabhängiger
Prüfer liest Scope, Methode, Belege und Ergebnis gegen. Erst wenn Verify
ein Problem bestätigt, bleibt oder entsteht ein SEC-*-Finding. Nach dem
Fix folgt Re-Verify.
SEC-*-Finding, Fixlauf und Re-Verify.
4. Das Multi-Modell-Konzept
Ephraims Review-System setzt nicht darauf, dass ein einzelnes KI-Modell Sicherheit abschließend beurteilen kann. Verschiedene Agenten und Modelle lesen Code, Berichte und Belege aus unterschiedlichen Blickwinkeln. Ein Modell strukturiert vielleicht die Architekturfrage gut, ein anderes findet eher Webpfade, ein weiteres formuliert bessere Negativtests oder erkennt Widersprüche in der Dokumentation.
Der Nutzen liegt nicht in einem Modellwettbewerb. Der Nutzen liegt in Reibung: mehrere Durchläufe, verschiedene Formulierungen, andere Schwerpunkte und eine dokumentierte Spur, die Menschen anschließend prüfen können. KI kann hier sehr hilfreich sein, weil sie große Mengen Code, Tests und Dokumentation schnell ordnet. Verbindlich wird ein Ergebnis aber erst durch Verify, Bewertung, Umsetzung und Re-Verify nach einem Fix.
5. Was der Lösungsansatz nicht behauptet
Die vorbereitete Review-Struktur ist ein Fortschritt, aber sie ist kein Sicherheitssiegel. Ein Register, ein Diagramm, Seiten für Menschen und mehrere KI-gestützte Läufe beweisen nicht automatisch, dass kein Fehler mehr im System steckt. Sie machen nur besser sichtbar, was geprüft, behoben, verworfen oder noch offen ist.
| Behauptet wird nicht | Stattdessen gilt |
|---|---|
| Alle Risiken sind erledigt. | Bekannte Befunde werden nachverfolgt. Neue Reviews können neue Befunde erzeugen. |
| KI kann unabhängige Prüfung ersetzen. | KI hilft beim Lesen, Sortieren und Testen. Entscheidungen brauchen menschliche Bewertung. |
| Lokale Inferenz löst jedes Sicherheitsproblem. | Lokale KI reduziert Datenabflussrisiken. Weblogik, Rollen, Tokens und Betrieb müssen trotzdem geprüft werden. |
| Ein internes Review ist ein externes Audit. | Interne Reviews schaffen Vorarbeit. Externe Reviewer sollen diese Vorarbeit ausdrücklich angreifen dürfen. |
| Ein breites Audit ist eine Sicherheitsfreigabe. | Audits können Qualität, Betrieb oder Bedienbarkeit prüfen. Sicherheitsentlastung braucht weiterhin Scope, Belege und Verify. |
6. Schutzgrenzen bei aktiven Tests
Sicherheitsreviews dürfen nicht selbst zum Risiko werden. Aktive Tests laufen deshalb nur gegen freigegebene lokale Ziele und mit synthetischen Daten. Produktivsysteme, echte Konten, echte Schülerdaten und externe Dienste sind ohne gesonderte Freigabe ausgeschlossen. Wenn Datenbankzustände verändert werden müssen, geschieht das temporär, mit Rücknahme oder in einem dokumentierten Klon.
| Grenze | Konsequenz für Reviews |
|---|---|
| Keine echten Nutzerdaten | Tests arbeiten mit fiktiven Konten, harmlosen Dateien und redigierten Artefakten. |
| Keine Produktionstests ohne Freigabe | Normale Reviews bleiben in der lokalen Entwicklungs- und Testumgebung. |
| Keine destruktiven Angriffe | Rate-Limits, Uploads, XSS und CSRF werden defensiv und mit harmlosen Markern geprüft. |
| Keine Geheimnisse in Artefakten | Tokens, Cookies, Passwörter, Mailinhalte und vollständige Adressen werden nicht veröffentlicht. |
7. Vom Befund zur Korrektur
Ein Sicherheitsbefund ist kein Scheitern. Er ist der Punkt, an dem ein Risiko überprüfbar wird. Ephraim unterscheidet deshalb zwischen offenen Befunden, verworfenen Befunden, akzeptierten Restrisiken, behobenen Befunden und nachgeprüften Fixes.
In der bisherigen Reviewarbeit wurden unter anderem Session-Grenzen, CSRF-Muster, Recovery-Codes, Token-Zwecktrennung, Objektberechtigungen und Projektbeitritte untersucht. Mehrere Befunde wurden behoben und re-verifiziert. Genau dieses Muster soll weitergeführt werden: finden, verifizieren, beheben, re-verifizieren, erklären.
8. Seiten für externe Reviewer und Audits
Die Seite für Security-Reviews bündelt Chronologie, Kennzahlen, Ablauf und Quellenhinweise. Sie ersetzt keine Prüfberichte, ist aber ein überzeugender Startpunkt für Menschen, die ein externes Security-Review übernehmen möchten: Die technische Struktur steht, die Reviewarten sind getrennt, die Sicherheitsgrenzen sind definiert und bisherige Befunde sind nachvollziehbar.
Die folgenden Momentaufnahmen zeigen die aktuellen menschlichen HTML-Übersichten vollständig.
Daneben gibt es eine Audit-Übersicht für breitere Prüfungen. Dort können historische Auditstände, System-, Qualitäts-, UI-/UX- und Betriebsprüfungen sowie offene Folgeaufgaben sichtbar werden, ohne den strengeren Security-Review-Begriff zu verwässern.
Für Schulleitung, Datenschutzbeauftragte, Eltern und Lehrkräfte ist die Botschaft ähnlich wichtig. Ephraim setzt nicht nur auf lokale KI und Verschlüsselung. Ephraim behandelt Code-Sicherheit als laufenden Prozess, der dokumentiert, korrigiert und von außen überprüfbar sein muss.
Die fachlichen Nachbarartikel sind Problem, Systemarchitektur, Datenschutz tiefgehend, Kryptoarchitektur, Datei-Sicherheit und Session-Management.