tessera-ctl/docs/sicherheitsprotokoll.md

Sicherheitsprotokoll

Dieses Protokoll hält an einer Stelle fest, wie sicher Tessera ist, was dafür bisher geprüft wurde und was dabei herauskam. Es richtet sich an die Inhaberin oder den Inhaber der Plattform und an spätere Kunden, die wissen möchten, wie sorgfältig Tessera geprüft wird. Sie müssen dafür kein Programmierer sein: Fachbegriffe werden beim ersten Auftreten erklärt.

Stand: 9. Oktober 2026.

Das Protokoll wird laufend fortgeschrieben. Jede neue Sicherheitsprüfung, jede festgehaltene Messung und jede Außenprüfung vor einer Freigabe bekommt unter „Verlauf“ einen eigenen Eintrag, der neueste steht oben. Wie die Pflege abläuft, steht in der Entwicklungsanleitung.

Das Protokoll enthält bewusst keine Passwörter, keine Zugangsdaten und keine Anleitungen, mit denen sich ein Fehler ausnutzen ließe. Es nennt Bausteine und Schweregrade in Alltagssprache.

Auf einen Blick

• Zugangsdaten im Quelltext: Es wurden keine echten Passwörter oder Schlüssel gefunden. Die gesamte Änderungsgeschichte des Projekts wurde durchsucht; alle 20 Treffer waren Fehlalarme, nämlich Testschlüssel, Beschriftungen und Beispiele in Notizen.
• Fremde Bausteine: Die erste Prüfung verzeichnete 151 bekannte Schwachstellen in den Bausteinen anderer Hersteller, die Tessera im Betrieb verwendet, davon 5 kritische und 73 hohe. Am 9. Oktober 2026 wurden die Bausteine innerhalb ihrer bisherigen Versionslinien aktualisiert und zwei ungenutzte Bausteine entfernt; ein Abschlusslauf der automatischen Prüfung bestätigt den Stand: 12 (0 kritische, 9 hohe, 3 mittlere). Die übrigen 12 haben keine bereinigte Fassung in der verwendeten Versionslinie (xlsx, node-forge) oder werden erst in einer neuen Hauptversion behoben (nodemailer, sharp, deepmerge-ts); sie sind unter „Einordnung der Befunde“ mit Grund eingeordnet.
• Eigener Quelltext: Ein einziger echter Härtungspunkt wurde gefunden (die Längenprüfung bei der Entschlüsselung gespeicherter Geheimnisse, Schweregrad niedrig); er ist am 9. Oktober 2026 behoben und durch Tests abgesichert. Alles andere sind Fehlalarme oder bewusste, dokumentierte Entscheidungen.
• Automatische Prüfung: Seit dem 9. Oktober 2026 läuft nach jedem Bau der Plattform automatisch eine Sicherheitsprüfung. Sie meldet nur und hält den Bau nie an. Ihr Abschlusslauf am selben Tag, im echten Bau-Umfeld auf dem bereinigten Stand, fand keine Zugangsdaten in der gesamten Geschichte und keinen kritischen Fund in den Bausteinen im Betrieb; die Zahlen vorher und nachher stehen im Abschnitt „Stand nach der Behebung“.
• Prüfung von außen: Vor jeder Freigabe wird der Testserver alpha wie ein Besucher ohne Konto angesehen, rein passiv und ohne Angriffe. Der erste Lauf am 9. Oktober 2026 (direkt gegen die Anwendung, ohne den vorgeschalteten Proxy) fand nichts Hohes, 2 mittlere und 6 niedrige Hinweise sowie 3 reine Informationen; alle betreffen fehlende Schutz-Kopfzeilen der Weboberfläche. Die Anwendung sendet diese Kopfzeilen seit dem 9. Oktober 2026 selbst (bis auf eine vollständige Inhaltsrichtlinie, die offen bleibt). Der Lauf über die öffentliche Adresse steht noch aus und zeigt, ob auch der Proxy sie durchreicht.
• Bisherige Prüfungen: Neun Code-Prüfungen größerer Änderungen mit zusammen 98 Befunden; 85 davon sind behoben. Offen sind nur noch 13 Hinweise der niedrigsten Stufe. Alle kritischen Befunde und alle Warnungen sind behoben.
• Was noch zu tun ist: Die Abbilder enthalten seit dem 9. Oktober 2026 keine Entwicklungswerkzeuge und keine Paketverwaltung mehr (das Server-Abbild ist von 1,66 GB bei der ersten Prüfung auf 1,12 GB geschrumpft, seine Fundzahl von 6 kritischen und 116 hohen auf 0 kritische und 6 hohe gefallen; das Web-Abbild von 2 kritischen und 19 hohen auf 0 kritische und 3 hohe). Offen bleiben einzelne Bausteine ohne bereinigte Fassung, die Bausteine, die erst mit einer neuen Hauptversion zu beheben sind, einige Hinweise zu Bausteinen der Desktop-App, die Gesundheitsprüfung der Weboberfläche, die vollständige Inhaltsrichtlinie sowie die Außenprüfung über die öffentliche Adresse; sie werden bei neuen Fassungen der Hersteller und bei der nächsten Außenprüfung erneut angesehen. Der Stand jedes einzelnen Punkts steht in der Tabelle „Einordnung der Befunde“, eine Liste in Alltagssprache im Abschnitt „Stand nach der Behebung“.

So lesen Sie dieses Protokoll

Schweregrade. Prüfwerkzeuge sortieren ihre Funde in vier Stufen. In diesem Protokoll bedeuten sie:

• Kritisch: Ein Fehler, den ein Angreifer unter ungünstigen Umständen aus der Ferne und mit großer Wirkung ausnutzen könnte. Hat Vorrang vor allem anderen.
• Hoch: Ein ernster Fehler, meist mit Voraussetzungen, zum Beispiel einer vorherigen Anmeldung.
• Mittel: Ein Fehler mit begrenzter Wirkung oder hohen Hürden.
• Niedrig: Eine Verbesserung der Vorsorge ohne unmittelbare Gefahr.

Bei den Code-Prüfungen (Abschnitt „Bisherige Sicherheitsprüfungen“) verwendet der Prüfer die Wörter „kritisch“, „Warnung“ und „Hinweis“. „Kritisch“ heißt dort: muss vor der Freigabe behoben werden. Das ist nicht immer eine Sicherheitslücke, sondern kann auch ein Funktionsfehler sein.

Stand eines Befunds. Jeder Befund trägt genau eines von drei Wörtern:

• behoben: Der Fehler ist korrigiert, mit Datum oder Verweis auf die Änderung.
• bewusst akzeptiert: Der Befund bleibt, weil das Risiko hier nicht zutrifft oder tragbar ist. Der Grund steht immer dabei.
• offen: Der Befund ist bekannt, aber noch nicht behoben. Grund und Einschätzung stehen dabei.

Fehlalarm ist keine Stufe, sondern eine Einschätzung: Das Werkzeug hat etwas gemeldet, aber nach Prüfung von Hand liegt gar kein Fehler vor. Ein Beispiel ist ein Testschlüssel, der nur zum Prüfen der Software gedacht ist und nirgends etwas schützt. Fehlalarme werden begründet in Ausnahmelisten eingetragen, damit künftige Berichte aussagekräftig bleiben.

Abhängigkeit nennt man einen Baustein eines Fremdherstellers, auf dem Tessera aufbaut. Ein Abbild ist ein fertig gebauter Container: das Paket, das auf dem Server gestartet wird. Eine Schwachstelle ist ein bekannter Fehler in einem Baustein, der unter bestimmten Umständen ausgenutzt werden kann.

Wie die Prüfungen arbeiten

Die automatische Prüfung bei jedem Bau

Immer wenn eine neue Fassung von Tessera gebaut wird, läuft zum Schluss ein eigener Arbeitsschritt namens „Sicherheitsprüfung (nur Bericht)“. Er startet erst, nachdem die Abbilder fertig gebaut sind, und nur für den Zweig, aus dem die Beta-Fassung entsteht, sowie für Freigabe-Marken. Er hat drei Eigenschaften, die Sie sich merken sollten:

• Er meldet nur. Findet er etwas, bleibt der Bau trotzdem grün. Er kann weder den Bau noch Tests noch die Veröffentlichung aufhalten.
• Er sieht keine Geheimnisse. Der Schritt bekommt keinerlei Passwörter oder Zugangsschlüssel der Pipeline.
• Er prüft genau den eingecheckten Stand. Nicht eingecheckte Dateien eines Arbeitsrechners erreichen keines der Werkzeuge und keinen Bericht.

Die Zahlen erscheinen als Zeilen, die mit „SECURITY-SUMMARY“ beginnen, im Protokoll des Laufs. Die Rohberichte hängen, soweit der Server das zulässt, als Download namens „sicherheitsberichte“ am Lauf. Die Werkzeuge sind auf feste Fassungen festgelegt und werden vor jeder Verwendung gegen eine Prüfsumme geprüft; passt die Prüfsumme nicht oder ist das Netz nicht erreichbar, wird nur das betroffene Werkzeug übersprungen. Jedes Werkzeug hat ein eigenes Zeitlimit; zusammen halten sie sich an 25 Minuten, das Zeitlimit des ganzen Schritts beträgt 30. Jedes Werkzeug meldet seine Zeile, sobald es fertig ist, damit ein Abbruch keine fertigen Ergebnisse verschluckt. Wird die Prüfung in einer verkürzten Kopie der Geschichte ausgeführt, meldet sie bei den Zugangsdaten „unvollständig“ statt eines scheinbar sauberen Ergebnisses. Die technischen Einzelheiten stehen im Pipeline-Handbuch und in der Entwicklungsanleitung.

