In diesem Abschnitt behandeln wir Themen, die sich direkt oder indirekt mit der sicherheitsbezogenen Software-Validierung befassen.
Funktionale und nicht-funktionale Tests
Functional Testing
Beim funktionalen Testen wird überprüft, ob eine Anwendung den Spezifikationen entsprechend funktioniert, sowohl auf Komponenten- als auch auf Systemebene. Die Tests sollten in einer realitätsnahen Testumgebung stattfinden.
Typen funktionaler Tests:
Unit Testing (Modultest) – einzelne Funktionen oder Module werden isoliert getestet.
Integration Testing – die Zusammenarbeit mehrerer Module wird überprüft, um sicherzustellen, dass sie korrekt interagieren.
Regression Testing – nach Änderungen oder Patches wird sichergestellt, dass keine neuen Fehler eingeführt oder alte Schwachstellen reaktiviert wurden.
Usability Testing – Bewertung der Benutzerfreundlichkeit aus Endnutzerperspektive.
Non-Functional Testing
Beim nicht-funktionalen Testen liegt der Fokus auf der Qualität der Anwendung, also auf Aspekten wie Sicherheit, Effizienz, Skalierbarkeit und Kompatibilität. Die theoretische Grundlage dafür liefert ISO/IEC 25010, das Qualitätsmerkmale für Software definiert.
Typen nicht-funktionaler Tests:
Security Testing – Überprüfung der Sicherheitsanforderungen wie Verschlüsselung, Authentifizierung und Zugriffskontrollen. Dazu gehören auch Penetrationstests, auf die im nächsten Abschnitt noch detaillierter eingegangen wird.
Performance Testing – Messung der Reaktionszeit und des Ressourcenverbrauchs unter normaler Last.
Capacity / Load Testing – Bewertung der Leistungsfähigkeit und Skalierbarkeit unter erhöhter oder maximaler Last.
Compatibility Testing – Überprüfung der Geräte- und Plattformkompatibilität, z. B. auf verschiedenen Betriebssystemen oder Browsern.
Documentation Validation – Überprüfung, ob Handbücher und Code-Dokumentation korrekt und vollständig sind.
Methoden der Sicherheitstests
Wenn es im vorherigen Teil darum ging, „was“ getestet wird, geht es im weiteren Teil um die Frage „wie“ getestet wird. Wir beginnen mit den drei Testansätzen Blackbox, Greybox und Whitebox – und besprechen anschließend die drei Testarten SAST, DAST und IAST.
Die drei Testansätze unterscheiden sich grundsätzlich im Wissensstand des Testers:
Whitebox – der Tester hat vollständige Einsicht in die interne Infrastruktur (IP-Adressen, Hostnamen), den Quellcode und die Systemdokumentation (inkl. Architektur- und Netzwerkdiagramme). Solche Tests werden in den meisten Fällen von internen Sicherheitsteams durchgeführt.
Greybox – der Tester hat eingeschränktes Wissen über das System, kann aber dadurch realistischere Angriffsbedingungen simulieren. Der Tester kann dabei sowohl intern als auch extern sein.
Blackbox – hier wird ein echter Angriff simuliert. Der externe Pentester hat keinerlei Kenntnisse über interne Abläufe oder Architektur.
Application Testing
Wie bereits in Abschnitt 4.2 erwähnt, ist Application Testing ein zentraler Bestandteil des SSDLC. Hier folgen die Details.
SAST (Static Application Security Testing) – überprüft den Quellcode auf Schwachstellen, bevor die Anwendung gestartet wird. Das ist die konsequente Umsetzung des Shift-Left-Prinzips. Bekannte Tools: SonarQube, Fortify, Checkmarx.
DAST (Dynamic Application Security Testing) – die Anwendung wird getestet, während sie aktiv läuft. Die Tests finden typischerweise in Staging- oder Pre-Production-Umgebungen statt – in echten Produktionsumgebungen nur sehr kontrolliert, da Tests laufende Dienste beeinflussen können. Bekannte Tools: Zed Attack Proxy, Burp Suite, Netsparker.
IAST (Interactive Application Security Testing) – kombiniert die Vorteile von SAST und DAST: Während SAST keine Laufzeitfehler erkennt und DAST keine Schwachstellen im Quellcode findet, schließt IAST diese Lücke. Technisch funktioniert es über einen Software-Agenten, der direkt in die laufende Anwendung eingebettet wird und Schwachstellen in Echtzeit analysiert. Bekannte Tools: Contrast Assess, Black Duck Seeker, Veracode IAST.
Peer Code Review – ergänzend zu den automatisierten Tools ist die manuelle Code-Überprüfung durch Entwicklerkollegen. Das Vier-Augen-Prinzip erkennt Logikfehler und Sicherheitsprobleme oft schneller, als es automatisierte Tools können.
Software Composition Analysis (SCA)
Moderne Softwareprodukte basieren zu einem großen Teil auf fertigen Bausteinen, sogenannten Open-Source-Bibliotheken. Dabei stellen sich zwei grundlegende Fragen: Sind diese Bausteine sicher, keine bekannten CVEs, keine veralteten Komponenten? Und darf man sie rechtssicher verwenden, sind sie lizenzkonform? Genau diese Fragen beantwortet SCA.
Idealerweise wird SCA direkt in die CI/CD-Pipeline integriert, sodass bei jedem Code-Commit automatisch geprüft wird, ob neue oder bestehende Abhängigkeiten Schwachstellen enthalten.
Nachdem ein SCA-Tool das Projekt gescannt hat, wird eine detaillierte Inventarliste aller verwendeten Bibliotheken erstellt – die SBOM (Software Bill of Materials). Diese Liste gewinnt zunehmend an rechtlicher Bedeutung: Der EU Cyber Resilience Act schreibt für viele Softwareprodukte eine SBOM vor.
Bekannte SCA-Tools: Black Duck, Snyk, OWASP Dependency-Check, Dependabot (direkt in GitHub integriert) und Mend.
Qualitätssicherung (QA – Quality Assurance)
Die QA ist die komischste Entität in diesem gesamten Abschnitt. Es ist gleichzeitig ein Prozess, eine Methode, oft auch eine eigene Rolle und kann sogar eine eigene Abteilung im Unternehmen sein. Der entscheidende Unterschied zum reinen Testing besteht darin, dass Testing bereits vorhandene Fehler im Code entdeckt, während QA durch Prozesse, Standards und Kontrollen versucht, die Entstehung von Fehlern von vornherein zu verhindern.
Letztendlich sind alle bisher beschriebenen Testmethoden Werkzeuge der QA. Die QA fungiert im Grunde genommen als „Dach“ über dem gesamten Qualitätssicherungsprozess.
Testen von Missbrauchsfällen (Abuse Case Testing)
Viele der oben beschriebenen Tests fokussieren sich auf einen „normalen“ Anwendungsfall, bei dem die Anwendung das tun muss, was sie soll.
Beim Abuse-Case-Testing ist es genau umgekehrt: Es wird untersucht, was passiert, wenn jemand die Anwendung absichtlich missbraucht. Der Tester schlüpft dabei in die Rolle eines Angreifers und versucht, Funktionen missbräuchlich zu nutzen, Eingaben zu manipulieren oder die Grenzen des Systems auszureizen.