Schwachstellenanalyse: Ein umfassender Leitfaden

Eine Sicherheits-Schwachstellenanalyse ist eine strukturierte Prüfung, die die Schwachstellen einer Anwendung aufspürt und ihren Schweregrad bewertet. Allerdings zeigen die Ergebnisse nicht, welche Fehler ein Angreifer tatsächlich ausnutzen könnte. Diesen Nachweis liefern Dienstleistungen für Penetrationstests, bei denen Spezialisten unter kontrollierten Bedingungen echte Angriffe durchführen.

Schwachstellen früh zu erkennen, ist dringlicher geworden. Im Data Breach Investigations Report 2026 von Verizon haben Software-Schwachstellen gestohlene Passwörter als häufigsten Weg in ein Unternehmen überholt: Auf sie entfielen 31 % der Sicherheitsverletzungen.

Das Thema leidet zudem unter einem Begriffsproblem, denn viele verwenden „Schwachstellenanalyse“ und „Risikobewertung“ synonym. Tatsächlich ermittelt eine Schwachstellenanalyse, was in Ihrer App fehlerhaft oder ungeschützt ist, während eine Risikobewertung misst, wie stark jedes Problem für Ihr Unternehmen ins Gewicht fällt. Dieser Leitfaden erklärt den Unterschied, führt Schritt für Schritt durch eine Sicherheits-Schwachstellenanalyse und zeigt, wo diese Prüfung in die reguläre QA passt.

Schwachstellenanalyse vs. Risikobewertung vs. Penetrationstest

Schwachstellenanalysen, Risikobewertungen und Penetrationstests werden oft verwechselt, weil sich alle drei mit Sicherheitsschwächen befassen. Doch jede beantwortet eine andere Frage, und wer diese Fragen kennt, kann die Prüfungen am schnellsten auseinanderhalten:

• Schwachstellenanalyse: Das US-amerikanische National Institute of Standards and Technology (NIST) definiert den Begriff als „systematische Untersuchung“, die dazu dient, „Sicherheitsmängel zu identifizieren“. In der Praxis durchsucht eine Sicherheits-Schwachstellenanalyse die App nach allen Schwachstellen und bewertet, wie gravierend jeder Befund ist.
• Risikobewertung: Laut NIST dient eine Risikobewertung Entscheidungsträgern dazu, „Risiken zu bewerten und zu priorisieren“. Die Prüfung verbindet bekannte Schwachstellen mit Bedrohungen und dem geschäftlichen Kontext, um einzuschätzen, wie wahrscheinlich ein Angriff ist und welchen Schaden er anrichten würde. Die Antworten hängen von den Umständen ab, denn derselbe Fehler kann auf einer Testseite, die niemand besucht, eine Kleinigkeit sein, auf Ihrer Checkout-Seite aber ein dringendes Problem.
• Penetrationstest: Mit Ihrer Erlaubnis versuchen Sicherheitsspezialisten einzudringen, häufig über die gravierendsten Schwachstellen, die eine Analyse gefunden hat. Nur ein Pentest beantwortet die Frage, die die beiden anderen Prüfungen offenlassen: Kann tatsächlich jemand eindringen, und wie weit käme ein Angreifer, wenn er erst einmal drin ist? Dieser Nachweis ist der Hauptgrund, warum Penetrationstests wichtig sind, selbst für Teams, die bereits regelmäßig scannen.

Die folgende Tabelle vergleicht alle drei auf einen Blick.

Warum auf die Analyse ein Pentest folgen sollte

Ein Pentest im Anschluss an eine Schwachstellenanalyse zeigt außerdem, ob die Schweregradbewertungen Bestand haben. So kann sich eine als „mittel“ eingestufte Schwachstelle als Glied einer Angriffskette erweisen, die bei Kundendaten endet, während ein „kritischer“ Fehler hinter einem Login liegen kann, den kein Außenstehender erreicht. Jede Überraschung fließt an das Analyseteam zurück, das ähnliche Probleme beim nächsten Mal treffsicherer einstuft. Falls Sie Ihre Optionen noch abwägen: Die Vor- und Nachteile von Penetrationstests und Schwachstellenscans hängen von Tiefe, Budget und Zeitpunkt ab.

Der Prozess der Schwachstellenanalyse in fünf Schritten

Sicherheitsanbieter unterteilen diese Arbeit in fünf bis acht Schritte, doch inhaltlich decken sie dasselbe ab. Der folgende Prozess der Schwachstellenanalyse ist die kürzeste Form und zeigt, was in jeder Phase passiert und was Sie am Ende erhalten sollten.

Schritt 1: Den Prüfumfang festlegen