Zugangsdaten im Quelltext und in seiner Geschichte (gitleaks)

Das Werkzeug gitleaks durchsucht jede jemals gespeicherte Fassung des Projekts nach Dingen, die wie Passwörter, Schlüssel oder Zugangscodes aussehen. Das ist wichtig, weil ein einmal versehentlich gespeichertes Passwort auch nach dem Löschen in der Geschichte stehen bleibt. Die Berichte zeigen gefundene Werte nur geschwärzt. Geprüfte Fehlalarme stehen in der Datei .gitleaks.toml, jeweils so eng wie möglich und mit einer Begründung.

Fremde Bausteine (pnpm audit, osv-scanner, Trivy auf die Paketlisten)

Tessera besteht zu einem großen Teil aus Bausteinen anderer Hersteller. Drei Werkzeuge vergleichen die Paketlisten des Projekts mit öffentlichen Listen bekannter Schwachstellen:

• pnpm audit fragt das Verzeichnis des Paketverwalters ab und zählt hier nur die Bausteine, die im Betrieb tatsächlich laufen („Produktion“). Bausteine, die nur beim Entwickeln gebraucht werden, zählen getrennt.
• osv-scanner vergleicht dieselbe Paketliste mit einer zweiten, unabhängigen Datenbank und prüft zusätzlich die Paketliste der Desktop-App.
• Trivy liest die Paketlisten ebenfalls und prüft außerdem die Einstellungen der Abbild-Baupläne (zum Beispiel, ob eine Gesundheitsprüfung eingetragen ist) und sucht noch einmal nach Zugangsdaten.

Eigener Quelltext (Semgrep)

Semgrep liest den von uns geschriebenen Quelltext und sucht nach Mustern, die erfahrungsgemäß zu Fehlern führen, etwa unsichere Verschlüsselungsaufrufe oder ausgeschaltete Zertifikatsprüfungen. Das Werkzeug meldet viel mehr als echte Fehler; jeder Treffer wird deshalb von Hand beurteilt. Testdateien, Testdaten und Planungsnotizen sind ausgenommen, denn sie werden nicht ausgeliefert. Semgrep läuft in seinem offiziellen Container, der über eine feste Kennung (den Digest) angepinnt ist: Docker prüft beim Laden, dass der Inhalt genau zu dieser Kennung passt, und es werden keine Zusatzpakete frei aus dem Internet nachgeladen.

Fertige Abbilder (Trivy)

Zum Schluss prüft Trivy die beiden fertig gebauten Abbilder, api und web, so wie sie auf einem Server laufen würden. Dabei zählt es auch die Pakete des Betriebssystems im Abbild und alles, was im Abbild zusätzlich steckt, etwa Entwicklungswerkzeuge. Deshalb liegen die Zahlen hier über denen der Paketlisten.

Prüfung von außen vor einer Freigabe (OWASP ZAP)

Vor jeder Freigabe sieht sich Claude den Testserver alpha von außen an, so wie ein Besucher ohne Konto: Startseite, Anmeldeseite, die mitgelieferten Kopfzeilen, Cookies und die ausgelieferten Dateien. Dafür wird das frei verfügbare Werkzeug OWASP ZAP in einem Container gestartet. Es arbeitet nur passiv: Es ruft Seiten ab und wertet aus, was der Server zurückschickt. Es füllt keine Formulare aus, sendet keine Daten an die Anwendung und probiert keine Angriffe aus. Ein Probelauf gegen eine eigens dafür gebaute Testseite mit Anmeldeformular hat bewiesen, dass dabei kein einziges Absenden (POST) stattfindet.

Der Zugangsschutz (Basic Auth) vor alpha bleibt, wie er ist. Die Prüfung läuft vom internen Entwicklungsrechner aus, für den der Zugangsschutz keine Anmeldung verlangt. Falls alpha diesen Rechner einmal doch nach einer Anmeldung fragt, kann das Skript die Zugangsdaten aus einer Datei außerhalb des Projekts lesen. Das Ergebnis jedes Laufs wird in diesem Protokoll festgehalten (Abschnitt „Prüfung von außen gegen alpha“ und „Verlauf“). Den Ablauf beschreibt der Schritt „Eine Version freigeben“ in der Betriebsanleitung; die technischen Einzelheiten stehen in der Entwicklungsanleitung.

Prüfung durch Menschen und Künstliche Intelligenz

Neben den Werkzeugen gibt es Prüfungen, die durch Lesen und Nachdenken entstehen:

• Code-Prüfungen durch Claude nach größeren Änderungen. Der Prüfer liest den geänderten Quelltext, sucht Fehler, Sicherheitslücken und Schwächen im Aufbau und schreibt jeden Befund mit Fundstelle und Verbesserungsvorschlag auf. Behobene Befunde bekommen einen Prüftest, der vorher rot war und nach der Korrektur grün ist.
• Bedrohungsbetrachtungen in den Plänen: Vor dem Bau einer Funktion wird aufgeschrieben, was schiefgehen kann (Angriffsmöglichkeiten, Missbrauch, Fehlbedienung) und womit sich das verhindern lässt. Die Maßnahmen werden später mit der Umsetzung abgeglichen.
• Automatische Tests, die einmal gefundene Fehler festnageln, darunter die Tests zur Datentrennung zwischen Organisationen auf Datenbankebene und viele Tests zum Schutz vor Missbrauch (siehe unten).

Bisherige Sicherheitsprüfungen

Code-Prüfungen

Neun Code-Prüfungen wurden bisher durchgeführt. Die Spalte „Nachweis“ nennt die interne Bezeichnung der Prüfung.

Datum	Prüfung	Umfang	Ergebnis	Stand	Nachweis
27.06.2026	DKV-Modul (Fahrzeugflotte)	44 Dateien	3 kritisch, 5 Warnungen, 4 Hinweise (12). Kritisch waren Funktionsfehler wie ein falsch gezählter Import, ein falsch berechneter Zeitplan und eine nicht geschlossene Postfach-Verbindung; dazu Warnungen zu Dateigrößen und Dateinamen	Alle 8 kritischen Befunde und Warnungen behoben am 27.06.2026. Die 4 Hinweise wurden nicht bearbeitet	Phase 07
01.07.2026	Dashboard-Kacheln, Favoriten, Symbol-Abruf	24 Dateien	2 kritisch, 5 Warnungen, 3 Hinweise (10). Kritisch: Der Schutz vor Abrufen interner Adressen ließ sich mit einer versteckten IPv6-Schreibweise umgehen, und die Favoriten-Abfrage ohne Kachelangabe lieferte alle Favoriten des Benutzers	2 kritische Befunde, 5 Warnungen und 1 Hinweis behoben am 01.07.2026 (eine gemeinsame Änderung). 2 Hinweise zu Anzeigetexten offen	Phase 08
06.08.2026	AD-Gruppen-Synchronisation	21 Dateien	0 kritisch, 4 Warnungen, 2 Hinweise (6). Die Warnungen betrafen unter anderem das versehentliche Löschen einer im Verzeichnis nur verschobenen Gruppe samt Freigaben	4 Warnungen behoben am 06.08.2026. 2 Hinweise (ein veralteter Kommentar, eine fehlende Längenbegrenzung eines Namensfelds) offen	Phase 16
16.09.2026	Desktop-App, Aktualisierung und Abbild-Bau	23 Dateien	1 kritisch, 3 Warnungen, 2 Hinweise (6). Kritisch: Eine Prüfung von Dateinamen ließ Namen aus nur Punkten zu	4 behoben am 16.09.2026, jeder mit Test. 2 Hinweise nicht bearbeitet	Phase 18
08.10.2026	Domains und AutoDNS	37 Dateien	1 kritisch, 6 Warnungen, 4 Hinweise (11). Kritisch: Bei Serverfehlern wurde eine Bestellung als „nicht aufgegeben“ gewertet, obwohl sie evtl. angekommen war (Gefahr der Doppelbestellung)	8 behoben am 08.10.2026 (der kritische Befund, alle 6 Warnungen und 1 Hinweis). 3 Hinweise offen, weil sie eine Datenbankänderung beziehungsweise einen eigenen Entwurf brauchen	quick-261008-dts
08.10.2026	Modul Dateien (Nextcloud)	54 Dateien	2 kritisch, 9 Warnungen, 7 Hinweise (18). Kritisch: Die Begrenzung von Passwortversuchen ließ sich durch gleichzeitige Anfragen umgehen, und ein Benutzer mit der Freigabe „Verwalten“ konnte die Nextcloud-Adresse für alle Benutzer umlenken	Alle 18 behoben am 08.10.2026	quick-261008-mzu
09.10.2026	Modul Dateien, Teilen (Nextcloud-Freigaben)	5 Änderungen	1 kritisch, 4 Warnungen, 6 Hinweise (11). Kritisch: Pfade und Kennungen wurden beim Anzeigen verändert, wodurch Freigaben auf die falsche Datei zeigen konnten	Alle 11 behoben am 09.10.2026; dazu zwei Nachbesserungen aus der Prüfung (Anzeige der Rechte eines Ordners, Zähler gegen zu viele Freigabe-Versuche)	quick-261009-dkv
09.10.2026	Zertifikatsmanager (Umbau, Abruf fremder Adressen, ZIP)	62 Dateien	3 kritisch, 7 Warnungen, 5 Hinweise (15). Kritisch: (1) eine „ZIP-Bombe“, bei der eine gefälschte Größenangabe alle Grenzen umging; (2) ein Suchmuster für Zertifikatsblöcke, das bei einer kleinen Datei die Programmschleife minutenlang blockierte; (3) PFX-Dateien mit Umlauten im Passwort ließen sich nicht richtig lesen und schreiben	Alle 15 behoben am 09.10.2026. Jeder kritische Befund hat einen Test, der gegen den alten Code rot war. Der Schutz vor Abrufen interner Adressen wurde dabei zusätzlich gehärtet (siehe unten)	quick-261009-ikt
09.10.2026	Sicherheitsauftrag (Prüfskripte der Pipeline, Außenprüfung, Abbilder, Kopfzeilen, Entschlüsselung)	24 Dateien	0 kritisch, 5 Warnungen, 4 Hinweise (9). Die Warnungen betrafen: den Prisma-Baustein des Server-Abbilds, der bei einem Fehler still fehlen konnte; Semgrep, das ohne feste Prüfsumme aus dem Internet geladen wurde; die Zeitgrenzen der Prüfung, die zusammen weit über dem Zeitlimit des Jobs lagen; die Anmeldekopfzeile der Außenprüfung, die nicht auf das Ziel beschränkt war; und das Verhalten des Prüfschritts im ersten echten Pipeline-Lauf	8 behoben am 09.10.2026 (4 Warnungen und 4 Hinweise), jeweils mit Gegenprobe. Die letzte Warnung ist mit dem ersten echten Lauf am 09.10.2026 erledigt: Der Prüfschritt blieb grün, meldete alle Ergebnisse und brauchte 63 Sekunden	quick-261009-p0m

