Es gibt diese Momente, in denen man als Administrator morgens die erste Tasse Kaffee in der Hand hält, die Monitoring-Alarme noch schweigen, und man denkt: „Heute wird ein ruhiger Tag.“ Dann trifft einen die Nachricht von einer kritischen Schwachstelle in der eigenen Nextcloud-Instanz – und der Kaffee wird kalt. Nextcloud hat sich in den letzten Jahren zu einer festen Größe im Bereich der datenschutzkonformen Cloud-Lösungen entwickelt, doch mit zunehmender Verbreitung steigt auch die Aufmerksamkeit von Angreifern. Eine systematische Schwachstellenanalyse ist daher kein optionales Extra, sondern eine Notwendigkeit. Dabei zeigt sich immer wieder: Die Sicherheit einer Nextcloud-Umgebung hängt nicht allein von den Entwicklern ab, sondern maßgeblich von der Betriebsdisziplin der Administratoren.
Wer Nextcloud betreibt, der verwaltet im Grunde eine kleine digitale Infrastruktur. Dateien, Kontakte, Kalender, Office-Dokumente – all das wandert durch die eigenen Server. Die Plattform ist modular aufgebaut, mit unzähligen Apps, die von der Community oder Drittanbietern kommen. Und genau diese Modularität birgt ein Risiko. Jede Erweiterung öffnet potenzielle Angriffsflächen. Eine Schwachstellenanalyse bei Nextcloud ist also nie nur die Betrachtung der Kern-Software, sondern muss das gesamte Ökosystem erfassen. Das klingt trivial, wird aber in der Praxis oft unterschätzt. Ein typisches Szenario: Ein Admin installiert die neueste Version von Nextcloud und denkt, die Sicherheitsupdates seien damit abgedeckt. Zwei Wochen später erscheint ein Advisory für eine Drittanbieter-App, die er vergessen hat zu aktualisieren – und plötzlich ist das ganze System kompromittiert.
Ein interessanter Aspekt ist die Art und Weise, wie Schwachstellen in Nextcloud überhaupt zustande kommen. Die Entwickler haben in den letzten Jahren große Fortschritte gemacht, insbesondere was die Härtung des Kerns betrifft. So wurde etwa die Session-Verwaltung überarbeitet, um eine Session-Fixation zu verhindern. Auch die Verwendung von HTTP-Only-Cookies ist mittlerweile Standard. Dennoch finden Sicherheitsforscher immer wieder Lücken, die oft auf die komplexe Interaktion zwischen verschiedenen Komponenten zurückgehen. Nehmen wir den Fall einer Schwachstelle im „Password Policy“-App, die es erlaubte, durch manipulierte Anfragen an die API eine bestehende Passwortrichtlinie zu umgehen. Das ist kein Fehler im Kern, aber in der Praxis genauso gefährlich. Solche Lücken werden meist durch Penetrationstests aufgedeckt, die nicht nur die Software, sondern auch die Konfiguration prüfen. Denn eine falsch gesetzte .htaccess-Datei oder eine offene Port-Freigabe im Docker-Netzwerk können die gesamte Sicherheitsarchitektur untergraben.
Der jüngste CVE-Eintrag, der die Nextcloud-Community aufschrecken ließ, war eine Cross-Site-Scripting (XSS)-Lücke in der Preview-Funktion für SVG-Dateien. Sie erlaubte es, schädlichen Code in den Browser eines Nutzers einzuschleusen, der ein manipuliertes Vorschaubild aufrief. Klingt harmlos, war es aber nicht. Angreifer hätten darüber Session-Cookies abgreifen oder den Nutzer auf Phishing-Seiten umleiten können. Und das Spannende daran: Die Schwachstelle war über ein Jahr lang in der Wildnis, bevor sie gemeldet und geschlossen wurde. Das zeigt ein grundsätzliches Problem: Die Meldekultur in der Open-Source-Welt ist oft auf Freiwilligkeit angewiesen, und viele Lücken werden erst entdeckt, wenn sie entweder gezielt gesucht oder durch Exploits sichtbar werden. Nextcloud betreibt zwar ein Bug-Bounty-Programm, aber die Prämien sind nicht immer ausreichend, um hochqualifizierte Sicherheitsforscher anzulocken.
Für Admins bedeutet das: Eine regelmäßige Schwachstellenanalyse muss Teil des Wartungsprozesses sein. Und zwar nicht nur im Sinne eines Scans, der CVE-IDs auflistet. Sondern wirklich als systematische Prüfung der eigenen Umgebung. Wo laufen die Dienste? Welche Netzwerkschnittstellen sind exponiert? Gibt es veraltete PHP-Versionen? Welche Apps sind installiert und welche davon sind noch supported? Oft ist es der unscheinbare Kandidat – eine kleine App für 2FA, die kaum noch gewartet wird – der die größten Risiken birgt. Ich habe Fälle gesehen, in denen Administratoren die Sicherheit ihrer Nextcloud-Instanz anhand der Changelogs der Kernsoftware bewertet haben, aber die Apps gar nicht im Blick hatten. Das ist so, als würde man die Alarmanlage eines Hauses auf dem neuesten Stand halten, während die Hintertür offensteht.
Ein weiteres Feld, das in der Praxis oft vernachlässigt wird, ist die Analyse der Zugriffslogdaten. Nextcloud protokolliert umfangreich, wer wann auf welche Dateien zugegriffen hat. Diese Logs sind eine Goldmine für die Erkennung von Angriffsmustern. Ein wiederholter Fehlversuch bei der Authentifizierung aus einer ungewöhnlichen IP-Region? Ein plötzlicher Anstieg von Downloads einer bestimmten Datei? Solche Anomalien deuten auf einen erfolgreichen Einbruch hin, oft lange bevor ein Patch verfügbar ist. Die Herausforderung ist allerdings, diese Logs auch zu analysieren. In kleinen Teams fehlt die Zeit, in großen Teams die automatisierte Auswertung. Hier bieten sich SIEM-Systeme an, aber die sind für viele Nextcloud-Betreiber eine zu teure Lösung. In der Konsequenz liegen die Logs brach, und die Chance, frühzeitig zu reagieren, verstreicht.
Die Architektur von Nextcloud selbst bietet einige Sicherheitsfeatures, die man aktiv nutzen sollte. Die sogenannte „File Access Control“ etwa erlaubt es, Zugriffe auf Dateien auf Basis von Regeln zu beschränken: Wer darf welche Dateien wann von wo aus öffnen? Das ist nicht nur für Compliance-Fragen nützlich, sondern auch ein Werkzeug zur Eindämmung von Schäden, falls ein Konto kompromittiert wird. Allerdings setzen viele Administratoren diese Funktion aus Komplexitätsgründen nicht ein. Sie vertrauen stattdessen auf die grundlegenden Berechtigungen, die in Nextcloud ohnehin schon granulär sind. Aber Granularität allein schützt nicht vor einer missbräuchlichen Nutzung legitimer Zugänge. Die Kunst besteht darin, die Balance zu finden zwischen Sicherheit und Benutzerfreundlichkeit – eine Kunst, die in der Praxis oft scheitert, weil die Anwender sich über zu viele Einschränkungen beschweren.
Ein wichtiger Punkt, den jede Schwachstellenanalyse berücksichtigen muss, ist die Abhängigkeit von Drittinfrastruktur. Nextcloud läuft oft in Docker-Containern auf einem Linux-Host, mit einem MySQL- oder PostgreSQL-Backend. Die Sicherheit dieser Komponenten ist genauso relevant wie die der Nextcloud-Software selbst. Ein kritischer Fehler in der Datenbankversion, ein veralteter Redis-Server, eine unsichere Konfiguration von Nginx – all das kann die gesamte Kette gefährden. In der Sorgfalt der Administratoren liegt hier eine große Varianz. Der eine pflegt seine Updates minutiös, der andere hat noch eine MariaDB-Version von 2017 im Einsatz, weil „das Ding läuft ja“. Dass Nextcloud selbst Sicherheitsupdates herausgibt, nützt wenig, wenn die darunterliegenden Schichten löchrig sind.
Vielleicht überrascht es nicht, dass die häufigste Angriffsquelle auf Nextcloud-Instanzen nicht etwa die Software selbst ist, sondern unsichere Passwörter. Trotz aller technischen Maßnahmen – ein schwaches Administratorpasswort („admin123“ oder „Passwort1“) kommt erschreckend oft vor. Selbst mit Zwei-Faktor-Authentifizierung, die Nextcloud unterstützt, lassen sich durch Brute-Force-Angriffe auf das Passwort von Benutzern Zugänge erobern, wenn die 2FA nicht für alle Nutzer verpflichtend ist. Die Analyse der Anmeldeversuche in den Logs ist daher ein guter erster Schritt für jeden, der seine Nextcloud-Instanz auf Schwachstellen untersuchen möchte. Es gibt Tools, die diese Analyse automatisieren, etwa mit fail2ban. Das ist schnell eingerichtet und senkt das Risiko drastisch. Trotzdem habe ich oft gesehen, dass Administratoren diese einfache Maßnahme nicht umsetzen, weil sie den Eindruck haben, dass ihr Netzwerk „sicher genug“ sei.
Die Nextcloud-Entwickler haben in den letzten Versionen einen bemerkenswerten Fokus auf Security-by-Design gelegt. Das Konzept der „Sprechenden URLs“ wurde überarbeitet, um Information Leakage zu vermeiden. Auch die Implementierung von Content Security Policy (CSP) im Frontend ist vorbildlich. Dennoch entdeckt das Nextcloud-Sicherheitsteam regelmäßig neue Lücken, die oft in der Schnittstellenlogik zwischen API und Frontend liegen. Eine Schwachstelle aus dem Frühjahr 2023 betraf die Dateiversionierung: Ein Angreifer konnte durch eine geschickt platzierte Anfrage ältere Versionen einer Datei einsehen, auf die er eigentlich keinen Zugriff mehr haben sollte. Das Problem war kein SQL-Injection, sondern ein Race-Condition in der Berechtigungsprüfung. Solche Fehler sind schwer zu finden und noch schwerer zuverlässig zu patchen. Für Admins bedeutet das: Auch wenn die Nextcloud-Instanz aktuell ist, kann ein Angriff auf noch nicht entdeckte Schwachstellen (Zero-Day) erfolgreich sein. Deshalb reicht eine reine Patch-Aktualisierung nicht. Man muss die Systeme auch überwachen und verdächtiges Verhalten erkennen können.
Eine effektive Schwachstellenanalyse bei Nextcloud umfasst idealerweise mehrere Schichten. Auf der Ebene der Software sollte man einen Vulnerability Scanner einsetzen, der CVE-Datenbanken abgleicht. Aber die reine Liste ist wertlos, wenn man die gefundenen Lücken nicht priorisiert und im Kontext der eigenen Umgebung bewertet. Ein CVSS-Score von 7.5 sagt nicht viel aus, wenn die betroffene Komponente in der eigenen Installation deaktiviert ist. Umgekehrt kann eine Schwachstelle mit CVSS 4.3 katastrophal sein, wenn sie eine App betrifft, die im täglichen Betrieb von Hunderten von Nutzern verwendet wird. Die Priorisierung ist keine Rechnerei, sondern erfordert Erfahrung und ein gutes Verständnis der eigenen Architektur. In der Praxis setzen sich Admins oft einen fixen Schwellenwert (z. B. alles ab CVSS 6 muss sofort gepatcht werden) und übergehen damit dringende Situationen, die anderswo liegen.
Ein Thema, das in der Community immer wieder aufkommt, ist die Frage nach der Sicherheit der Datenverschlüsselung in Nextcloud. Die Plattform bietet eine serverseitige Verschlüsselung an, die jedoch nicht vor dem Zugriff durch den Serverbetreiber schützt – das ist ein häufiges Missverständnis. Die serverseite Verschlüsselung schützt nur vor physikalischem Diebstahl der Festplatten, nicht vor einem Angreifer, der sich Zugang zum Nextcloud-Prozess verschafft. Echte Ende-zu-Ende-Verschlüsselung (E2EE) ist in Nextcloud als App verfügbar, aber sie ist komplex einzurichten und hat Einschränkungen, etwa bei der gemeinsamen Bearbeitung von Dokumenten. Viele Unternehmen, die aus Datenschutzgründen Nextcloud einsetzen, gehen davon aus, dass ihre Daten bereits vollständig verschlüsselt sind – und liegen damit falsch. Eine Schwachstellenanalyse sollte daher auch die Verschlüsselungskonfiguration überprüfen und dokumentieren, welche Daten tatsächlich durch E2EE geschützt sind und welche nicht.
Die Dynamik der Bedrohungslandschaft verlangt einen kontinuierlichen Prozess. Einmal im Jahr einen Pentest durchzuführen, ist nicht ausreichend. Nextcloud veröffentlicht Sicherheitsupdates im Schnitt alle zwei bis drei Wochen. Wer da nicht aufmerksam bleibt, hinkt hinterher. Admins sollten sich in die entsprechenden Mailinglisten oder RSS-Feeds eintragen. Dass das oft untergeht, liegt nicht am Desinteresse, sondern an der Informationsflut. Jede dritte E-Mail ist eine Sicherheitswarnung, irgendwann stumpft man ab. Hilfreich ist eine Automatisierung: Ein Skript, das täglich die neuesten CVEs zur installierten Nextcloud-Version abruft und den Admin mit einer Punktlandung benachrichtigt, wenn Handlungsbedarf besteht. Solche Tools gibt es, müssen aber installiert und konfiguriert werden.
Nicht zuletzt sollten Administratoren einen genauen Blick auf die Konfiguration der Nextcloud-Instanz werfen. Standardmäßig sind viele Einstellungen auf Sicherheit getrimmt, aber nicht alle. So ist etwa die „Lax“-Einstellung für SameSite-Cookies in älteren Versionen die Voreinstellung, obwohl „Strict“ deutlich sicherer wäre. Auch die Aktivierung von HSTS (HTTP Strict Transport Security) sollte manuell gesetzt werden, da Nextcloud sie nicht automatisch forciert. Eine Konfigurationsanalyse lässt sich mit Tools wie dem Nextcloud Security Scanner durchführen, den die Entwickler selbst anbieten. Das ist ein Online-Service, der die öffentlich erreichbare Nextcloud-Instanz auf eine Reihe von Sicherheitsparametern überprüft. Das Ergebnis ist oft ernüchternd: Viele Instanzen haben veraltete TLS-Versionen oder fehlende Security-Header. Der Scanner ist kostenlos, aber er setzt voraus, dass die Instanz über das Internet erreichbar ist. Bei rein internen Installationen muss der Admin selbst prüfen. Ein Aufwand, der sich lohnt.
Eines der kontroversesten Themen in der Nextcloud-Sicherheit ist der Umgang mit Apps aus dem offiziellen App Store. Nextcloud prüft jede App vor der Veröffentlichung auf grundlegende Sicherheitsmängel, aber die Überprüfung ist nicht so tiefgehend wie ein Code-Audit. Es gab Fälle, in denen Apps schadhafte Funktionen enthielten, die etwa Daten an externe Server übertrugen – sogenannte Spyware. Nextcloud hat diese Apps dann aus dem Store entfernt, aber sie waren zuvor für eine gewisse Zeit verfügbar. Für die Schwachstellenanalyse bedeutet das: Man sollte die Liste der installierten Apps regelmäßig durchgehen und jede einzelne auf ihren Verwendungszweck prüfen. Ist sie noch nötig? Wer pflegt sie? Gibt es bekannte Sicherheitsvorfälle? Dieser manuelle Check ist zwar aufwändig, aber unverzichtbar. Automatisierung kann hier nur bedingt helfen, weil die Entscheidung über die Vertrauenswürdigkeit einer App letztlich eine menschliche ist.
Ein weiterer Punkt, der in der Diskussion oft zu kurz kommt, ist der Faktor Mensch. Die größte Schwachstelle in jeder IT-Infrastruktur ist der Benutzer. Phishing-Angriffe auf Nextcloud-Konten sind alltäglich. Und Nextcloud bietet zwar die Möglichkeit, MFA zu erzwingen, aber viele Unternehmen tun es nicht, weil sie den Aufwand für die Benutzerverwaltung scheuen. In der Praxis sieht es oft so aus: Ein Mitarbeiter erhält eine E-Mail, die vorgeblich von der IT-Abteilung stammt, mit einem Link zur Nextcloud-Instanz. Er klickt darauf, gibt seine Anmeldedaten ein – und schon ist das Konto gekapert. Der Angreifer hat Zugriff auf alle Dateien, die dieser Nutzer sehen darf. Die Nextcloud-Sicherung selbst ist dann zweitrangig. Hier hilft nur Aufklärung und technische Maßnahmen wie WebAuthn oder Hardware-Token für die 2FA. Aber auch das nützt nichts, wenn der Mitarbeiter seinen Token verliert und die IT dann aus Bequemlichkeit einen Workaround ohne 2FA bereitstellt.
Die Schwachstellenanalyse einer Nextcloud-Umgebung kann man nicht auf einen Werkzeugkasten reduzieren. Sie ist ein Prozess, der die technische Prüfung mit organisatorischen und menschlichen Faktoren verbindet. Eine regelmäßige Überprüfung der Konfiguration, das Lesen der Security-Bulletins, das Testen der Backup- und Disaster-Recovery-Pläne – all das gehört dazu. Ein interessanter Aspekt, den ich in vielen Unternehmen beobachtet habe, ist die Negierung des Restrisikos. Man patched alles, hat eine Firewall, setzt auf Verschlüsselung, und dennoch: Es bleibt ein Restrisiko, dass eine bislang unbekannte Lücke ausgenutzt wird. Statt dieses Risiko zu akzeptieren, betreiben manche Admins einen Overengineering-Overkill, der das System so komplex macht, dass neue Fehler entstehen. Die Kunst ist es, die richtigen Maßnahmen zu setzen und nicht in blinden Aktionismus zu verfallen.
Ein Tipp aus der Praxis: Schauen Sie sich die CVE-Liste der letzten zwölf Monate für Nextcloud an. Sie werden überrascht sein, wie viele der gemeldeten Lücken inzwischen bekannt sind, aber dennoch nicht gepatcht werden. Der Grund ist oft, dass die Aktualisierung den laufenden Betrieb kurzzeitig unterbricht oder weil ein Update einer kritischen App mit Breaking Changes daherkommt. Das ist ein schwieriger Spagat. Aber Sicherheitslücken zu ignorieren, weil der Patch „zu viel Aufwand“ ist, ist kein haltbarer Betriebsmodus. Nextcloud selbst bietet seit Version 25 eine Major-Upgrade-Unterstützung, mit der man direkt von einer Hauptversion auf die nächste springen kann ohne Zwischenschritte. Das vereinfacht die Aktualisierung. Dennoch stoßen Administratoren immer wieder auf Hürden, etwa bei der Anpassung von Themes oder Datenbank-Migrationen.
In den Fachforen und Konferenzen wird auch zunehmend die Nutzung von Containern diskutiert. Nextcloud als Docker-Container zu betreiben, ist heute Standard. Doch die Sicherheit eines Containers hängt stark von der Host-Konfiguration ab. Container-Root-Rechte, falsch gesetzte User-ID-Mappings, unnötig geöffnete Ports, persistent Speicher mit falschen Berechtigungen – die Liste möglicher Fehler ist lang. Wer Nextcloud in einer Docker-Umgebung betreibt, sollte sich unbedingt mit den Sicherheitsempfehlungen des Docker-Betreibers vertraut machen. Ein einfacher `docker run` mit den Standardoptionen ist oft unsicher. Ich empfehle, die Nextcloud-Container mit einem gesonderten Benutzer (UID) laufen zu lassen und die Kernel-Capabilities drastisch zu reduzieren. Auch die Überwachung des Container-Verhaltens mit Tools wie Falco kann helfen, Anomalien zu erkennen.
Ein weiteres Thema ist die Netzwerksegmentierung. Nextcloud sollte idealerweise in einer eigenen DMZ stehen, getrennt von anderen internen Diensten. Wenn ein Angreifer Zugriff auf den Nextcloud-Server erlangt, soll er nicht von dort aus sofort das gesamte Firmennetzwerk angreifen können. Das klingt nach Basissicherheit, wird aber oft aus Kostengründen ignoriert. In kleinen Unternehmen läuft Nextcloud oft auf demselben Server wie die Firmenwebseite oder das Ticketsystem. Das ist ein gefährliches Konstrukt. Eine Schwachstellenanalyse muss auch die Netzwerkarchitektur bewerten und auf mögliche laterale Bewegungen hinweisen. Firewalls und VLANs sind keine Option, sondern eine Notwendigkeit. Und das Schlimmste, was passieren kann, ist ein Angriff, der von Nextcloud ausgehend auf die Active-Directory-Umgebung übergreift – dann sind die Schäden unkalkulierbar.
Die Datenschutz-Grundverordnung (DSGVO) spielt in der Diskussion um Nextcloud-Schwachstellen natürlich eine große Rolle. Denn eine Datenpanne, die durch eine nicht geschlossene Lücke verursacht wird, kann empfindliche Bußgelder nach sich ziehen. Nextcloud wird oft genau wegen der DSGVO-Konformität gewählt, aber die Konformität ist nur gegeben, wenn auch die Sicherheit auf dem aktuellen Stand ist. Eine Schwachstelle in der Zugriffskontrolle, die dazu führt, dass vertrauliche Dokumente von Unbefugten eingesehen werden können, ist ein meldepflichtiger Vorfall. Wer also Nextcloud betreibt, muss nicht nur aus technischer, sondern auch aus rechtlicher Perspektive eine kontinuierliche Schwachstellenanalyse durchführen. Das ist ein zusätzlicher Druck, der aber auch dazu beiträgt, dass das Thema ernst genommen wird.
In der Praxis habe ich immer wieder festgestellt, dass der simplste Fehler der unsicherste ist: Die Verwendung des Standard-Administratorkontos „admin“. Nextcloud erlaubt es, den Admin-Benutzernamen zu ändern, aber viele lassen es auf dem Default. Das ist das erste, was ein Angreifer ausprobiert. Wer bei der Schwachstellenanalyse nichts anderes macht, als den Admin-Namen zu ändern und ein starkes Passwort zu setzen, hat schon einen großen Schritt getan. Aber das ist natürlich nur der Anfang. Das gesamte Thema Sicherheit ist ein Marathon, kein Sprint. Und Nextcloud mit seinem großen Ökosystem verlangt ständige Aufmerksamkeit. Wer das nicht leisten kann, sollte überlegen, ob er die Plattform nicht in einer gemanagten Variante betreiben möchte, etwa als Nextcloud Enterprise mit Support-Vertrag. Das kostet Geld, spart aber Zeit und Nerven.
Zum Abschluss möchte ich noch auf einen Punkt hinweisen, der in der Diskussion über Schwachstellenanalysen oft unterschlagen wird: die Dokumentation. Wenn Sie eine Schwachstelle finden – sei es durch einen Scanner oder durch einen Hinweis aus der Community – dann dokumentieren Sie den Fund, die Bewertung und die Maßnahme. Das ist nicht nur für die Nachvollziehbarkeit wichtig, sondern auch für das nächste Audit. Und es hilft Ihnen selbst, wenn Sie Monate später auf das gleiche Problem stoßen. Ich habe schon oft erlebt, dass Admins dieselbe Lücke zweimal patchen, weil sie vergessen haben, dass sie es schon einmal gemacht haben. Oder schlimmer noch: Sie haben die Lücke nicht dokumentiert und müssen später zugeben, dass sie keine Ahnung hatten, ob die Instanz einmal kompromittiert war. Die Schwachstellenanalyse ist kein einmaliges Projekt, sondern ein kontinuierlicher Kreislauf aus Erkennen, Bewerten, Beheben und Lernen. Nextcloud bietet dafür eine gute Grundlage, aber die Verantwortung liegt bei den Betreibern.
Wenn ich auf die vergangenen Jahre zurückschaue, dann sehe ich ein System, das in der Breite sicherer geworden ist, aber auch ein Angriffsumfeld, das professioneller und gezielter vorgeht. Nextcloud selbst reagiert auf gemeldete Lücken in der Regel innerhalb weniger Tage mit einem Patch. Das ist beeindruckend für ein Open-Source-Projekt. Aber die Update-Politik der Betreiber hinkt oft hinterher. Ein kürzlich veröffentlichter Report zeigte, dass fast ein Drittel aller öffentlich erreichbaren Nextcloud-Instanzen mehr als drei Monate alte Versionen verwendeten. Das ist keine Kritik an Nextcloud, sondern ein Weckruf an die Gemeinschaft. Eine Schwachstellenanalyse ist kein Hexenwerk, aber sie erfordert Disziplin. Und die ist in der IT manchmal knapper als gedacht.
Wer also seine Nextcloud-Instanz auf Vordermann bringen will, der sollte heute damit anfangen. Prüfen Sie die letzten Logins, durchsuchen Sie die installierten Apps, gleichen Sie die Versionen mit den aktuellen Sicherheitsbulletins ab. Und dann stellen Sie sich die Frage: Was würde passieren, wenn morgen ein Angreifer Zugriff auf meine Nextcloud hätte? Wenn diese Frage unbehaglich ist, haben Sie noch Arbeit vor sich. Die Schwachstellenanalyse ist der Weg, diese Unbehaglichkeit in Kontrolle zu verwandeln. Sie ist das Rüstzeug, um aus einem „Moment, in dem der Kaffee kalt wird“ einen ruhigen Vormittag zu machen – oder zumindest einen, in dem man weiß, was zu tun ist.