Jede Sicherheits-Schwachstellenanalyse beginnt mit einem schriftlich festgelegten Prüfumfang, denn das Team kann nur prüfen, worauf sich alle Beteiligten geeinigt haben. Dieses Dokument benennt die betroffenen Apps, Funktionen und Nutzertypen. Nutzerrollen verdienen besondere Aufmerksamkeit, denn ein Kunde, ein Support-Mitarbeiter und ein Administrator sehen jeweils eine andere Version derselben App. Daher betrifft ein Fehler unter Umständen nur einen Kontotyp, während die beiden anderen nie damit in Berührung kommen. Auch Komponenten von Drittanbietern gehören in den Prüfumfang, also die fertigen Code-Bibliotheken und externen Dienste, auf die Ihre App angewiesen ist. Ihr Team hat diese Teile nicht selbst geschrieben, daher werden ihre Fehler leicht übersehen, sofern niemand sie gezielt prüft. Das Dokument sollte außerdem festhalten, was ausgeschlossen ist, etwa die eigenen Systeme eines Zahlungsanbieters, für deren Prüfung Sie keine Erlaubnis haben.

Schritt 2: Die App scannen und manuell prüfen

Sobald der Prüfumfang feststeht, übernehmen automatisierte Tools den ersten Durchlauf. Einige durchsuchen den Quellcode nach riskanten Mustern, andere testen die laufende App so, wie es der Browser eines Angreifers tun würde. Parallel dazu gleichen Dependency-Checker Ihre Drittanbieter-Komponenten mit öffentlichen Datenbanken bekannter Schwachstellen ab. Die Standardreferenz ist die Liste der Common Vulnerabilities and Exposures, in der jede veröffentlichte Schwachstelle eine eigene ID-Nummer hat. Über diese Kennung kann ein Scanbericht auf genau das betreffende Problem verweisen.

Musterabgleich erkennt allerdings nur Probleme, die bereits bekannt sind. Deshalb übersehen automatisierte Prüfungen Fehler in der Geschäftslogik, also in den Regeln, die festlegen, was Nutzer in Ihrer App tun dürfen. Ein Scanner bemerkt zum Beispiel in der Regel nicht, wenn Ihr Checkout jeden Preis akzeptiert, den der Browser zurücksendet. Wer diesen Betrag mit den integrierten Werkzeugen des Browsers ändert, könnte dann weniger als den tatsächlichen Gesamtbetrag zahlen. Ein Tester, der den Checkout durchläuft, sucht gezielt nach solchen Schlupflöchern. Wegen dieses blinden Flecks führen wir jede Sicherheits-Schwachstellenanalyse in einer festen Reihenfolge durch. Zuerst ermitteln wir die Wege, über die ein Angreifer in die App gelangen könnte. Dann setzen wir die Tools ein und bestätigen die Befunde manuell.

Schritt 3: Fehlalarme aussortieren

Scanner melden alles, was einem bekannten Problem ähnelt, daher enthält ein Rohbericht meist Fehlalarme (False Positives). Solche Warnungen verweisen auf Probleme, die in Ihrer Umgebung nicht existieren oder nicht erreichbar sind. Bevor der Bericht an Ihre Entwickler geht, prüft ein Sicherheitsspezialist jeden Befund und filtert das Rauschen heraus. Diese Prüfung ergänzt auch den Kontext, den kein Tool erkennt, etwa ob die betroffene Seite öffentlich ist oder hinter einem Login liegt. Der zusätzliche Durchgang erspart Ihren Entwicklern Tage, die sie sonst mit Warnungen verbringen würden, die nie real waren.

Schritt 4: Befunde nach Schweregrad und Wahrscheinlichkeit priorisieren

Selbst wenn die Fehlalarme aussortiert sind, ist die Liste meist länger, als ein Team auf einmal bewältigen kann. Laut dem State of Software Security Report 2026 von Veracode tragen bereits 82 % der Organisationen Sicherheitsschulden mit sich, also Schwachstellen, die länger als ein Jahr offen geblieben sind. Deshalb ist es entscheidend festzulegen, was zuerst behoben wird. Drei öffentliche Ressourcen helfen bei der Priorisierung:

• Schweregrad: Das Common Vulnerability Scoring System bewertet auf einer Skala von 0 bis 10, wie gravierend eine Schwachstelle ist.
• Angriffswahrscheinlichkeit: Das Exploit Prediction Scoring System schätzt die Wahrscheinlichkeit, dass eine veröffentlichte Schwachstelle innerhalb der nächsten 30 Tage angegriffen wird.
• Aktuelle Bedrohungen: Ein Katalog bekannter ausgenutzter Schwachstellen der US-amerikanischen Cybersecurity and Infrastructure Security Agency listet Schwachstellen auf, die Kriminelle bereits ausnutzen.