Summe: 9 Prüfungen, 98 Befunde (13 kritisch, 48 Warnungen, 37 Hinweise). Behoben sind 85, darunter alle kritischen Befunde, alle 48 Warnungen und 24 von 37 Hinweisen. Offen oder nicht bearbeitet sind 13 Hinweise der niedrigsten Stufe.

Drei Begriffe aus der Tabelle in Alltagssprache: Eine ZIP-Bombe ist eine kleine Datei, die sich beim Entpacken auf ein Vielfaches ihrer Größe aufbläht und den Server überlasten soll. Ein Suchmuster (regulärer Ausdruck) kann bei bestimmten Eingaben extrem lange rechnen; so lässt sich mit einer winzigen Datei ein Server lahmlegen. PFX ist ein passwortgeschütztes Dateiformat, das Zertifikat und Schlüssel zusammenfasst.

Härtung des gemeinsamen Adressschutzes (9. Oktober 2026)

Einige Funktionen rufen im Auftrag eines Benutzers Internetadressen ab: Symbole für Favoriten, Logos im Modul Nextcloud-Status und neu das Nachladen fehlender Zertifikate. Damit dabei nicht interne Systeme erreicht werden (man nennt diesen Angriff SSRF), gibt es einen gemeinsamen Adressschutz. Am 9. Oktober 2026 wurde er gehärtet: Er erkennt jetzt auch versteckte Schreibweisen interner IPv6-Adressen (zum Beispiel die gemappte Form von 127.0.0.1, NAT64, 6to4 und Teredo), und er beurteilt Adressen in eckigen Klammern. Beim Nachladen von Zertifikaten wird die Adresse außerdem noch einmal im Moment des Verbindens geprüft; erlaubt sind nur der Standardanschluss, höchstens drei Weiterleitungen, 8 Sekunden und 256 KiB. Eine neue Testdatei hält die Regeln fest.

Bedrohungsbetrachtungen in den Plänen

Seit Beginn des Projekts wird zu jedem Bauplan aufgeschrieben, was schiefgehen kann. Stand 9. Oktober 2026 enthalten 179 Pläne eine solche Bedrohungsbetrachtung; sie führen zusammen 884 verschiedene Bedrohungen mit Kennung auf. Zu den Bedrohungen gehört jeweils eine Maßnahme oder eine begründete Hinnahme. Die Zahlen wurden am Prüftag neu aus den Plandateien ausgezählt.

Datentrennung zwischen Organisationen

Für die Trennung von Daten verschiedener Organisationen gibt es einen eigenen Schutz auf Datenbankebene, der durch Tests abgesichert ist:

• Die Anwendung verbindet sich mit einer eigenen Datenbankrolle ohne Administratorrechte und ohne Recht, Schutzregeln zu umgehen.
• Jede Tabelle, die Daten einer Organisation trägt (zurzeit 20), hat eine Zeilenschutz-Regel: Die Datenbank liefert nur Zeilen der eigenen Organisation.
• Ein Startprüfprogramm weist mit fünf Proben nach, dass die Rolle und die Regeln so wirken, wie beschrieben.
• Fünf Wächter-Tests (vier Dateien rls-*.spec.ts und auth-lookup-functions.spec.ts) prüfen bei jeder Änderung, dass keine Tabelle ohne Regel hinzukommt, dass die Rolle keine Umgehungsrechte hat, dass das Startprüfprogramm richtig arbeitet, dass der Quelltext keinen Zugriff ohne Organisationsbezug enthält und dass die Hilfsfunktionen der Anmeldung stimmen.

Weitere Sicherheitsaufträge

Neben den Prüfungen gab es kleinere Aufträge mit Sicherheitsbezug:

Datum	Auftrag	Was es bewirkt
30.06.2026	quick-260630-gbh	Profilbild-Upload nur als PNG, JPEG oder WebP bis 2 MB, Dateiname aus dem Typ abgeleitet statt vom Benutzer übernommen; Passwortänderung in den Einstellungen nur für lokale Konten, nicht für Konten aus dem Verzeichnisdienst
01.07.2026	quick-260701-calendar-ssrf-fix-errors	Die Adressprüfung des Kalenders schützt vor Abrufen interner Adressen
09.09.2026	quick-260909-cx0	Hochgeladene Dateien liegen auf einem dauerhaften Speicher und sind in der Sicherung enthalten
11.09.2026	quick-260911-mkj	Die automatische Bestandsaufnahme der Datenbankzugriffe erkennt jetzt auch Zugriffe, die über Verknüpfungen in eine zweite Tabelle hineinreichen
14.09.2026	quick-260914-ebg	Ein Administrator kann ein Super-Administrator-Konto nicht mehr verändern oder löschen (Rechteausweitung geschlossen)
21.09.2026	quick-260921-fi3	Ein erzwungener Passwortwechsel wird jetzt von der Schnittstelle selbst durchgesetzt, nicht nur von der Oberfläche
21.09.2026	quick-260921-oxm	Die verschlüsselte Verbindung (STARTTLS) zum Postfach wird wirklich erzwungen
21.09.2026	quick-260921-m34	288 Stellen mit untypisiertem Code im Backend wurden einzeln beurteilt
08/2026	LDAP-Verbindung	Das Passwort der Verzeichnisdienst-Verbindung wird verschlüsselt gespeichert

Das Fehlerregister (WINDOWS)

Die Datei .planning/WINDOWS.md ist ein Fehlerregister über alle Bauabschnitte hinweg: Dort wird jede erkannte Schwäche, jeder nicht ausgeführte Test und jede bewusste Abweichung eingetragen, damit nichts unbemerkt liegen bleibt. Es hat 39 Einträge (Stand 21.09.2026): 25 behoben, 1 auf Entscheidung zurückgestellt, die übrigen 13 betreffen Randfälle der Datentrennung zwischen Organisationen und wirken im Betrieb einer einzelnen Firma nicht; sie werden hier deshalb nicht einzeln geführt. Sicherheitsrelevante Einträge, die behoben sind:

• Nr. 10: Die Zugriffsprüfung der Modulseiten griff bei den fest verdrahteten Modulrouten nicht; ein Benutzer ohne Freigabe sah die Seite. Behoben und im Browser nachgemessen (07.09.2026).
• Nr. 17: Hochgeladene Dateien überlebten kein Neuerstellen der Container. Behoben (09.09.2026).
• Nr. 27: Die automatische Bestandsaufnahme der Datenbankzugriffe war für Zugriffe über Verknüpfungen blind. Behoben (11.09.2026).
• Nr. 29: Rechteausweitung innerhalb einer Organisation (Administrator verändert Super-Administrator). Behoben (14.09.2026).

Sicherheitsrelevante automatische Tests

Rund 50 Testdateien in Server und Weboberfläche behandeln ausdrücklich Missbrauchsfälle, darunter ungültige Adressen und Umleitungen auf interne Systeme (SSRF), überlange oder bösartige Eingaben, ZIP-Bomben, Pfadtricks, Einschleusen von Befehlen und die Datenbankzugriffsregeln. Dazu kommen Ende-zu-Ende-Skripte in fünf Aufträgen, die gegen einen echten Stapel aus Datenbank, Server und Weboberfläche laufen, und rund 50 Nachweisberichte („Verification“) zu einzelnen Aufträgen. Die Bilanz des Meilensteins 1.1 steht in v1.1-MILESTONE-AUDIT.md.

Was es bisher nicht gab

Eine eigene, nachträgliche Abnahme der geplanten Schutzmaßnahmen je Bauabschnitt (in der Projektsteuerung „secure-phase“ genannt) wurde bisher nicht durchgeführt; entsprechende Berichte existieren nicht. Die Schutzmaßnahmen wurden stattdessen in den Code-Prüfungen und Tests oben kontrolliert. Ebenso gab es vor dem 9. Oktober 2026 keine automatische Suche nach Schwachstellen in fremden Bausteinen und keine Prüfung der fertigen Abbilder.

Erste vollständige Prüfung am 9. Oktober 2026

