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: 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.
• 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 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.

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

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

Verlauf

Der neueste Eintrag steht oben.

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