Keiner dieser Werte weiß jedoch etwas über Ihr Unternehmen. Diese Lücke schließt eine Risikobewertung, indem sie jeden Befund daran misst, was ein Angriff Sie tatsächlich kosten könnte.

Schritt 5: Probleme beheben und die Korrekturen prüfen

Sobald die Reihenfolge feststeht, liefert der Bericht der Sicherheits-Schwachstellenanalyse den Entwicklern alles, was sie zum Handeln brauchen: jede bestätigte Schwachstelle, ihre Bewertung, die Schritte zur Reproduktion und eine empfohlene Korrektur. Das Team arbeitet die Liste dann von oben nach unten ab, und Tester prüfen jede Änderung erneut, sobald sie eingespielt ist. Ohne diese zweite Prüfung könnte ein Patch eine Lücke schließen und dabei eine andere öffnen oder eine Funktion beschädigen, die bisher funktioniert hat. Ein Befund gilt erst als abgeschlossen, wenn Tester bestätigen, dass die Schwachstelle beseitigt ist.

Häufige Anwendungsschwachstellen, auf die Sie prüfen sollten

Wenn der Prozess klar ist, stellt sich die nächste Frage: Worauf sollte geprüft werden? Ein guter Ausgangspunkt ist eine gemeinnützige Community namens Open Worldwide Application Security Project (OWASP). Die Organisation veröffentlicht die OWASP Top 10, eine Rangliste der kritischsten Sicherheitsrisiken für Webanwendungen. Die aktuelle Ausgabe stammt aus dem Jahr 2025, und ihre zehn Einträge bilden eine praxistaugliche Checkliste für jede Sicherheits-Schwachstellenanalyse:

1. Fehlerhafte Zugriffskontrolle: Nutzer können Daten sehen oder Aktionen ausführen, die ihnen nicht zustehen, etwa die Rechnung eines anderen Kunden öffnen, indem sie eine Zahl in der Webadresse ändern. Die Ausgabe 2025 ordnet dieser Kategorie auch Server-Side Request Forgery zu. Bei diesem Angriff bringt jemand Ihr System dazu, in seinem Auftrag Seiten abzurufen.
2. Sicherheitsrelevante Fehlkonfiguration: Standardpasswörter, zu ausführliche Fehlermeldungen und öffentlich zugänglicher Cloud-Speicher bieten Angreifern einen einfachen Zugang.
3. Fehler in der Software-Lieferkette: Risiken gelangen über fertigen Code, Build-Tools und Updates ins System, die Ihr Team nicht selbst geschrieben hat.
4. Kryptografische Fehler: Schwache oder fehlende Verschlüsselung macht Passwörter und Zahlungsdaten für jeden lesbar, der sie abfängt.
5. Injection: Die App behandelt Eingaben eines Angreifers als Befehl. SQL-Injection tut dies bei Datenbanken, Cross-Site Scripting bei den Browsern anderer Nutzer.
6. Unsicheres Design: Der Fehler steckt bereits im Entwurf, sodass ihn auch noch so sorgfältiges Programmieren später nicht beheben kann.
7. Fehler bei der Authentifizierung: Eine schwache Login- und Sitzungsverwaltung ermöglicht es Angreifern, Passwörter zu erraten oder Konten zu übernehmen.
8. Fehler bei der Software- oder Datenintegrität: Die App vertraut Updates, Plugins oder Daten, ohne deren Herkunft zu prüfen.
9. Fehler bei Sicherheitsprotokollierung und Alarmierung: Angriffe bleiben unbemerkt, weil niemand verdächtige Aktivitäten aufzeichnet oder überprüft.
10. Fehlerhafte Behandlung von Ausnahmezuständen: Die App versagt auf unsichere Weise, wenn etwas Unerwartetes passiert, zum Beispiel indem sie Daten preisgibt, nachdem ein Zahlungsdienst nicht mehr antwortet.

Wo die Schwachstellenanalyse in die QA passt

Die zuvor beschriebenen fünf Schritte ergeben zusammen eine einmalige Prüfung, deren Ergebnisse schnell veralten. Viele Unternehmen behandeln eine Sicherheits-Schwachstellenanalyse noch immer als jährliches Audit. Ihre Apps erhalten jedoch alle paar Wochen Updates, sodass eine jährliche Prüfung nicht mithalten kann. Auch Angreifer sind schneller geworden. Das Mandiant-Team von Google berichtete in M-Trends 2026, dass die durchschnittliche Zeit bis zur Ausnutzung einer Schwachstelle unter null gesunken ist, auf geschätzte -7 Tage. Mit anderen Worten: Angriffe beginnen regelmäßig, bevor überhaupt ein Fix existiert.