Was geprüft wurde: der damalige Stand des Quelltexts, die gesamte Änderungsgeschichte (1367 Änderungen), beide Paketlisten (Webportal und Server sowie die Desktop-App) und die beiden Beta-Abbilder. Werkzeuge: gitleaks 8.30.1, Trivy 0.75.0, osv-scanner 2.6.0, Semgrep 1.180.0 und pnpm audit mit pnpm 9.15. Die Werkzeuge haben nichts an unseren Servern geprüft; sie haben nur Verzeichnisse im Internet abgefragt.

Die Tabelle zeigt für jedes Werkzeug zwei Zahlen. „Rohwert“ ist der erste Lauf ohne Ausnahmelisten. „Nach den Ausnahmelisten“ ist ein späterer Lauf desselben Tages, nachdem die geprüften Fehlalarme (Testschlüssel, Testdateien, Planungsnotizen) eingetragen waren. Nach den Ausnahmelisten wurden die Abbilder und die Paketlisten genauso gezählt, nur die Zählweise der Abbilder umfasst jetzt auch die Pakete des Betriebssystems.

Prüfung	Rohwert	Nach den Ausnahmelisten	Was die Zahl bedeutet
Zugangsdaten in der Geschichte (gitleaks)	20 Treffer in 1367 Änderungen, 0 echte	0 Treffer in 1369 Änderungen	Es gibt kein echtes Passwort und keinen echten Schlüssel im Projekt. Die 20 Treffer waren Schlüsselmuster in Testschlüsseln und Textbeispielen (16), eine Beschriftung, ein Testwert und eine Tabellenzeile (3) und ein Beispielaufruf an einen Wegwerf-Testserver (1)
Fremde Bausteine im Betrieb (pnpm audit)	151: 5 kritisch, 73 hoch, 68 mittel, 5 niedrig, in 30 Bausteinen	unverändert	151 bekannte Schwachstellen. Die kritischen betreffen das Webframework Next.js, ein Vorlagenpaket für Mails und eine Hilfsbibliothek des Webservers
Fremde Bausteine, zweite Datenbank (osv-scanner)	43 verwundbare Bausteinfassungen von 1262 (nur Webportal und Server)	56 (mit der Desktop-App)	Eine andere Datenbank, andere Zählweise; die Desktop-App kommt hinzu
Paketlisten und Baupläne (Trivy auf den Quellstand)	Bausteine wie oben, Desktop-App 2 mittlere, Baupläne 2 niedrige Hinweise, 7 „Zugangsdaten“	Bausteine: 5 kritisch, 73 hoch, 70 mittel, 5 niedrig; Baupläne 2 niedrige; „Zugangsdaten“ 0	Die 7 Treffer waren die Testschlüssel des Zertifikatsmanagers. Die 2 niedrigen: In beiden Bauplänen fehlt eine eingebaute Gesundheitsprüfung
Eigener Quelltext (Semgrep)	58 Treffer (9 Fehler, 46 Warnungen, 3 mittlere); 59 Scanfehler	34 Treffer (2 Fehler, 29 Warnungen, 3 mittlere); 4 Scanfehler	Die Treffer sind unter „Einordnung der Befunde“ beurteilt: ein echter Härtungspunkt, sonst Fehlalarme und Entscheidungen. Die Ausnahmeliste nahm Testschlüssel, Tests und Notizen heraus
Abbild api (Trivy)	Bausteine: 6 kritisch, 116 hoch, 98 mittel, 7 niedrig; Betriebssystem 1 mittel	6 kritisch, 116 hoch, 99 mittel, 7 niedrig	Das Server-Abbild enthält Entwicklungswerkzeuge und einen Paketverwalter, die im Betrieb nichts tun, aber mitgezählt werden
Abbild web (Trivy)	Bausteine: 2 kritisch, 19 hoch, 21 mittel, 1 niedrig; Betriebssystem 1 mittel	2 kritisch, 19 hoch, 22 mittel, 1 niedrig	Die kritischen Funde sind dieselben des Webframeworks wie oben; dazu kommen Pakete des mitgelieferten Paketverwalters npm
Prüfung von außen (ZAP, direkt gegen die Anwendung auf alpha)	0 hoch, 2 mittel, 6 niedrig, 3 Informationen	keine Ausnahmelisten	Nur fehlende Schutz-Kopfzeilen der Weboberfläche und Hinweise zum Zwischenspeichern; Einzelheiten im Abschnitt „Prüfung von außen gegen alpha“

Gegenprobe: Um zu beweisen, dass die Ausnahmelisten nichts Echtes verdecken, wurde in einer Wegwerfkopie des Projekts ein erfundener Zugangscode (ein „Köder“) abgelegt. gitleaks und Trivy haben ihn gefunden. Die Kopie und der Köder wurden danach gelöscht.

Die Scanfehler bei Semgrep. Manche Dateien konnte Semgrep nur teilweise lesen oder brauchte zu lange dafür; das Werkzeug meldet das ausdrücklich als „Scanfehler“, statt es zu verschweigen. Im Rohlauf waren es 59 (43 Dateien nur teilweise gelesen, 16 Zeitüberschreitungen). Nach den Ausnahmelisten und einer Zeitgrenze pro Datei sind es noch 4 teilweise gelesene Dateien (die Pipeline-Datei und die beiden Abbild-Baupläne); eine Zeitüberschreitung gab es nicht mehr.

Stand nach der Behebung

Am Ende des 9. Oktober 2026 wurde die automatische Prüfung noch einmal vollständig auf dem bereinigten Stand ausgeführt: in einer frischen Kopie des Projekts, im selben Container-Abbild wie die Bau-Pipeline, gegen die lokal neu gebauten Abbilder api und web. Der Lauf endete ohne Fehler; die Werkzeuge, die schon beim ersten Lauf dabei waren, ergaben diese Zahlen. Die Spalte „Erste Prüfung“ zeigt die Rohwerte, die Spalte „Nach der Behebung“ den Abschlusslauf.

Prüfung	Erste Prüfung	Nach der Behebung	Was sich geändert hat
Zugangsdaten in der Geschichte (gitleaks)	20 Treffer, 0 echte	0 Treffer	Keine echten Geheimnisse, die 20 geprüften Fehlalarme stehen in der Ausnahmeliste
Bausteine im Betrieb (pnpm audit)	151: 5 kritisch, 73 hoch, 68 mittel, 5 niedrig	12: 0 kritisch, 9 hoch, 3 mittel, 0 niedrig	Alle kritischen Meldungen sind behoben; es bleiben Bausteine ohne bereinigte Fassung oder mit Korrektur erst in einer neuen Hauptversion
Bausteine, zweite Datenbank (osv-scanner, Webportal, Server und Desktop-App)	56	20 (8 im Webportal und Server, 12 in der Desktop-App)	Die Desktop-App ist mitgezählt; rustls und die Bausteine der Mail-Pakete sind behoben
Paketlisten und Baupläne (Trivy)	5 kritisch, 73 hoch, 70 mittel, 5 niedrig; Zugangsdaten 0 (nach Ausnahmeliste)	0 kritisch, 9 hoch, 4 mittel, 0 niedrig; Baupläne 2 niedrige Hinweise; Zugangsdaten 0	Entspricht der Aktualisierung der Bausteine
Eigener Quelltext (Semgrep)	58 Treffer (nach Ausnahmeliste 34, davon 2 Fehler)	33 Treffer (1 Fehler, 29 Warnungen, 3 mittlere); 4 Scanfehler	Die Stelle mit der Längenprüfung des Echtheits-Codes wird nicht mehr gemeldet; die übrigen Treffer sind beurteilt
Abbild api (Trivy)	6 kritisch, 116 hoch, 98 mittel, 7 niedrig; 1,66 GB	0 kritisch, 6 hoch, 4 mittel, 0 niedrig; 1,12 GB	Ohne Entwicklungswerkzeuge und Paketverwaltung; die 6 hohen sind Bausteine ohne Korrektur (nodemailer, xlsx, node-forge, deepmerge-ts)
Abbild web (Trivy)	2 kritisch, 19 hoch, 21 mittel, 1 niedrig; 359 MB	0 kritisch, 3 hoch, 1 mittel, 0 niedrig; 359 MB	Ohne Paketverwaltung des Node-Grundabbilds; die 3 hohen betreffen den Bildbaustein sharp
Prüfung von außen (ZAP)	0 hoch, 2 mittel, 6 niedrig, 3 Informationen (direkt gegen die Anwendung)	nicht neu gemessen	Die Schutz-Kopfzeilen sendet die Anwendung seit dem 9. Oktober 2026 selbst; der nächste Lauf über die öffentliche Adresse zeigt das Ergebnis

Was offen bleibt, in Alltagssprache:

• Tabellenbaustein xlsx und Zertifikatsbaustein node-forge: Die Hersteller haben keine bereinigte Fassung veröffentlicht. Beide verarbeiten nur Dateien angemeldeter Benutzer mit Modulfreigabe. Sie werden beobachtet; xlsx müsste durch einen anderen Baustein ersetzt werden.
• Mailversand nodemailer, Bildbaustein sharp und Datenbank-Hilfsbaustein deepmerge-ts: Die Korrektur gibt es erst in einer neuen Hauptversion. Ein solcher Wechsel ist ein eigener Schritt und gehörte nicht zu dieser Aktualisierung.
• Testwerkzeuge vitest 3 und tinypool: nur beim Entwickeln im Einsatz, nicht im Betrieb und nicht in den Abbildern; eine neue Hauptversion bringt die Korrektur.
• Desktop-App: der Baustein glib und elf weitere Hinweise zu Rust-Bausteinen, zum Teil über das Desktop-Framework; für drei gibt es Patch-Fassungen zum Anheben.
• Weboberfläche: keine Gesundheitsprüfung im Bauplan des Web-Abbilds, keine vollständige Inhaltsrichtlinie (eigener Auftrag, damit keine Seite bricht).
• Pipeline und Paketverwaltung: bewegliche Versionsnamen bei Bausteinen der Pipeline und drei Einstellungen der Arbeitsbereich-Datei, deren Wirkung in der eingesetzten Fassung noch nicht geprüft ist. Beides ist niedrig bewertet.
• Außenprüfung über die öffentliche Adresse: Sie steht aus, weil die Adresse vom Prüfrechner nicht erreichbar war. Sie zeigt auch die Verschlüsselung (HTTPS) und die Kopfzeilen des Proxys.

