# 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](anleitung-entwicklung.md#sicherheitsprüfungen).

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:** In den Bausteinen anderer Hersteller, die Tessera im Betrieb verwendet, sind 151 bekannte Schwachstellen verzeichnet, davon 5 kritische und 73 hohe. Für die allermeisten gibt es eine bereinigte Fassung innerhalb der aktuell verwendeten Versionslinie. Für zwei Bausteine (xlsx und node-forge) gibt es noch keine bereinigte Fassung; sie sind unter „Einordnung der Befunde“ eingeordnet.
- **Eigener Quelltext:** Ein einziger echter Härtungspunkt wurde gefunden (die Längenprüfung bei der Entschlüsselung gespeicherter Geheimnisse, Schweregrad niedrig). 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.
- **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. Der Lauf über die öffentliche Adresse steht noch aus.
- **Bisherige Prüfungen:** Acht Code-Prüfungen größerer Änderungen mit zusammen 89 Befunden; 76 davon sind behoben, die übrigen 13 sind Hinweise der niedrigsten Stufe. Alle kritischen Befunde und alle Warnungen sind behoben.
- **Was noch zu tun ist:** Die Bausteine mit bereinigter Fassung werden aktualisiert, und die fertigen Abbilder sollen keine Entwicklungswerkzeuge mehr enthalten. Der Stand jedes einzelnen Punkts steht in der Tabelle „Einordnung der Befunde“.

## 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. Die technischen Einzelheiten stehen im [Pipeline-Handbuch](ci-cd-setup.md) und in der [Entwicklungsanleitung](anleitung-entwicklung.md#sicherheitsprüfungen).

### 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.

### 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](anleitung-betrieb.md#9-zwei-kanäle-live-und-beta); die technischen Einzelheiten stehen in der [Entwicklungsanleitung](anleitung-entwicklung.md#sicherheitsprüfungen).

### 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

Acht 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 |

**Summe:** 8 Prüfungen, 89 Befunde (13 kritisch, 43 Warnungen, 33 Hinweise). Behoben sind 76, darunter alle kritischen Befunde und alle Warnungen und 20 von 33 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.

