Entdecken Sie das TÜV-zertifizierte GoogleTest mit Agentic AI für C/C++-Tests!
Details ansehen »
Zum Abschnitt springen
Parasoft-Blog
Hören Sie auf, Schwachstellen erst im Nachhinein zu beheben. Erfahren Sie, warum Prävention besser ist als Erkennung – und warum SAST IAST verbessert.
Zum Abschnitt springen
Wer sich lange genug mit Sicherheitstools beschäftigt, stößt irgendwann auf die Argumentation für IAST (Interactive Application Security Testing). Das Argument lautet in etwa so: SAST-Tools erzeugen zu viele Fehlalarme, Entwickler ignorieren die Ergebnisse, und bis diese schließlich auftauchen, ist die Behebung bereits kostspielig. Besser ist es, die laufende Anwendung zu instrumentieren und echte Schwachstellen während der Ausführung zu erkennen – mit weniger Fehlalarmen und besserem Kontext.
Diese Kritik ist nicht ganz unberechtigt. Ich habe SAST genau so eingesetzt gesehen, spät im Entwicklungszyklus als Tool zum Auffinden von Sicherheitslücken anstatt zur Codehärtung. Und genau so versagt es. Aber die Schlussfolgerung, dass IAST die grundlegenden Probleme von SAST umgeht, ist der Punkt, dem ich entschieden widersprechen würde.
Folgendes ist der Punkt: Der beschriebene Fehler ist ein Workflow-Problem, kein Werkzeugproblem. Und IAST hat selbst strukturelle Probleme.
Es benötigt einen Auslöser: eine Testsuite, einen DAST-Scanner, der Angriffsverkehr generiert, oder echte Benutzer in der Produktionsumgebung. Jemand muss die Anwendung instrumentieren. Die Analyse erfasst nur tatsächlich ausgeführten Code – unabhängig von der Quelle des Datenverkehrs. Bis etwas gefunden wird, ist der Code bereits kompiliert, integriert und bereitgestellt.
Und noch grundlegender: Sie können Ihren Weg zur Sicherung der Software nicht erkennen.Erkennung ist wichtig. Sie ist nicht ausreichend.
W. Edwards Demings berühmte Anweisung, „die Abhängigkeit von der Qualitätskontrolle zu beenden“, war kein Vorschlag, mit dem Testen aufzuhören. Sie war vielmehr eine Herausforderung für Organisationen, die die Endkontrolle an die Stelle des eigentlichen Qualitätsmanagements gesetzt hatten. Wer Fehler erst am Ende entdeckt, hat bereits im Vorfeld versagt. Die Kontrolle macht den Fehler lediglich sichtbar.
Der traditionelle Ansatz zur Softwarequalitätssicherung
Jede Disziplin, die Produkte herstellt, die funktionieren müssen, hat dies verinnerlicht. Man prüft die Qualität einer Brücke nicht erst, nachdem der Beton gegossen ist. Man verwendet die richtigen Materialien, befolgt die richtigen Verfahren und überprüft jede Phase, bevor man zur nächsten übergeht. Bei Softwaresicherheit ist es nicht anders. Oder zumindest sollte es nicht anders sein.
Sicherheit von Anfang an zu integrieren ist eine Disziplin. Unsicheren Code im Nachhinein zu entdecken, ist es nicht. Das sind grundverschiedene Entwicklungsaufgaben, und SAST ermöglicht erst die Integration von Sicherheit. Werden sie als austauschbar betrachtet, landet man bei einem Sicherheitsprogramm, das permanent reaktiv arbeitet – es löscht Brände, anstatt die Ursachen zu beheben.
IAST instrumentiert eine laufende Anwendung und meldet Schwachstellen, sobald der Code während Tests oder im Produktivbetrieb ausgeführt wird. Der Reiz liegt auf der Hand: die Bestätigung, dass eine Schwachstelle tatsächlich erreichbar ist, mit einem Laufzeitkontext, den statische Tools nicht liefern können. Doch die strukturelle Einschränkung ist ebenso real: IAST erfasst nur ausgeführten Code.
Die meisten Anwendungen erreichen durch ihre Testsuiten eine Codeabdeckung zwischen 40 % und 70 %. Dabei werden Codeabschnitte, die Grenzfälle, Fehlerzustände, Legacy-Funktionen und selten genutzte Administrationsschnittstellen abdecken, oft nicht getestet. Genau diese Bereiche, die Angreifer systematisch untersuchen, bleiben bei Testläufen häufig unberührt.
Dahinter verbirgt sich ein tieferliegendes Problem. Diejenigen, die Testsuiten schreiben, sind in der Regel keine Sicherheitstester, und Sicherheitstester schreiben üblicherweise keine Unit-Tests.
Standardmäßige Qualitätssicherung bildet das Verhalten von Angreifern nicht ab. Und diejenigen, die das Verhalten von Angreifern modellieren, sind in der Regel nicht für die Entwicklung der Testumgebung zuständig, auf der IAST basiert.
IAST liefert ein präzises Bild der Schwachstellen im getesteten Code. Über den nicht getesteten Code erhält man hingegen keinerlei Informationen. Man reduziert zwar die Anzahl falsch positiver Ergebnisse, erhöht aber die Anzahl falsch negativer Ergebnisse. Der Vorteil falsch negativer Ergebnisse liegt darin, dass sie nicht störend sind. Der Nachteil ist, dass man ihren Zeitpunkt nicht erkennt.
Hinzu kommt ein praktischer Mehraufwand, der oft unberücksichtigt bleibt. Alle IAST-Tools benötigen eine Steuerung für die Ausführung:
Manche Tools können jede dieser Möglichkeiten nutzen. Keines von ihnen kann Code analysieren, der von keinem Tool getestet wird.
Jemand muss die Anwendung instrumentieren, diese Instrumentierung bei Codeänderungen aufrechterhalten und sicherstellen, dass der Auslöser der Analyse einen ausreichend großen Teil der Angriffsfläche abdeckt, um aussagekräftige Ergebnisse zu liefern. Je komplexer der Auslöser, desto höher der erforderliche operative Aufwand. Die Abdeckung ist stets proportional zu dem, was sie verursacht.
Und dann ist da noch der Kostenaspekt. Bis IAST läuft, ist der Code geschrieben, integriert und mindestens in einer Testumgebung – und oft auch in der Staging- oder Produktionsumgebung – bereitgestellt.
Die meisten IAST-Implementierungen erfolgen in der Qualitätssicherung oder in Staging-Umgebungen, wo sie auch in unserer Grafik verortet sind. Einige Anbieter bewerben die Implementierung in der Produktionsumgebung explizit. Unabhängig vom Einsatzort ist der Code bereits vorhanden, und der Entwicklungskontext, in dem er entstanden ist, verliert zunehmend an Bedeutung. Laut dem IBM/Ponemon Institute-Bericht „Cost of a Data Breach 2024“ belaufen sich die durchschnittlichen Kosten einer Datenschutzverletzung weltweit auf 4.88 Millionen US-Dollar – ein Rekordwert.
Die Kosten summieren sich jedoch schon lange vor Produktionsbeginn. Derselbe Fehler ist in der Qualitätssicherung deutlich teurer zu beheben als in der Entwicklungsumgebung und in der Staging- oder Produktionsumgebung wiederum deutlich teurer als in der Qualitätssicherung.
Die relativen Kosten für die Behebung eines Sicherheitsfehlers steigen in jeder Phase des Softwareentwicklungszyklus (SDLC) stark an. IAST kommt typischerweise in der Testphase zum Einsatz, in der die Kosten bereits deutlich über den Kosten der Codierungsphase liegen.
Manche IAST-Implementierungen beschränken sich nicht auf die Testumgebung. Einige Anbieter vermarkten explizit produktionsreife IAST-Lösungen, bei denen Agenten kontinuierlich in Live-Systemen laufen und Schwachstellen melden, während der Code unter realem Datenverkehr getestet wird.
Der Reiz liegt auf der Hand: reale Angriffsfläche, reale Nutzungsmuster, reale Umgebung.
Doch bedenken Sie, was die Erkennung des Fehlers in der Produktionsumgebung konkret für die Behebung bedeutet. Der Code ist im Einsatz und die Benutzer verlassen sich darauf. Eine Fehlerbehebung erfordert, den gesamten Entwicklungsprozess – von der Entwicklung über das Testen und die Staging-Umgebung bis hin zur erneuten Bereitstellung – in einer Software durchzuführen, die sich seit der Veröffentlichung der anfälligen Version möglicherweise erheblich verändert hat.
Der Entwickler, der den Code geschrieben hat, arbeitet möglicherweise in einem anderen Sprint, an einem anderen Projekt oder sogar in einem anderen Unternehmen. Die Rekonstruktion des Kontextes, der für eine korrekte Fehlerbehebung notwendig ist, ist aufwendig. Und in der Praxis geschieht dies oft nicht.
Es ist erschreckend häufig, dass spät entdeckte Sicherheitslücken mit Kommentaren wie „Der Code hat sich seit der Meldung erheblich verändert“ oder „In meiner Umgebung nicht reproduzierbar“ geschlossen werden. Das sind keine Behebungen, sondern nur als Lösungen getarnte Aufschübe. Die Zeit bis zur Ausnutzung läuft ununterbrochen.
Das Uber-Datenleck 2022 Dies verdeutlicht ein ähnliches Problem. Angreifer, die sich Netzwerkzugriff verschafft hatten, entdeckten ein PowerShell-Skript mit fest codierten Administratoranmeldeinformationen für das Privileged Access Management-System von Uber. Mit diesen Anmeldeinformationen konnten AWS, GCP, Google Drive, Slack und SentinelOne entsperrt werden.
Die Ursache lag in einer Programmierpraxis: Geheimnisse waren fest im Quellcode verankert, sodass kein Laufzeittool sie jemals erkennen würde. IAST überwacht laufende Anwendungen. Ein in einem Skript gespeicherter Zugangscode wird bei einem Testlauf nicht ausgeführt. SAST hingegen, das den Quellcode liest, würde ihn bereits beim Schreiben erkennen.
IAST im Produktivbetrieb ist ein Sicherheitsnetz. Ein nützliches. Ziel ist es jedoch, es so selten wie möglich zu benötigen. Dies lässt sich erreichen, indem man die Entstehung von Sicherheitslücken von vornherein verhindert.
Bei einem Großteil der heute entwickelten Software geht es nicht mehr nur darum, Sicherheitslücken zu finden. Es geht vielmehr darum, die Einhaltung von Standards nachzuweisen, die bestimmte Programmierpraktiken vorschreiben.
All dies erfordert die Einhaltung von Codierungsregeln, die den Quellcode selbst regeln.
IAST kann Ihnen nicht sagen, ob Ihr C-Quellcode die von MISRA verbotenen Sprachkonstrukte vermeidet. Es kann die CERT-Codierungsstandards nicht durchsetzen. Es kann nicht die von Auditoren und Zertifizierungsstellen geforderten Nachweise erstellen. Diese Eigenschaften sind im Quellcode vorhanden oder nicht. Nur eine statische Quellcodeanalyse kann sie verifizieren. Diese Lücke lässt sich nicht durch eine verbesserte Instrumentierung schließen.
Hinzu kommt eine grundlegendere Sprachbarriere.
IAST funktioniert, indem Agenten in verwaltete Laufzeitumgebungen eingebettet werden, die JVM für Java, die CLR für .NET und ähnliche Plattformen.
C, C++, Rust und Ada, die Sprachen, die die Entwicklung sicherheitskritischer eingebetteter Systeme dominieren, verfügen nicht über ein solches Instrumentierungsmodell.
Es gibt keinen IAST-Agenten für Bare-Metal-C, das auf einem Kfz-Steuergerät läuft, keine instrumentierte Laufzeitumgebung für Ada in einem Avioniksystem und keine sinnvolle IAST-Abdeckung für die Rust-Codebasen, die US-Regierungsbehörden jetzt aktiv für die Entwicklung speichersicherer Systeme fördern.
Für diese Sprachen und Domänen ist IAST keine suboptimale Wahl. Es ist schlichtweg keine praktikable.
Auch die praktische Performance-Dimension sollte berücksichtigt werden. IAST-Instrumentierung verursacht messbaren Laufzeit-Overhead in Bezug auf CPU, Speicher und Latenz. Wie hoch dieser Overhead ist, variiert enorm je nach Tool, Anwendung, Workload und dem zu überwachenden Parameter.
Die Ergebnisse können variieren, in manchen Fällen sogar um eine Größenordnung. Bei Echtzeitsystemen oder leistungsbeschränkten eingebetteten Umgebungen schließt diese Variabilität allein die Laufzeitinstrumentierung als primäre Sicherheitsstrategie aus, unabhängig von Argumenten zur Abdeckung.
In sicherheitskritischen Systemen ist das Problem falsch negativer Ergebnisse keine Unannehmlichkeit, sondern eine notwendige Konstruktionsvoraussetzung.
Wenn Softwarefehler physische Folgen haben, geht es nicht nur darum, ob Ihr Sicherheitstool Schwachstellen findet. Es geht darum, ob Sie nachweisen können, dass es keine übersehen hat.
IAST kann diese Sicherheit strukturell nicht bieten. Es deckt nur Code ab, der von Testern ausgeführt wurde, die während eines Testlaufs, der die Grenzfälle, in denen Fehler tatsächlich auftreten, nicht simulierten, kein Angreiferverhalten simulierten.
Das ist kein Problem der Werkzeugkonfiguration, sondern eine architektonische Einschränkung. Die einzige Methode, die eine systematische Abdeckung der gesamten Codebasis mit dokumentierten Regelsätzen und nachvollziehbaren Nachweisen ermöglicht, ist die statische Quellcodeanalyse.
Sicherheitskritische Software wird nicht auf Korrektheit getestet. Sie wird von vornherein darauf ausgelegt, wobei die Analyse von der ersten Codezeile an erfolgt. Die statischen Analysetools von Parasoft, C / C ++ - TestJtest und dotTEST decken die wichtigsten Standards für C, C++, Java, C# und VB.NET ab, darunter MISRA, AUTOSAR, CERT, CWE, OWASP Top 10, OWASP API Top 10 und DISA ASD STIG.
Für Teams in regulierten Branchen ist „nutzen Sie stattdessen IAST“ keine Alternative. Es ist keine Antwort.
Dig Deeper
Entdecken Sie unsere Leitfaden zur statischen Codeanalyse »
Nichts davon ist ein Argument gegen IAST. Wenn Sie Anwendungen entwickeln, bei denen Laufzeittests praktikabel sind, stellt es eine wirklich nützliche Ebene dar. Es bestätigt die Vorhersagen der statischen Analyse und deckt Probleme auf, die bei der statischen Analyse übersehen werden, insbesondere Schwachstellen, die sich erst durch spezifische Laufzeitinteraktionen mit Servern, Datenbanken oder Drittanbieterdiensten manifestieren.
Die richtige Reaktion auf einen von IAST gemeldeten Fehler besteht nicht nur darin, die betroffene Instanz zu beheben. Die Instanz reparieren? Ja. Aber anschließend muss die Ursache des Fehlers ermittelt und beseitigt werden. Dies sind zwei separate Schritte.
Der Patch behebt die unmittelbare Sicherheitslücke. Die Ursachenanalyse und die daraus resultierenden Codierungsstandards, Validierungsmuster oder statischen Analysen beseitigen die gesamte Problemklasse.
Der eigentliche Hebel liegt im zweiten Schritt. Wenn eine Sicherheitslücke auftritt, lautet die richtige Frage für die Entwickler nicht: „Wie behebe ich das?“, sondern: „Wo im Quellcode verbirgt sich derselbe Fehler noch?“
Diese Frage hören wir immer wieder von Entwicklern und Sicherheitsteams, die das Problem richtig angehen. Ein einzelner IAST-Befund, der richtig behandelt wird, kann die Rechtfertigung dafür liefern, einen zuvor nicht verwendeten Checker zu aktivieren oder einen benutzerdefinierten Checker zu schreiben, der speziell auf das soeben gefundene Muster abzielt.
Parasoft unterstützt beides:
Die zur Laufzeit gewonnenen Erkenntnisse dienen als Grundlage für die Festlegung der statischen Analysekonfiguration. Dies ist der Feedback-Mechanismus, der die eigentliche Veränderung bewirkt.
Wenn SAST gut funktioniert, gelangen weniger Schwachstellen in die Builds, weniger erreichen die Integration und weniger gelangen in die Umgebungen, in denen IAST ausgeführt wird.
Die Ergebnisse der IAST-Untersuchung werden aussagekräftiger und weniger rauschbehaftet.
Das Team verbringt weniger Zeit mit der Priorisierung und mehr Zeit mit der Auslieferung. Die Tools stehen nicht in Konkurrenz zueinander. Sie arbeiten sequenziell: Prävention im Vorfeld, Bestätigung im Nachgang.
Es gibt eine Frage, die es wert ist, aufgeworfen zu werden, die bisher nicht genügend Aufmerksamkeit erhält.
Was geschieht mit den strukturellen Herausforderungen von IAST, wenn KI-Codierungsagenten beginnen, signifikante Teile der Codebasis zu generieren?
KI-Agenten erzeugen schnell und in großen Mengen Code. Sie erzeugen aber auch charakteristische Fehlermuster:
Das sind keine Tippfehler. Es sind strukturelle Probleme, die von einem Agenten herrühren, der gelernt hat, Code zu erzeugen, der kompiliert und grundlegende Tests besteht, ohne die Gründe für die Sicherheitsbeschränkungen verinnerlicht zu haben.
IAST benötigt Code, der bereitgestellt, instrumentiert und getestet wird, bevor es etwas finden kann.
Mit zunehmender Menge an KI-generiertem Code gewinnen die bereits bestehenden strukturellen Beschränkungen an Bedeutung.
Die statische Analyse hingegen kann direkt in den KI-Codierungszyklus integriert werden und analysiert jede generierte Datei zum Zeitpunkt ihrer Erstellung, bevor sie gespeichert wird.
Mit der zunehmenden Verbreitung von KI-gestützten Codierungsagenten gewinnt die statische Codeanalyse als Kontrollinstanz in diesem Prozess an Bedeutung. Das zugrundeliegende Prinzip ist einfach: Die statische Analyse interessiert sich nicht dafür, wer den Code geschrieben hat.
Im Idealfall wäre KI-generierter Code fehlerfrei, gut strukturiert und frei von Sicherheitslücken. Doch so weit sind wir noch nicht. KI-Programmierer erzeugen bereits heute echte Sicherheitslücken.
Manchmal handelt es sich um dieselben Arten von Fehlern, die auch von menschlichen Entwicklern verursacht werden. Manchmal treten neue Fehler auf, die charakteristisch für die Art und Weise sind, wie Modelle Code generieren.
Die Antwort ist unabhängig von der Quelle dieselbe. Führen Sie eine statische Analyse aller Änderungen durch, jedes Commits, egal ob von einem Menschen oder einer Maschine.
Die besondere Stärke dieser Lösung im Parasoft-Kontext liegt darin, dass die Behebung von Verstößen Compliance-konform erfolgen kann und nicht nur generell korrekt ist. Es genügt nicht, einen Verstoß so zu beheben, dass der Code zufällig kompiliert.
Für Codebasen, die unter MISRA, AUTOSAR oder anderen Standards arbeiten, ist eine Korrektur, die einen anderen Verstoß gegen denselben Standard verursacht oder ein Problem durch ein anderes ersetzt, keine wirkliche Lösung. Der Code-Fix-Agent von Parasoft setzt genau hier an. Er behebt festgestellte Fehler im Kontext des jeweiligen Standards und führt anschließend eine erneute Analyse durch, um zu überprüfen, ob die Korrektur tatsächlich die Konformität herstellt und nicht nur die beanstandete Zeile entfernt. Ziel ist Code, der nicht nur geändert, sondern nachweislich konform ist.
Parasoft hat hierzu eigene Forschungsergebnisse veröffentlicht. Ein technisches Whitepaper, das Parasoft C/C++test mit GitHub Copilot vergleicht, bewertete automatisierte Korrekturen für CWE-Verstöße in 1,856 Open-Source-C/C++-Projekten.
Die Compliance-orientierten Eingabeaufforderungen von Parasoft, die eine Regeldokumentation und eine nachvollziehbare Gedankenkette beinhalten, waren dem generischen Fix-Befehl von GitHub Copilot in 64 % der Fälle mit und in 57 % der Fälle ohne logische Schlussfolgerungen überlegen.
Die manuelle Überprüfung bestätigte, dass die Korrekturen von Parasoft umfassender, robuster und konsequenter den Codierungsstandards entsprechend waren. Der Unterschied liegt nicht nur darin, welches Tool mehr Verstöße findet, sondern auch darin, welches Tool versteht, wie eine korrekte Korrektur im jeweiligen Compliance-Kontext aussieht.
Die Softwareindustrie versucht seit Jahrzehnten, die Qualität erst am Ende zu testen. Liste schwerwiegender Softwarefehler ist lang genug, um den Punkt für sich allein zu verdeutlichen. Sicherheit folgt dem gleichen Muster:
Das ist kein Sicherheitsprogramm. Das ist ein Laufband.
Die Teams, die ihre Sicherheitslage tatsächlich verbessern, sind nicht diejenigen mit den besten Erkennungswerkzeugen. Sie sind diejenigen, die von vornherein in besseren Code investieren, indem sie Standards durchsetzen und statische Analysen integrieren, die den Code beeinflussen können, solange der Entwickler noch den Kontext hat, um Fehler zu beheben. Demings Aussage war nicht, dass Inspektion wertlos sei. Er sagte vielmehr, dass man bereits verloren hat, wenn Inspektion die primäre Qualitätsstrategie ist.
IAST ist ein nützliches Instrument auf dem Laufband. Das Ziel ist es, vom Laufband abzusteigen.
Qualität von Anfang an einbauen. Zur Laufzeit überprüfen. Und lassen Sie sich nicht einreden, dass die Erkennung von Problemen am Ende deren Vermeidung von vornherein ersetzt.
SAST (Static Application Security Testing) analysiert Quellcode, ohne ihn auszuführen, und findet Schwachstellen bereits beim Codieren. IAST (Interactive Application Security Testing) instrumentiert eine laufende Anwendung und erkennt Schwachstellen während der Codeausführung im Test- oder Produktivbetrieb. SAST deckt Probleme auf, bevor sie veröffentlicht werden. IAST findet Probleme in bereits ausgeführtem Code. Beide Verfahren decken reale Probleme auf. Nur SAST kann verhindern, dass diese überhaupt erst entstehen.
Nein. IAST analysiert nur tatsächlich ausgeführten Code, wodurch große Teile der meisten Codebasen unerforscht bleiben. Es erfordert eine Testsuite für die Analyse und operativen Aufwand für Instrumentierung und Wartung. Die Einhaltung von Codierungsstandards wie MISRA, CERT oder OWASP kann nicht überprüft werden. Und Schwachstellen können erst erkannt werden, nachdem der Code bereits geschrieben, kompiliert und bereitgestellt wurde – ein Zeitpunkt, an dem die Behebung deutlich teurer ist.
IAST ist besonders wertvoll als ergänzende Ebene zu SAST in Programmen zur Anwendungssicherheit, in denen Laufzeittests praktikabel sind und bereits eine ausgereifte Testsuite existiert. Es liefert nützliche Bestätigungen für die tatsächliche Ausnutzbarkeit und deckt Schwachstellen auf, die sich nur durch Serverinteraktionen zur Laufzeit manifestieren. Es eignet sich nicht als primäre oder alleinige Strategie und bietet keinen Mehrwert für Codebasen, die den Nachweis der Quellcodekonformität mit Standards wie MISRA oder CERT erfordern.
Parasoft konzentriert sich auf SAST und Tests, nicht auf IAST. Statische Analysewerkzeuge von Parasoft Umfasst C, C++, Java, C# und VB.NET mit umfassenden Regelsätzen für Sicherheits- und Compliance-Standards.
Welche SAST-Lösung ist die richtige für Ihr Team?