Alle anderen Befunde sind behoben oder als Fehlalarm beziehungsweise bewusste Entscheidung begründet (siehe „Einordnung der Befunde“).

Einordnung der Befunde

Die Tabelle beurteilt jeden Befund der ersten vollständigen Prüfung. Sie wird bei jeder späteren Messung auf den neuesten Stand gebracht.

Befund	Wo	Bewertung	Stand	Begründung
Webframework Next.js, Fassung 15.5.19	Weboberfläche	Kritisch (2 kritisch, 3 hoch, 7 mittel)	behoben (9. Oktober 2026)	Auf die bereinigte Fassung 15.5.27 derselben Hauptversion angehoben, ohne den Sprung auf eine neue Hauptversion. Die Weboberfläche ist über den vorgeschalteten Proxy erreichbar, daher hatte dieser Punkt die höchste Dringlichkeit
Express-Baustein proxy-addr 2.0.7 (Absenderadresse hinter einem vorgeschalteten Server)	Server	Kritisch (1)	behoben (9. Oktober 2026)	Der Fehler wirkt nur, wenn der Server den Adressangaben eines vorgeschalteten Servers vertraut. Tessera schaltet diese Einstellung nicht ein (im Quelltext geprüft), das tatsächliche Risiko war deshalb gering. Die bereinigte Fassung 2.0.8 ist über eine Überschreibung in der Paketverwaltung erzwungen
Mail-Vorlagenpaket handlebars 4.7.9	Server (ungenutztes Paket)	Kritisch (2 kritisch, 1 mittel)	behoben (9. Oktober 2026)	Das Paket gehörte zu einem Mail-Baustein, den kein Modul mehr benutzte. Der Baustein ist samt seiner Unterpakete aus dem Projekt entfernt; versendet wird ausschließlich über nodemailer. Mit ihm entfielen auch der zweite ungenutzte Baustein für die Anbindung von Exchange (die Anbindung läuft über eigene Abfragen mit NTLM-Anmeldung) und rund 230 mitgezogene Pakete
Mailversand nodemailer 9.1.1 (vorher 9.0.x und 8.0.11 in einem Nebenpaket)	Server	Hoch (2 hoch, 3 mittel nach der Aktualisierung; vorher 3 hoch, 5 mittel)	offen	Auf die Fassung 9.1.1 angehoben (behoben am 9. Oktober 2026); das ältere Nebenpaket 8.0.11 ist mit dem ungenutzten Mail-Baustein entfernt, und die Fassung des Postfach-Bausteins ist per Überschreibung auf 9.1.1 gehoben. Die verbleibenden Meldungen betreffen das Lesen präparierter Mailanschriften (Überlastung) und eine Eigenheit des Zwischenspeichers bei der Namensauflösung; sie werden erst in der nächsten Hauptversion 10 behoben. Ein Wechsel dorthin gehört nicht zu einer Aktualisierung innerhalb der Hauptversion und ist hier bewusst nicht vorgenommen. Mailadressen und Anschriften kommen von Administratoren und angemeldeten Benutzern; die Hauptversion 10 wird als eigener Schritt geprüft
Netzwerkbaustein undici 7.28.0 und 6.27.0	Server	Hoch (4 hoch, 13 mittel, 4 niedrig)	behoben (9. Oktober 2026)	Auf Fassung 7.30.0 angehoben und exakt festgelegt (nicht als Bereich), weil mehrere Kopien des Bausteins zu schwer zu findenden Fehlern führen; die Fassung 6.27.0 verschwand mit dem ungenutzten Mail-Baustein. Alle Kopien im Projekt sind jetzt 7.30.0
Datei-Upload multer 2.1.1	Server	Hoch (3 hoch, 1 mittel, 1 niedrig)	behoben (9. Oktober 2026)	Mit dem Server-Framework auf 11.2.7 gehoben; es bringt multer 2.4.0 mit. Hochladen können nur angemeldete Benutzer mit Modulfreigabe
ZIP-Baustein adm-zip 0.6.0	Server (Zertifikatsmanager)	Hoch (4 hoch, 3 mittel)	behoben (9. Oktober 2026)	Auf Fassung 0.6.1 angehoben, die die Meldungen mit Korrektur behebt. Tessera begrenzt das Entpacken zusätzlich mit eigenem Code
Hinweis zu adm-zip ohne Korrektur (Verknüpfungen in ZIP-Dateien)	Server (Zertifikatsmanager)	Mittel	bewusst akzeptiert	Nicht betroffen: Tessera liest ZIP-Einträge nur im Arbeitsspeicher, mit eigenen Grenzen für Größe, Verhältnis und Anzahl, und schreibt nie Einträge auf die Platte. Die angezeigte Gefahr entsteht erst beim Schreiben von Verknüpfungen
Übrige Bausteine mit bereinigter Fassung innerhalb der Version: brace-expansion, ip-address, js-yaml, postcss, nanoid, browserslist, source-map-js, qs, fast-uri, underscore, baseline-browser-mapping, csv-parse und weitere (axios, @xmldom/xmldom, liquidjs, svgo, uuid, moment, linkify-it entfielen mit den ungenutzten Bausteinen)	Server und Weboberfläche, überwiegend mittelbar eingebunden	Hoch bis Mittel	behoben (9. Oktober 2026)	Es waren überwiegend Meldungen, bei denen eine präparierte Eingabe den Dienst überlasten kann. Die tief eingebundenen Bausteine sind über Überschreibungen (pnpm.overrides im Wurzel-package.json) auf die bereinigte Fassung derselben Hauptversion gehoben; csv-parse wurde direkt angehoben. Keine Überschreibung springt über eine Hauptversion
Zwei mittelbare Bausteine ohne bereinigte Fassung in der Versionslinie: Bildbaustein sharp 0.34.5 (im Webframework) und deepmerge-ts 7.1.5 (in der Datenbank-Werkzeugkette)	Weboberfläche, Server	Hoch (3 und 1)	offen	Die Korrektur liegt bei sharp erst in 0.35 (eine neue Nebenversion der Null-Linie, die wie eine Hauptversion behandelt wird), bei deepmerge-ts in Version 8. Die Meldungen zu sharp betreffen das Dekodieren präparierter Bilddateien (libvips, libheif, librsvg); sharp gehört zur Bild-Optimierung des Webframeworks, und in der Konfiguration sind keine fremden Bildquellen freigegeben, sodass nur eigene Dateien verarbeitet werden. deepmerge-ts steckt im Werkzeug der Datenbank-Anbindung, das mit der Datenbank-Hauptversion (Prisma 6.19.3 bleibt exakt festgelegt) mitgeführt wird. Beide werden mit der jeweils nächsten Hauptversion ihres Elternpakets behoben
Tabellenbaustein xlsx 0.18.5	Server (Import Handelsware, Export DKV)	Hoch (2 hoch)	offen	Die beiden Meldungen betreffen das Verändern von Objekteigenschaften und die Überlastung durch präparierte Dateien. Auf dem öffentlichen Paketverzeichnis gibt es keine bereinigte Fassung. Der Baustein liest hochgeladene Tabellen angemeldeter Benutzer mit Modulfreigabe und schreibt DKV-Exporte. Er muss durch einen anderen Baustein ersetzt werden; bis dahin begrenzt die Modulfreigabe den Kreis möglicher Angreifer
Zertifikatsbaustein node-forge 1.4.0	Server (Zertifikatsmanager)	Hoch (1 hoch)	offen	Es ist keine bereinigte Fassung verzeichnet. Der Fehler betrifft das Prüfen von Unterschriften; im Zertifikatsmanager dient diese Prüfung dem Ordnen und Anzeigen der Kette, eine Zugriffsentscheidung hängt nicht daran. Der Baustein liest nur Dateien, die angemeldete Benutzer mit Modulfreigabe selbst hochladen; Größe, Anzahl und Rechenaufwand sind begrenzt. Er wird beobachtet und bei Erscheinen einer Korrektur aktualisiert
Entwicklungswerkzeuge im Server-Abbild (tinypool, tar, pnpm)	Abbild api	Hoch (damals 6 kritisch, 116 hoch im Abbild insgesamt)	behoben (9. Oktober 2026)	Das Abbild bringt jetzt nur noch mit, was zum Laufen nötig ist: Es gibt eine eigene Bauphase, die ausschließlich die Bausteine für den Betrieb installiert (samt dem fertig erzeugten Datenbank-Baustein), die Laufzeit-Stufe stammt direkt aus dem Node-Abbild und enthält keine Test- und Bauwerkzeuge mehr. Bewiesen durch einen Start gegen eine frische Datenbank (alle 63 Migrationen laufen durch, die API meldet sich) und durch die Rauchtests am neu gebauten Stack. Größe 1,59 auf 1,12 GB; Fundzahl des Abbilds von 3 kritisch / 45 hoch auf 0 kritisch / 6 hoch (Messung mit Trivy, Betriebssystem und Bausteine zusammen, nach den Aktualisierungen vom selben Tag)
Paketverwalter npm im Node-Grundabbild	Abbilder web und api	Hoch (damals Teil von 2 kritisch, 19 hoch)	behoben (9. Oktober 2026)	Die Paketverwaltungen des Node-Grundabbilds (npm, npx, corepack, yarn) werden in beiden Laufzeit-Stufen als Erstes entfernt, im Betrieb installiert nichts nach. Das Abbild web fiel von 11 hohen auf 3 hohe Funde (0 kritisch). Die Größe des Web-Abbilds bleibt bei 359 MB, weil Docker gelöschte Dateien aus einer früheren Schicht nicht herausrechnet; die Funde zählen trotzdem weniger, weil Trivy nur die sichtbaren Dateien betrachtet. Die Paketverwaltung des Betriebssystems (apk) bleibt bestehen
Desktop-App: Baustein rustls 0.23.41 (Verschlüsselung der Verbindung)	Desktop-App	Mittel	behoben (9. Oktober 2026)	Auf 0.23.45 derselben Versionslinie angehoben (dabei zog der Paketverwalter den Begleitbaustein rustls-webpki von 0.103.13 auf 0.103.15 mit). Übersetzen und Codeprüfung der Desktop-App laufen fehlerfrei. Die nächste Fassung der Desktop-App muss neu gebaut werden, damit die Korrektur ausgeliefert wird
Desktop-App: Baustein glib 0.18.5	Desktop-App (Linux-Oberfläche)	Mittel	offen	Die Korrektur liegt erst in Version 0.20, die zur Oberflächen-Bibliothek des Desktop-Frameworks gehört. Ein Wechsel ist nur mit deren Aktualisierung möglich
Weitere Hinweise zu Bausteinen der Desktop-App (elf Bausteine: anyhow, event-listener, h2, zwei Fassungen von quick-xml, proc-macro-error und fünf nicht mehr gepflegte unic-Bausteine)	Desktop-App, mittelbar über das Desktop-Framework	Nicht einzeln bewertet (überwiegend „nicht mehr gepflegt“ oder Fehler in Sonderfällen)	offen	Die Meldungen betreffen nicht mehr gepflegte Bausteine und seltene Fehlerfälle in Bibliotheken, die das Desktop-Framework mitbringt (zum Beispiel Überlastung durch präparierte Netzwerkpakete oder XML-Dateien). Ob und auf welchem Weg die Desktop-App diese Fälle erreicht, wurde nicht im Einzelnen untersucht. Für anyhow, event-listener und h2 liegen Korrekturen als Patch-Fassungen derselben Versionslinie vor; das Anheben steht noch aus und wird mit der nächsten Aktualisierung der Desktop-Paketliste nachgeholt. Die übrigen hängen am Desktop-Framework und lassen sich nur mit dessen Aktualisierung beheben
Testwerkzeuge vitest 3.2.6, @vitest/mocker 3.2.6 und tinypool 1.1.1 (nur beim Entwickeln)	Server, nur Entwicklungsumgebung	Kritisch (2) und mittel (2) laut Werkzeug	offen	Diese Bausteine laufen nur bei den automatischen Tests des Servers und sind seit dem 9. Oktober 2026 nicht mehr im Server-Abbild enthalten (im Abbild nachgemessen). Die Korrektur liegt in einer neuen Hauptversion der Testwerkzeuge (vitest 4); der Wechsel gehört nicht zu dieser Aktualisierung innerhalb der Versionslinien und wird als eigener Schritt geprüft
Länge der Echtheitsprüfung bei AES-GCM (Entschlüsselung gespeicherter Geheimnisse)	Server, crypto.service.ts	Niedrig	behoben (9. Oktober 2026)	Die Entschlüsselung verlangt jetzt genau die volle Länge des Echtheits-Codes (16 Byte) und weist alles andere ab; die Länge wird zusätzlich an die Verschlüsselungsfunktion übergeben. Alle bisher gespeicherten Werte nutzen die volle Länge und bleiben lesbar. Tests: ein auf 4 Byte gekürzter Code, ein zu langer und ein leerer Code sowie ein Code mit einem veränderten Bit werden abgewiesen (vor der Änderung wurde der gekürzte Code noch akzeptiert), der normale Hin- und Rückweg inklusive leerem Text und Umlauten funktioniert weiter. Im Abschlusslauf meldet Semgrep diese Stelle nicht mehr
Vier abschaltbare Zertifikatsprüfungen (Verzeichnisdienst, Proxmox-Anmeldung, Proxmox-Abfragen, Symbolsuche)	Server	Mittel laut Werkzeug	bewusst akzeptiert	Die Prüfung entfällt nur, wenn ein Administrator das für genau eine Verbindung ausdrücklich erlaubt, etwa bei internen Servern mit selbst ausgestellten Zertifikaten. Standard ist die volle Prüfung. Die Entscheidung ist in Kommentaren des Quelltexts mit Verweis auf den Beschluss festgehalten
Testschlüssel und Testwerte in Testdaten, Testdateien und Planungsnotizen	Zertifikatsmanager (Testdaten), drei Testdateien, eine Planungsnotiz, eine Testkomponente	Fehlalarm	bewusst akzeptiert	Die Schlüssel sind eigens zum Prüfen der Software erzeugt und schützen nichts. Der Ordner mit den Testdaten und die einzelnen Dateien stehen in den Ausnahmelisten (gitleaks, Trivy, Semgrep)
Beschriftung „Benutzer/Passwort“, Tabellenzeile einer Prüfliste und Beispielaufruf an einen lokalen Wegwerf-Testserver	Sprachdatei, Planungsnotizen	Fehlalarm	bewusst akzeptiert	Keines der drei enthält ein echtes Geheimnis: ein Beschriftungstext, eine Beispielzeile und der Testzugang eines wegwerfbaren lokalen Testservers. Alle drei sind einzeln in den Ausnahmelisten eingetragen
Hinweise zu Umleitung nach der Anmeldung, zusammengesetzten Suchmustern und Durchlaufen von Objekten	Weboberfläche, Server	Fehlalarm	bewusst akzeptiert	Die Umleitung nach der Anmeldung läuft durch eine Prüffunktion, die nur Pfade der eigenen Seite zulässt. Die Suchmuster werden aus festen Konstanten gebaut, nicht aus Benutzereingaben. Das Durchlaufen der Objekte liest nur
Verhalten des Prüfschritts im ersten echten Pipeline-Lauf (Code-Prüfung des Sicherheitsauftrags, 9. Oktober 2026)	Pipeline	Niedrig	behoben (09.10.2026)	Im ersten echten Lauf (Lauf 519) blieb der Schritt grün, alle Zusammenfassungszeilen standen im Protokoll, die Berichte wurden als Artefakt „sicherheitsberichte“ abgelegt, und die Prüfung brauchte 63 Sekunden von 1500 erlaubten. Der Runner wird also nur kurz belegt. Der einzige Fund (eine zitierte Oberflächenbeschriftung in einer Planungsnotiz) war ein Fehlalarm und steht jetzt auf der Ausnahmeliste
Pipeline-Datei: Bausteine der Pipeline mit beweglichen Versionsnamen (14 Stellen seit dem neuen Prüfschritt) und ein Installationsaufruf per Herunterladen-und-Ausführen	Pipeline	Niedrig	offen	Die Pipeline läuft auf eigenen Servern ohne fremde Zugriffe. Bewegliche Versionsnamen könnten sich aber unbemerkt ändern; sie sollen fest eingetragen werden
Einstellungen zum Absichern der Paketverwaltung (drei Werte)	Arbeitsbereich-Datei	Niedrig	offen	Diese Einstellungen stärken die Lieferkette. Ob sie in der eingesetzten Fassung 9.15 des Paketverwalters wirken, ist noch nicht geprüft
Fehlende Gesundheitsprüfung im Bauplan des Server-Abbilds	Abbild api	Niedrig	bewusst akzeptiert	Die Gesundheitsprüfung liegt in der Compose-Datei, die den Server startet und seine Erreichbarkeit überwacht
Fehlende Gesundheitsprüfung im Bauplan des Web-Abbilds	Abbild web	Niedrig	offen	Weder Bauplan noch Compose-Datei prüfen die Weboberfläche; ein hängender Web-Container würde nicht automatisch erkannt
Fehlender Schutz gegen Einrahmen (Clickjacking; Außenprüfung 9. Oktober 2026)	Weboberfläche, alle Seiten	Mittel	behoben in der Anwendung, beim öffentlichen Lauf erneut prüfen	Die Anwendung schickt jetzt selbst die Kopfzeilen mit, die das Einrahmen durch fremde Seiten verbieten (X-Frame-Options „SAMEORIGIN“ und die Richtlinie „frame-ancestors“ der Inhaltsrichtlinie); Einrahmen durch Tessera-Seiten selbst bleibt möglich. Eingebettete fremde Seiten (XFrame-Kachel, eigene Module) sind nicht betroffen, die Kopfzeilen schützen nur Tessera. Die Desktop-App lädt die Seite direkt und nicht in einem Rahmen. Ob zusätzlich der Proxy dieselben Kopfzeilen setzt, zeigt der Lauf über die öffentliche Adresse
Vollständige Inhaltsrichtlinie (Content Security Policy)	Weboberfläche, alle Seiten	Mittel	offen	Bisher gibt es nur die eine Teilrichtlinie gegen das Einrahmen. Eine vollständige Richtlinie, die festlegt, von wo Skripte und Bilder geladen werden dürfen, braucht eine eigene Prüfung der Inline-Skripte des Webframeworks und der eingebetteten Kacheln, sonst bricht sie Seiten. Das tatsächliche Risiko ist gering bis mittel: Es bräuchte bereits eingeschleusten Code. Wird als eigener Auftrag behandelt
Weitere fehlende Schutz-Kopfzeilen (Dateityp-Umdeutung, Berechtigungsrichtlinie, Trennung der Fenster untereinander)	Weboberfläche	Niedrig	behoben in der Anwendung, beim öffentlichen Lauf erneut prüfen	Die Anwendung sendet jetzt die Kopfzeile gegen das Umdeuten von Dateitypen (nosniff), eine Berechtigungsrichtlinie, die Kamera, Mikrofon, Standort, Zahlung und USB sperrt (die Zwischenablage für „Link kopieren“, Vollbild und Benachrichtigungen bleiben erlaubt), die Regel für die Weitergabe der Herkunftsadresse (Referrer-Policy) und die Fensterrichtlinie „same-origin-allow-popups“ (das Anmelde-Fenster zu Nextcloud und andere neue Fenster funktionieren weiter, weil sie ohne Verbindung zum Ursprungsfenster geöffnet werden). Die beiden übrigen Cross-Origin-Richtlinien (Embedder und Resource) bleiben bewusst weg: Sie könnten eingebettete Bilder und Kacheln sperren, ohne hier etwas zu schützen
Kopfzeile „X-Powered-By“ nennt das Webframework	Weboberfläche und Server	Niedrig	behoben in der Anwendung, beim öffentlichen Lauf erneut prüfen	Sie ist in der Weboberfläche abgeschaltet; auch der Server (Express) sendet sie nicht mehr. Sie verriet nur den Namen des Frameworks, den Angreifer ohnehin leicht erraten
Verschlüsselte Verbindung (HTTPS) und deren Absicherung der öffentlichen Adresse	Proxy vor alpha	nicht beurteilt	offen	Der erste Lauf ging über eine unverschlüsselte, interne Verbindung direkt zur Anwendung und konnte das nicht sehen. Aufgabe des Proxys, beim öffentlichen Lauf erneut prüfen
Drei Informationen der Außenprüfung (Dateityp bei Umleitungen, Zwischenspeicherung)	Weboberfläche	Information	bewusst akzeptiert	Es sind Beschreibungen, keine Schwächen: Anmeldeseiten sind nicht speicherbar, die öffentlichen Programmdateien sind es. Daran ist nichts zu ändern

