IAST – Interactive Application Security Testing

„Die Synthese aus SAST und DAST – oder: Wie man zwei mittelmäßige Dinge zu etwas Besserem kombiniert."

Sinn & Zweck

IAST ist das Kind, das SAST und DAST bekommen hätten, wenn sie sich vertragen hätten. Es kombiniert die Codekenntnis von SAST mit der Runtime-Perspektive von DAST – durch einen Agenten, der direkt in der Anwendung lebt.

Während SAST den Code analysiert und DAST von außen angreift, sitzt IAST in der Anwendung und beobachtet, was wirklich passiert, wenn Daten durch das System fließen. Wie ein Spion in der eigenen Organisation – nur dass dieser Spion für dich arbeitet.

Techniken

Instrumentierung

IAST injiziert Sensoren in die Anwendung:

Bei Java: Agent via -javaagent
Bei .NET: Profiler-API
Bei Node.js: Require-Hook oder native Module

Diese Sensoren beobachten jeden Datenzugriff, jeden HTTP-Request, jeden SQL-Query.

Runtime Taint Tracking

User Input → Validierung? → Sanitization? → Datenbank/Output
     ↓            ↓              ↓              ↓
   [IAST]      [IAST]         [IAST]        [IAST]
   "Tainted"   "Still?"      "Clean?"      "ALARM!"

IAST verfolgt "tainted" (potenziell gefährliche) Daten durch die gesamte Anwendung – und schlägt Alarm, wenn sie unsanitiert an gefährliche Stellen gelangen.

Code-Kontext-Korrelation

Wenn IAST eine Schwachstelle findet, zeigt es:

Die exakte Code-Zeile
Den HTTP-Request, der das Problem ausgelöst hat
Den kompletten Datenfluss
Stack Traces für alle Beteiligten

Methoden & Implementierung

Architektur

┌─────────────────────────────────────────────┐
│           Laufende Anwendung                │
│  ┌───────────────────────────────────────┐  │
│  │         IAST Agent                     │  │
│  │  • HTTP-Request-Interceptor            │  │
│  │  • SQL-Query-Monitor                   │  │
│  │  • File-I/O-Observer                   │  │
│  │  • Crypto-API-Watcher                  │  │
│  └───────────────────────────────────────┘  │
│                     ↓                        │
│              Findings & Telemetry            │
└─────────────────────────────────────────────┘
                      ↓
            ┌─────────────────┐
            │  IAST Backend   │
            │  (Dashboard)    │
            └─────────────────┘

Gängige Tools

Tool	Sprachen	Typ	Anmerkung
Contrast Security	Java, .NET, Node, Python, Go	Commercial	Marktführer, teuer, aber gut
Hdiv	Java, .NET	Commercial	Fokus auf Runtime Protection
Seeker (Synopsys)	Java, .NET, Node, Python	Commercial	Integration mit Coverity
Checkmarx IAST	Multi	Commercial	Teil der Checkmarx-Suite
OpenRASP	Java, PHP	Open Source	Von Baidu, limitiert aber kostenlos

Integration

// Java-Agent-Start
java -javaagent:/path/to/contrast-agent.jar \
     -Dcontrast.server.name=my-app \
     -jar my-application.jar

IAST funktioniert am besten während:

Funktionaler Tests
QA-Tests
Penetration Tests
Jeder anderen Aktivität, bei der die App benutzt wird

Risiken & Grenzen

Performance-Overhead

Der Agent braucht Ressourcen:

5-15% CPU-Overhead – spürbar
10-30% mehr Memory – manchmal mehr
Latenz-Erhöhung – bei jedem Request

In Production? Theoretisch möglich, praktisch... mutig.

Sprachabhängigkeit

Nicht jede Sprache wird unterstützt:

Java und .NET: Excellent
Node.js und Python: Gut
Go und Rust: Schwierig
PHP: Geht so
Exotisches: Vergiss es

Skalierungsprobleme

In Microservice-Architekturen:

Jeder Service braucht einen eigenen Agenten
Service-übergreifende Datenflüsse sind schwer zu tracken
Kubernetes + IAST = Konfigurationshölle

Abhängigkeit von Test-Coverage

IAST findet nur Probleme in Code-Pfaden, die auch ausgeführt werden. Keine Tests = keine Findings.

Vendor Lock-in

Einmal Contrast, immer Contrast. Die Migration zwischen IAST-Tools ist... nicht trivial.

Vorteile

Präzision statt Raten

IAST sieht den echten Datenfluss:

SAST: "Diese Zeile KÖNNTE unsicher sein" (60% Confidence)
DAST: "Irgendetwas hier ist kaputt" (keine Details)
IAST: "User-Input aus Parameter 'name' in Request POST /api/users 
       fließt unsanitiert in SQL-Query in UserRepository.java:42"

Minimale False Positives

Weil IAST den tatsächlichen Datenfluss sieht, gibt es kaum Fehlalarme. Wenn IAST sagt, es gibt ein Problem, dann gibt es ein Problem.

Entwicklerfreundliche Reports

Exakte Zeilennummern
HTTP-Request zum Reproduzieren
Stack Trace
Empfohlener Fix

Continuous Security

IAST läuft während der normalen QA-Tests – kein zusätzlicher Aufwand nötig.

Runtime-Kontext

Findet Probleme, die vom Deployment abhängen:

Fehlende Security-Header
Unsichere Cookie-Konfiguration
Aktivierte Debug-Endpoints

IAST vs. SAST vs. DAST

Aspekt	SAST	DAST	IAST
Quellcode-Zugriff	Ja	Nein	Ja (Runtime)
Runtime-Kontext	Nein	Ja	Ja
False Positives	Viele	Mittel	Wenige
False Negatives	Mittel	Viele	Wenige*
Performance-Impact	Build-Zeit	Keine	Runtime
Präzision	Mittel	Niedrig	Hoch

*Bei guter Test-Coverage

Best Practices

In QA integrieren – IAST braucht Traffic, also lass es während der QA-Tests laufen
Performance-Baselines erstellen – Wisse, wie viel Overhead der Agent verursacht
Nicht in Production – Es sei denn, du hast Performance-Budget und Nerven aus Stahl
Mit CI/CD verbinden – Findings sollten automatisch in Tickets landen
Test-Coverage erhöhen – Je mehr Code ausgeführt wird, desto mehr findet IAST
Developer-Training – IAST-Findings sind lehrreich, nutze sie für Security-Schulungen

Anwendungsfälle

Ideal für:

Teams mit guter Test-Coverage
Monolithische Anwendungen
QA-Umgebungen mit realistischem Traffic
Organisationen, die SAST + DAST satt haben

Weniger ideal für:

Microservice-Chaos
Exotische Programmiersprachen
Performance-kritische Systeme
Budget-bewusste Startups

Fazit

IAST ist wie ein Sicherheitsbeamter, der nicht nur die Kameras überwacht, sondern tatsächlich durch das Gebäude läuft und sieht, was passiert. Die Präzision ist unschlagbar, der Aufwand hält sich in Grenzen – aber du brauchst die richtige Infrastruktur und genug Test-Coverage.

Wenn dein IAST keine Findings produziert, hast du entweder die sicherste App der Welt – oder niemand testet.

Weiterführende Ressourcen: