Antwort.

Die Idee der Automatisierung von Sicherheitstests für Anwendungen entwickelte sich mit dem Anstieg von Cyberbedrohungen. Zunächst war das Sicherheitstestverfahren fast vollständig manuell, aber die Entwicklung von DevOps und Automatisierung ermöglichte die Integration von Sicherheitsüberprüfungen in CI/CD-Pipelines.

Historie der Fragestellung

In den frühen Jahren waren manuelle Penetrationstests (Pentests) und Scanner die einzigen Werkzeuge zur Überprüfung von Sicherheitsanfälligkeiten. Später wurden separate automatisierte Scanner entwickelt, und dann ganze Plattformen, die in die Prozesse integriert werden können.

Problem

Sicherheitstests dauern oft lange und werden selten aktualisiert.
Hohe Anzahl an „falschen Positiven“.
Erforderlichkeit komplexer Anpassungen an Infrastruktur und Anwendung.
Nicht alle Sicherheitsanfälligkeiten können automatisch gefunden werden – einige Prüfungen erfordern Expertenanalysen.

Lösung

Integrieren Sie automatisierte Sicherheitstests in die CI/CD-Phase: Verwenden Sie DAST/SAST-Analysatoren, automatische Scanner (OWASP ZAP, SonarQube, Checkmarx usw.).
Aktualisieren Sie regelmäßig Berichte und Testskripte, konfigurieren Sie die Verarbeitung von falschen Positiven.
Kombinieren Sie Automatisierung mit periodischen manuellen Audits und Retrospektiven.

Wesentliche Merkmale:

SAST/DAST/RASP-Scanning
Integration mit CI/CD
Verarbeitung und Automatisierung von Reaktionen auf Vorfälle

Fangfragen.

Ist es möglich, alle Sicherheitsanfälligkeiten ausschließlich mit automatisierten Tests zu finden?

Nein, automatisierte Überprüfungen decken nur einen Teil der Sicherheitsrisiken ab (z.B. XSS, SQL-Injection). Für Vollständigkeit ist auch ein manueller Audit erforderlich.

Reicht ein Scanner-Typ – SAST oder DAST – für einen wirksamen Schutz aus?

Nein, SAST analysiert den Code statisch vor dem Start der Anwendung, DAST das Verhalten der Anwendung während des Betriebs. Man muss beide verwenden und auch zusätzliche Methoden berücksichtigen.

Sollte man Sicherheitstests in CI/CD deaktivieren, um die Bereitstellung zu beschleunigen?

Nein, dieser Ansatz ist gefährlich – er gefährdet die Sicherheit des Produkts.

Typische Fehler und Anti-Patterns

Ignorieren von Scanner-Berichten (false-positive fatigue)
Fehlende Integration von manuellen und automatisierten Ansätzen
Automatisierung nur eines Teils des Sicherheitsprozesses

Beispiel aus der Praxis

Negativer Fall

Die Sicherheit wird nur durch manuelle Analysen in der Release-Phase überprüft, manchmal mit Hilfe von Scannern, die Berichte sind nicht in CI/CD integriert.

Vorteile:

„Live“-Audit komplexer Anfälligkeiten

Nachteile:

Entdeckung von Problemen in späteren Phasen
Hohe Kosten für Korrekturen

Positiver Fall

Sicherheitstests sind automatisiert in CI/CD bereitgestellt, kritische Anfälligkeiten blockieren die Veröffentlichung, Regeln zur Filterung von falschen Positiven sind konfiguriert, zusätzliche Pentest-Sitzungen alle drei Monate.