Prüfung von außen gegen alpha

Jede Zeile ist ein Lauf der passiven Außenprüfung (OWASP ZAP 2.17.0). Gezählt werden Meldungsarten, nicht einzelne Fundstellen; dieselbe Meldung auf mehreren Seiten zählt einmal.

Datum	Version	Weg	Hoch	Mittel	Niedrig	Info
9. Oktober 2026	v1.10.1-80-gd15a470 (Beta)	direkt gegen die Anwendung, ohne Proxy	0	2	6	3

Zum ersten Lauf. Die öffentliche Adresse von alpha war an diesem Tag vom Prüfrechner aus nicht erreichbar (die Verbindung lief in eine Zeitüberschreitung). Der erste Lauf ging deshalb direkt gegen die Anwendung auf alpha, über die interne Adresse des Testservers und ohne den vorgeschalteten Proxy. Das ist ein Lauf mit denselben Regeln (passiv, keine Formulare, keine Angriffe), aber er sieht nur, was die Anwendung selbst ausliefert. Alles, was der Proxy beisteuert, etwa die verschlüsselte Verbindung (HTTPS) und deren Absicherung, konnte dieser Lauf nicht beurteilen. Der Lauf über die öffentliche Adresse folgt, sobald diese vom Prüfrechner erreichbar ist. Gefunden wurden 28 Seiten und Dateien; es gab keine Anmeldung und keine Datenänderung.