## 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) | offen | Eine bereinigte Fassung derselben Hauptversion (15.5.27) liegt vor. Die Weboberfläche ist über den vorgeschalteten Proxy erreichbar, daher hat dieser Punkt die höchste Dringlichkeit. Er wird innerhalb der Hauptversion 15 behoben, ohne den Sprung auf eine neue Hauptversion |
| Express-Baustein proxy-addr 2.0.7 (Absenderadresse hinter einem vorgeschalteten Server) | Server | Kritisch (1) | offen | 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 ist deshalb gering. Eine bereinigte Fassung (2.0.8) lässt sich erzwingen |
| Mail-Vorlagenpaket handlebars 4.7.9 | Server (ungenutztes Paket) | Kritisch (2 kritisch, 1 mittel) | offen | Das Paket gehört zu einem Mail-Baustein, den kein Modul mehr benutzt. Ein Angriff bräuchte eine eingeschleuste Vorlage; Vorlagen pflegt nur ein Administrator. Der ungenutzte Baustein soll entfernt werden |
| Mailversand nodemailer 9.0.x (und 8.0.11 in einem Nebenpaket) | Server | Hoch (3 hoch, 5 mittel) | offen | Fassung 9.1.x behebt die Meldungen. Mailadressen kommen von Administratoren und Benutzern, daher wird der Baustein aktualisiert |
| Netzwerkbaustein undici 7.28.0 und 6.27.0 | Server | Hoch (4 hoch, 13 mittel, 4 niedrig) | offen | Fassung 7.29.1 oder neuer derselben Hauptversion behebt die Meldungen. Die abgerufenen Adressen laufen zusätzlich durch den Adressschutz; das Anheben ist trotzdem sinnvoll |
| Datei-Upload multer 2.1.1 | Server | Hoch (3 hoch, 1 mittel, 1 niedrig) | offen | Fassung 2.4.0 gehört zum nächsten Nebenstand des Server-Frameworks. Hochladen können nur angemeldete Benutzer mit Modulfreigabe |
| ZIP-Baustein adm-zip 0.6.0 | Server (Zertifikatsmanager) | Hoch (4 hoch, 3 mittel) | offen | Fassung 0.6.1 behebt die Meldungen mit Korrektur. 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: axios, @xmldom/xmldom, brace-expansion, ip-address, js-yaml, liquidjs, postcss, sharp, svgo, nanoid, browserslist, source-map-js, qs, uuid, moment, csv-parse, deepmerge-ts, linkify-it, underscore und weitere | Server und Weboberfläche, überwiegend mittelbar eingebunden | Hoch bis Mittel | offen | Es sind überwiegend Meldungen, bei denen eine präparierte Eingabe den Dienst überlasten kann. Für alle gibt es eine Korrektur in derselben Hauptversion; ein Teil davon steckt in ungenutzten Paketen, die entfernt werden |
| 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 (6 kritisch, 116 hoch im Abbild insgesamt) | offen | Das Abbild enthält Werkzeuge zum Testen und Bauen, die im Betrieb nichts tun, aber Schwachstellen mitbringen. Das fertige Abbild soll nur noch enthalten, was zum Laufen nötig ist |
| Paketverwalter npm im Node-Grundabbild | Abbild `web` | Hoch (Teil von 2 kritisch, 19 hoch) | offen | Das Grundabbild bringt einen Paketverwalter mit eigenen Bausteinen mit, der im Betrieb nicht gebraucht wird. Er soll aus dem fertigen Abbild entfernt werden |
| Desktop-App: Baustein rustls 0.23.41 (Verschlüsselung der Verbindung) | Desktop-App | Mittel | offen | Eine bereinigte Fassung (0.23.45) liegt in derselben Versionslinie vor und lässt sich ohne Umbau einspielen |
| 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 |
| Länge der Echtheitsprüfung bei AES-GCM (Entschlüsselung gespeicherter Geheimnisse) | Server, `crypto.service.ts` | Niedrig | offen | Beim Entschlüsseln wird die Länge des Echtheits-Codes nicht erzwungen. Ein Angreifer bräuchte dafür schreibenden Zugriff auf die Datenbank. Alle bisher gespeicherten Werte nutzen die volle Länge, die Härtung ist ohne Datenverlust möglich |
| 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 |
| Pipeline-Datei: Bausteine der Pipeline mit beweglichen Versionsnamen (12 Stellen) 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 |
| Fehlende Inhaltsrichtlinie und fehlender Schutz gegen Einrahmen (Außenprüfung 9. Oktober 2026) | Weboberfläche, alle Seiten | Mittel | offen | Die Anwendung selbst schickt diese Kopfzeilen bisher nicht mit. Ein vorgeschalteter Proxy kann sie ergänzen; ob er das tut, kann nur der Lauf über die öffentliche Adresse zeigen. Aufgabe des Proxys, beim öffentlichen Lauf erneut prüfen. Fehlen sie dort auch, werden sie in der Anwendung gesetzt. Das tatsächliche Risiko ist gering bis mittel: Es braucht eine fremde Seite, die Benutzer zu Klicks verleitet, oder bereits eingeschleusten Code |
| Weitere fehlende Schutz-Kopfzeilen (Dateityp-Umdeutung, Berechtigungsrichtlinie, drei Cross-Origin-Richtlinien) | Weboberfläche | Niedrig | offen | Reine Vorsorge ohne unmittelbare Gefahr. Teilweise Aufgabe des Proxys (beim öffentlichen Lauf erneut prüfen), sonst kommen sie in die Konfiguration der Weboberfläche |
| Kopfzeile „X-Powered-By“ nennt das Webframework | Weboberfläche | Niedrig | offen | Das Webframework schickt diese Angabe standardmäßig mit. Sie verrät nur den Namen des Frameworks, den Angreifer ohnehin leicht erraten. Wird bei der Härtung der Kopfzeilen mit abgeschaltet |
| 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

Der neueste Eintrag steht oben.

### 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“.