Besser ist es, die Analyse zu einem festen Bestandteil der QA zu machen und ihre Tiefe daran auszurichten, wie oft Sie releasen:

• Bei jeder Codeänderung: Automatisierte Code- und Komponentenprüfungen laufen neben Ihren anderen Tests und melden neue Probleme innerhalb von Minuten.
• Bei jedem Release: Ein Scan der laufenden App und eine manuelle Prüfung decken die geänderten Funktionen ab.
• Vor einem großen Launch oder Audit: Zuerst erfolgt eine vollständige Analyse der gesamten App, danach ein Pentest.

Dieser Rhythmus ist Teil eines umfassenderen Ansatzes namens Shift-Left-Testing. Die Idee dahinter: Probleme ab den frühesten Projektphasen erkennen, solange der Code dem Entwickler noch frisch im Gedächtnis ist. Regelmäßige Prüfungen verhindern außerdem einen Engpass kurz vor dem Launch. Deshalb integriert unser Team für Sicherheitstests diese Arbeit in Ihren bestehenden Release-Zeitplan, sodass Prüfungen die Auslieferung nie aufhalten.

Für Unternehmen, die in der EU verkaufen, hat die regelmäßige Analyse inzwischen auch eine rechtliche Seite. Seit dem 11. September 2026 verpflichtet der Cyber Resilience Act Hersteller, jede Schwachstelle in ihrem Produkt zu melden, die Angreifer aktiv ausnutzen. Eine Frühwarnung ist innerhalb von 24 Stunden nach Bekanntwerden fällig. Ein Team, das bereits jedes Release prüft, findet seine eigenen Schwachstellen mit größerer Wahrscheinlichkeit, bevor diese Frist überhaupt zu laufen beginnt.

Wie wir jede Analyse auf echte Risiken ausrichten

In unseren eigenen Projekten setzt jede Sicherheits-Schwachstellenanalyse bei den größten Risiken des Produkts an. Als wir ICONOMI testeten, eine Plattform für das Management von Krypto-Assets, stand der Schutz der Nutzerkonten an erster Stelle. Wir prüften die Passworteinrichtung, die Identitätsprüfung mit Dokumenten-Upload und die VPN-Erkennung. Unsere Ingenieure fütterten den Registrierungsprozess außerdem gezielt mit fehlerhaften Eingaben, etwa Sonderzeichen in Namen oder sehr großen Dateien, um versteckte Schwachstellen aufzudecken.

Bei Union54 lag die Priorität anders. Im Mittelpunkt des Produkts stand eine Programmierschnittstelle (API), also die Verbindung, über die Programme miteinander kommunizieren. Unser Team testete diese API auf korrekte Authentifizierung und Zugriffskontrollen, damit jeder Kontotyp nur auf die für ihn bestimmten Daten zugreifen konnte. In beiden Projekten lief die Sicherheitsarbeit innerhalb eines umfassenderen QA-Auftrags, also genau nach dem Ansatz, den dieser Abschnitt empfiehlt.

Befunde in Korrekturen umsetzen und diese nachweisen

Eine Sicherheits-Schwachstellenanalyse zahlt sich nur aus, wenn ihre Ergebnisse zu echten Korrekturen führen. Dafür braucht es drei Dinge:

1. Priorisieren Sie die Schwachstellen nach ihren Auswirkungen auf Ihr Unternehmen.
2. Beheben Sie sie in dieser Reihenfolge und testen Sie jede Korrektur erneut.
3. Führen Sie für die gravierendsten Probleme einen Penetrationstest durch, um zu sehen, was ein Angreifer tatsächlich ausnutzen könnte.

Fehlt einer dieser Schritte, wird der Bericht zu einem weiteren Dokument, auf das niemand reagiert. Deshalb übernimmt QAwerk den gesamten Zyklus in einem einzigen Auftrag, von der Analyse und Risikopriorisierung bis zu Retests und praktischen Penetrationstests. Lassen Sie Ihre App von unserem Sicherheitsteam prüfen.

FAQ

Sehen Sie sich ein Beispiel unserer Sicherheitscodeüberprüfung einer in den USA ansässigen E-Commerce-Plattform an.

Dieser Bericht hebt die von uns gefundenen Schwachstellen hervor, kategorisiert nach Schweregrad, und enthält Empfehlungen zu deren Behebung.

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

PDF herunterladen