Was die einzelnen Meldungen bedeuten:

• Fehlende Inhaltsrichtlinie (Content Security Policy), mittel. Mit dieser Kopfzeile sagt eine Webseite dem Browser, von wo sie Skripte und andere Inhalte laden darf. Sie bremst Angriffe, bei denen fremder Code in eine Seite eingeschleust wird. Ohne sie gilt keine solche Einschränkung. Es ist eine fehlende Vorsorge, keine ausgenutzte Lücke.
• Fehlender Schutz gegen Einrahmen (Clickjacking), mittel. Ohne passende Kopfzeile könnte eine fremde Seite die Anmeldeseite unsichtbar in einen Rahmen legen und Besucher zu Klicks verleiten. Zu sehen war das auf der Anmeldeseite und der Seite zum Zurücksetzen des Passworts.
• Fehlende Kopfzeile gegen das Umdeuten von Dateitypen, niedrig. Sie hindert Browser daran, eine Datei als etwas anderes zu behandeln, als der Server sagt.
• Fehlende Berechtigungsrichtlinie, niedrig. Damit lässt sich festlegen, auf welche Geräte-Funktionen (zum Beispiel Kamera oder Standort) eine Seite zugreifen darf.
• Drei fehlende Kopfzeilen zur Trennung von Seiten untereinander (Cross-Origin-Embedder-, -Opener- und -Resource-Policy), niedrig. Sie sollen verhindern, dass fremde Seiten Inhalte der Anwendung einbinden oder beobachten. Für eine Anwendung ohne eingebettete Fremdinhalte ist der Nutzen klein.
• Kopfzeile „X-Powered-By“, niedrig. Der Server nennt das Webframework, mit dem er gebaut ist. Das hilft einem Angreifer nur beim Raten, welche Schwachstellen er probieren könnte.
• Drei Informationen. „Content-Type fehlt“ trifft Umleitungen und leere Antworten ohne Inhalt. „Nicht speicherbar“ und „speicherbar und zwischenspeicherbar“ beschreiben nur, ob Browser und Zwischenspeicher eine Antwort behalten dürfen: Anmeldeseiten sind zu Recht nicht speicherbar, die öffentlichen Programmdateien sind es.

Die Beurteilung jeder Meldung steht in der Tabelle „Einordnung der Befunde“.

Verlauf

2026-10-09 — Erster echter Lauf der automatischen Prüfung

Nach dem Hochladen lief die automatische Prüfung zum ersten Mal auf dem echten Server (Lauf 519). Sie blieb grün, hielt den Bau nicht auf und brauchte 63 Sekunden. Ergebnis: keine Zugangsdaten außer einem Fehlalarm, 0 kritische und 9 hohe Lücken in den Bausteinen des laufenden Betriebs, im Server-Abbild 0 kritische und 6 hohe, im Web-Abbild 0 kritische und 3 hohe – dieselben Zahlen wie im Abschlusslauf auf dem Entwicklungsrechner. Der Fehlalarm war eine Planungsnotiz, die die harmlose Oberflächenbeschriftung „Benutzer/Passwort“ zitiert; sie steht jetzt auf der geprüften Ausnahmeliste, und die Durchsicht der ganzen Geschichte meldet wieder nichts.

Der neueste Eintrag steht oben.

2026-10-09 — Codeprüfung des Sicherheitsauftrags

Die Änderungen des Sicherheitsauftrags selbst (Prüfskripte der Pipeline, Außenprüfung, Abbilder, Kopfzeilen, Entschlüsselung, Bausteine) wurden von einer zweiten Stelle durchgesehen. Ergebnis: keine kritischen Befunde, 5 Warnungen und 4 Hinweise; nichts davon hielt eine Veröffentlichung auf. Behoben wurden am selben Tag: (1) Das Server-Abbild erzeugt den Prisma-Baustein jetzt in einem eigenen Schritt, dessen Fehler den Bau abbricht; vorher konnte der Baustein still fehlen und das Abbild erst beim Start sterben. Eine absichtlich kaputte Beschreibung bewies, dass der Bau jetzt scheitert. Die Startprobe gegen eine frische Datenbank liegt nun versioniert im Projekt und steht in der Freigabe-Checkliste. (2) Semgrep kommt aus dem offiziellen Container mit fester Kennung statt aus dem Paketindex mit frei aufgelösten Zusatzpaketen. (3) Die Zeitgrenzen der Werkzeuge ergeben zusammen höchstens 25 Minuten (vorher rund 140), ein Gesamtbudget kürzt sie, und jedes Werkzeug meldet sein Ergebnis sofort. (4) Die Anmeldekopfzeile der Außenprüfung geht nur noch an das Ziel; die Gegenprobe über einen Zwischenserver zeigte: Ziel bekam sie, ein zweiter Rechner und derselbe Rechner an einem anderen Anschluss nicht. (5) Hinweise: Die Programme zur Paketverwaltung werden mit Platzhaltern entfernt und der Bau scheitert, falls eines bleibt; der Berichtsordner der Außenprüfung ist nur noch für den ZAP-Benutzer zugänglich statt für alle; Passwörter mit Anführungszeichen oder Rückstrich werden sicher behandelt; ein flacher Klon wird bei den Zugangsdaten als „unvollständig“ gemeldet; und ein Kommentar zur Doppelung der Kopfzeilen mit dem Proxy wurde richtiggestellt. Offen: das Verhalten des Prüfschritts im ersten echten Pipeline-Lauf (siehe „Einordnung der Befunde“).

2026-10-09 — Stand nach der Behebung

Abschlusslauf der automatischen Prüfung auf dem bereinigten Stand, im Container-Abbild der Pipeline, mit frisch gebauten Abbildern: Keine Zugangsdaten in der gesamten Geschichte, keine kritische Meldung mehr bei den Bausteinen im Betrieb (151 auf 12 Meldungen), das Server-Abbild von 6 kritischen und 116 hohen Funden auf 0 und 6, das Web-Abbild von 2 und 19 auf 0 und 3. Die Längenprüfung des Echtheits-Codes wird von Semgrep nicht mehr gemeldet. Die Zahlen vorher und nachher stehen im Abschnitt „Stand nach der Behebung“, die Beurteilung jedes Befunds in „Einordnung der Befunde“ (jede Zeile hat Stand und Begründung). Offen: xlsx, node-forge, nodemailer, sharp, deepmerge-ts, einige Hinweise zu Bausteinen der Desktop-App, die Gesundheitsprüfung der Weboberfläche, die vollständige Inhaltsrichtlinie und der Lauf über die öffentliche Adresse.

2026-10-09 — Schutz-Kopfzeilen in der Anwendung

Als Antwort auf den ersten Außenlauf sendet die Weboberfläche jetzt selbst Schutz-Kopfzeilen, damit sie nicht allein vom Proxy abhängen: Schutz gegen das Einrahmen durch fremde Seiten, gegen das Umdeuten von Dateitypen, eine Regel für die Weitergabe der Herkunftsadresse, eine Berechtigungsrichtlinie (Kamera, Mikrofon, Standort, Zahlung und USB gesperrt; die Zwischenablage bleibt erlaubt) und die Fensterrichtlinie „same-origin-allow-popups“. Die Kopfzeile „X-Powered-By“ ist in Weboberfläche und Server abgeschaltet. Vor der Umsetzung wurde geprüft, dass nichts davon eine Funktion bremst: neue Fenster (auch die Nextcloud-Anmeldung) werden ohne Verbindung zum Ursprungsfenster geöffnet, es gibt keinen Austausch zwischen Fenstern, die Desktop-App lädt die Seite direkt, und eingebettete fremde Seiten sind von diesen Kopfzeilen nicht betroffen. Eine vollständige Inhaltsrichtlinie wurde bewusst nicht gesetzt (siehe Tabelle „Einordnung der Befunde“, Zeile „offen“). Ob der Proxy dieselben Kopfzeilen ebenfalls setzt, zeigt der nächste Lauf über die öffentliche Adresse; bis dahin steht der Stand dieser Zeilen auf „behoben in der Anwendung, beim öffentlichen Lauf erneut prüfen“.

2026-10-09 — Eigene Härtung: Echtheits-Code und schlankere Abbilder

Zwei Maßnahmen aus der ersten Prüfung wurden umgesetzt. Erstens verlangt die Entschlüsselung gespeicherter Geheimnisse jetzt die volle Länge des Echtheits-Codes; ein gekürzter Code wird abgewiesen, vorher wurde er noch angenommen (der neue Test war vor der Änderung rot). Zweitens enthalten die fertigen Abbilder keine Entwicklungswerkzeuge und keine Paketverwaltung mehr: Das Server-Abbild wird aus einer eigenen Bauphase mit ausschließlich den Betriebsbausteinen zusammengesetzt, und beide Laufzeit-Abbilder entfernen npm, npx, corepack und yarn des Node-Grundabbilds.

Messung (Trivy, Betriebssystem und Bausteine, nach den Aktualisierungen vom selben Tag): Server-Abbild vorher 3 kritisch, 45 hoch, 41 mittel, 2 niedrig bei 1,59 GB, nachher 0 kritisch, 6 hoch, 4 mittel, 0 niedrig bei 1,12 GB. Web-Abbild vorher 0 kritisch, 11 hoch, 13 mittel, 1 niedrig, nachher 0 kritisch, 3 hoch, 1 mittel, 0 niedrig bei unveränderten 359 MB. Beweis, dass nichts kaputtgegangen ist: Ein Start des Server-Abbilds gegen eine frische, leere Datenbank wendet alle 63 Migrationen an und bringt die API zum Laufen; dazu liefen die Rauchtests am neu gebauten Stack (Zertifikatsmanager, Änderungsliste, Dateien und Übertragungen, Mailversand) fehlerfrei.

2026-10-09 — Bausteine von Fremdherstellern aktualisiert

Alle Bausteine mit bereinigter Fassung innerhalb ihrer bisherigen Versionslinie wurden angehoben: das Webframework Next.js (15.5.19 auf 15.5.27), das Server-Framework (11.2.7, damit multer 2.4.0), der Mailversand (nodemailer 9.1.1), das Netzwerk-Paket undici (7.30.0), adm-zip (0.6.1) und csv-parse (7.0.3). Dazu kommen 15 Überschreibungen für tief eingebundene Bausteine (pnpm.overrides, jeweils innerhalb derselben Hauptversion) und die Entfernung der beiden ungenutzten Pakete für Mailvorlagen und die frühere Exchange-Anbindung. In der Desktop-App wurde rustls auf 0.23.45 gehoben. Prisma blieb exakt auf 6.19.3, Next.js auf der Linie 15, NestJS auf 11.

Messung pnpm audit --prod (Bausteine im Betrieb): vorher 151 Schwachstellen (5 kritisch, 73 hoch, 68 mittel, 5 niedrig), nachher 12 (0 kritisch, 9 hoch, 3 mittel, 0 niedrig). Messung pnpm audit (alle Bausteine einschließlich Entwicklungswerkzeuge): vorher 171 (7 kritisch, 85 hoch, 74 mittel, 5 niedrig), nachher 16 (2 kritisch, 9 hoch, 5 mittel, 0 niedrig); die 2 kritischen und 2 der mittleren gehören zu den Testwerkzeugen (tinypool und vitest 3), die nur im Entwicklungsbetrieb laufen und deren Korrektur in einer neuen Hauptversion liegt. Das Lockfile gewann keinen einzigen neuen Paketnamen; 232 Namen entfielen. Alle Testläufe, Typprüfung, Codeprüfung, der neu gebaute lokale Stack und die Rauchtests (einschließlich eines Mailversands an das lokale Postfach) liefen fehlerfrei.

Offen: xlsx und node-forge (keine bereinigte Fassung), nodemailer, sharp und deepmerge-ts (Korrektur erst in einer neuen Hauptversion) sowie glib in der Desktop-App. Der Stand jeder Zeile steht in „Einordnung der Befunde“.

2026-10-09 — Erste Prüfung von außen gegen alpha (OWASP ZAP)

Passiver Erstlauf gegen alpha in der Fassung v1.10.1-80-gd15a470 (Beta), direkt gegen die Anwendung und ohne den vorgeschalteten Proxy, weil die öffentliche Adresse vom Prüfrechner nicht erreichbar war. Ergebnis: 0 hoch, 2 mittel, 6 niedrig, 3 Informationen; alle Meldungen betreffen fehlende Schutz-Kopfzeilen der Weboberfläche oder beschreiben Zwischenspeicherung. Vor dem Lauf bewies ein Probelauf gegen eine Testseite, dass das Skript keine Formulare absendet. Beurteilung: siehe „Prüfung von außen gegen alpha“ und „Einordnung der Befunde“. Offen: der Lauf über die öffentliche Adresse; dort werden auch die Kopfzeilen und die Verschlüsselung des Proxys sichtbar.

2026-10-09 — Erste vollständige Prüfung und automatische Prüfung eingerichtet

Zum ersten Mal wurde das gesamte Projekt mit allen fünf Werkzeugen geprüft: Zugangsdaten in der Geschichte, Bausteine anderer Hersteller, eigener Quelltext und die beiden fertigen Abbilder. Ergebnis: keine echten Geheimnisse, 151 bekannte Schwachstellen in Bausteinen im Betrieb (5 kritisch, 73 hoch), ein echter Härtungspunkt im eigenen Quelltext und ein Server-Abbild, das Entwicklungswerkzeuge enthält. Die Einzelheiten stehen in den Abschnitten „Erste vollständige Prüfung“ und „Einordnung der Befunde“. Gleichzeitig wurde die automatische Sicherheitsprüfung nach jedem Bau eingerichtet und mit einer Gegenprobe (erfundener Köder-Code) im echten Bau-Umfeld geprüft; sie meldet nur und hält nie etwas an. Danach wurde die Liste der Ausnahmen für geprüfte Fehlalarme angelegt.

2026-10-09 — Code-Prüfung Zertifikatsmanager und Härtung des Adressschutzes

15 Befunde, davon 3 kritische (ZIP-Bombe mit gefälschter Größenangabe, blockierendes Suchmuster bei Zertifikatsblöcken, Umlaute in PFX-Passwörtern), alle behoben und mit Tests abgesichert. Der gemeinsame Adressschutz wurde um versteckte IPv6-Schreibweisen interner Adressen erweitert (siehe „Härtung des gemeinsamen Adressschutzes“).

2026-10-09 — Code-Prüfung Modul Dateien, Teilen (Nextcloud-Freigaben)

11 Befunde, davon 1 kritischer (Pfade und Kennungen wurden verändert), alle behoben. Das Teilen nutzt zusätzlich einen Zähler gegen zu viele Versuche.

2026-10-08 — Code-Prüfung Modul Dateien (Nextcloud)

18 Befunde, davon 2 kritische (umgehbare Begrenzung der Passwortversuche, umlenkbare Nextcloud-Adresse), alle behoben.

2026-10-08 — Code-Prüfung Modul Domains und AutoDNS

11 Befunde, davon 1 kritischer (Gefahr der Doppelbestellung bei Serverfehlern). 8 behoben, 3 Hinweise offen.

Ältere Prüfungen (Juni bis September 2026) stehen in der Tabelle „Bisherige Sicherheitsprüfungen“.