Intraprozedurale vs. interprozedurale Analyse: Warum der Unterschied die Ergebnisse bestimmt

Führt man ESLint auf einer JavaScript-Datei mit einer SQL-Injection-Schwachstelle aus, wird der Test ohne Beanstandungen bestanden. Wendet man CodeQL auf dieselbe Codebasis an, markiert es die Injection mit Angabe der exakten Datei, Zeile und des Datenflusspfads. Beide sind statische Analysetools. Beide untersuchen denselben Quellcode, ohne ihn auszuführen. Der Unterschied in den Ergebnissen liegt nicht in der Regelkonfiguration oder der Sprachunterstützung, sondern in einem grundlegenden Unterschied in der Analysemethode. ESLint untersucht jeweils eine Funktion und meldet die gefundenen Schwachstellen innerhalb dieser Grenzen. CodeQL verfolgt die Daten durch Funktionsaufrufe, über Module hinweg und durch den gesamten Aufrufgraphen, bis es auf eine gefährliche Stelle stößt.

Diese Unterscheidung zwischen intra- und interprozeduraler Analyse ist das wichtigste technische Konzept, um zu verstehen, warum verschiedene statische Analysetools unterschiedliche Ergebnisse liefern. Sie erklärt, warum ein Linter einem Code einwandfreie Ergebnisse bescheinigen kann, während ein komplexeres Tool kritische Sicherheitslücken im selben Code aufdeckt. Sie erklärt, warum Sicherheits-SAST-Tools ressourcenintensiv sind. Sie erklärt, warum die Rate falsch negativer Ergebnisse bei „schnellen“ Tools strukturell höher ist als bei „langsamen“. Und genau dieses Konzept müssen Unternehmen verstehen, bevor sie eine statische Analysetoolchain evaluieren.

Was ist intraprozedurale Analyse?

Die intraprozedurale Analyse untersucht, was innerhalb einer einzelnen Funktion, Methode oder Prozedur geschieht, ohne zu berücksichtigen, was passiert, wenn diese Funktion andere Funktionen aufruft oder von ihnen aufgerufen wird. Die Analysegrenze ist die Funktionsgrenze. Sobald ein intraprozedurales Werkzeug auf einen Funktionsaufruf stößt, stoppt es; es verfolgt den Aufruf nicht bis zur aufgerufenen Funktion und weiß daher nicht, wie diese die empfangenen Daten verarbeitet.

Die klassischen Beispiele für intraprozedurale Analysen sind Linting und die Analyse des grundlegenden Datenflusses innerhalb einer einzelnen Funktion:

python

def process_input(user_data):
    # Intraprocedural analysis sees: user_data used here
    query = "SELECT * FROM users WHERE id = " + user_data  # flagged: string concat in SQL
    return query

Eine einfache Regel, die Stringverkettungen in SQL-Abfragen kennzeichnet, funktioniert innerhalb einer einzelnen Funktion, da das gefährliche Muster sichtbar ist. Ändern Sie jedoch die Codestruktur geringfügig:

python

def get_user_id(request):
    return request.args.get("id")  # untrusted input

def build_query(user_id):
    return "SELECT * FROM users WHERE id = " + user_id  # looks safe in isolation

def handle_request(request):
    uid = get_user_id(request)
    query = build_query(uid)    # vulnerability spans three functions
    db.execute(query)

Nun zur Quelle der verfälschten Daten (request.args.get("id")) hat eine andere Funktion als das gefährliche Waschbecken (db.execute(query)Keine einzelne Funktion enthält genügend Informationen, damit ein intraprozedurales Tool die Schwachstelle erkennen kann. get_user_id Sieht gut aus, es liest einfach nur eine Anfrage aus. build_query Sieht gut aus, es nimmt einen Parameter entgegen und erstellt eine Zeichenkette. handle_request Es sieht gut aus, es ruft Funktionen auf und führt eine Abfrage aus. Die SQL-Injection ist real, ausnutzbar und für jedes Tool unsichtbar, das keine Funktionsgrenzen überschreitet.

Wofür ist die intraprozedurale Analyse gut?

Intraprozedurale Tools sind schnell. Sehr schnell. Da sie jede Funktion unabhängig analysieren, skalieren sie linear mit der Codebasisgröße; die Analyse einer Codebasis mit einer Million Zeilen kostet proportional genauso viel wie die Analyse einer Codebasis mit zehntausend Zeilen. Diese Geschwindigkeit macht sie ideal für:

• Pre-Commit-Hooks das in weniger als einer Sekunde läuft
• Inline-Feedback der IDE während ein Entwickler tippt
• CI/CD-Qualitätsgates bei jedem Pull Request
• Stil- und Konventionsdurchsetzung (Benennung, Formatierung, Komplexitätsmetriken)
• Missbrauch lokaler Variablen (unbenutzte Variablen, undefinierte Referenzen, offensichtliche Typfehler)
• Zyklomatische Komplexität und Methodenlängerein intra-funktionale Metriken

Zu dieser Kategorie gehören Werkzeuge wie ESLint, Pylint, Clippy (Rust), golangci-lint, Checkstyle und die meisten Linter. Sie sind für die Art von Problemen, die sie erkennen können, unverzichtbar und wertvoll. Ihre Einschränkung ist struktureller Natur, kein Qualitätsmangel.

Was ist eine interprozedurale Analyse?

Die interprozedurale (programmweite) Analyse ist in der Regel die leistungsstärkste, aber auch die ressourcenintensivste Methode. Sie erweitert Kontrollflussgraphen um Funktionsaufruf- und Rückgabekanten aus einem Aufrufgraphen. Durch die Erstellung von Funktionszusammenfassungen kann die Analyse vermeiden, dieselben Funktionen wiederholt aufzurufen.

Während die intraprozedurale Analyse an Funktionsgrenzen endet, überschreitet die interprozedurale Analyse diese. Sie erstellt einen Aufrufgraphen, der darstellt, welche Funktionen welche anderen aufrufen, und verfolgt anschließend Datenfluss, Kontrollfluss oder Datenverfälschungen entlang der Kanten dieses Graphen. Trifft ein interprozedurales Werkzeug auf einen Funktionsaufruf, folgt es diesem bis zur aufgerufenen Funktion oder verwendet eine vorab berechnete Zusammenfassung des Verhaltens der aufgerufenen Funktion und setzt die Analyse auf der anderen Seite fort.

Die drei oben genannten SQL-Injection-Funktionen sind ein einfaches Beispiel. Reale interprozedurale Analysen behandeln Folgendes:

• Datenfluss über mehrere Hops: Nicht vertrauenswürdige Eingabe, die fünf Funktionen durchläuft, bevor sie eine gefährliche Senke erreicht.
• RückgabewertverunreinigungEine Funktion gibt fehlerhafte Daten zurück; Aufrufer verwenden diesen fehlerhaften Rückgabewert in unsicheren Operationen.
• Feldempfindliche Verunreinigung: Nicht vertrauenswürdige Daten, die in einem Objektfeld gespeichert und später in einer anderen Funktion abgerufen werden
• Bedingte Ausbreitung: Taint-Flüsse erfolgen nur entlang bestimmter Ausführungspfade, abhängig von Laufzeitbedingungen, die die Analyse statisch modellieren muss

Java

// Interprocedural vulnerability: three-hop taint flow
public class UserController {
    public String handleRequest(HttpServletRequest request) {
        String userId = request.getParameter("id");    // source: untrusted input
        User user = userService.getUser(userId);       // taint flows through call
        return generateReport(user);                   // taint reaches sink
    }
}

public class UserService {
    public User getUser(String id) {
        // id is tainted -- passed to repository
        return userRepository.findByRawId(id);         // taint propagates
    }
}

public class UserRepository {
    public User findByRawId(String id) {
        String query = "SELECT * FROM users WHERE id = " + id;  // sink: SQL injection
        return db.execute(query);
    }
}

Ein intraprozedurales Instrument zur Untersuchung UserRepository.findByRawId isoliert betrachtet wird ein Parameter id in eine SQL-Abfrage verkettet. Das sieht potenziell unsicher aus, aber das Tool hat keine Möglichkeit zu wissen, wo id Die Daten stammen möglicherweise von einem vertrauenswürdigen, validierten Wert aus internem Code. Ein intraprozedurales Tool kennzeichnet sie entweder als potenzielles Problem (und erzeugt damit Fehlalarme bei jeder parametrisierten, aber strukturierten Abfrage im Code) oder ignoriert sie (und erzeugt damit Fehlalarme bei tatsächlichen Schwachstellen). Die interprozedurale Dateninventaranalyse erkennt, ob nicht vertrauenswürdige Daten über Funktionen zu sensiblen Operationen fließen. Sie verfolgt die Daten von request.getParameter("id") - durch Konsolidierung, userService.getUser()Durch userRepository.findByRawId()bis hin zu db.execute(query), wodurch ein präzises Ergebnis mit dem genauen Pfad der Schadstoffbelastung erzielt wird, ohne falsch positive oder falsch negative Ergebnisse.

Die drei Analyseebenen: Ein praktisches Spektrum

Statische Analysewerkzeuge in der Praxis lassen sich auf einem Spektrum von rein intraprozedural bis vollständig interprozedural einordnen. Das Verständnis der jeweiligen Position jedes Werkzeugs erklärt sowohl, was es findet als auch, was es übersieht.

Analyseebene	Geltungsbereich	Was es sieht	Was es fehlt	Zubehör
Lexikalisch / syntaktisch	Einzelne Token und Syntax	Formatierung, Benennung, grundlegende Syntax	Alles Semantische	Prettier, rustfmt, gofmt
Intraprozedural	Einzelfunktion	Lokaler Datenfluss, Komplexität, Kontrollfluss innerhalb der Funktion	Funktionsübergreifende Schwachstellen, Architekturprobleme	ESLint, Pylint, Clippy, golangci-lint
Flache interprozedurale	Eine Anruftiefe	Direkte Anrufer-Angerufene-Beziehungen	Tiefe Multi-Hop-Flows	Einige Semgrep-Regeln, grundlegende SAST-Regeln
Vollständige interprozedurale	Vollständige Aufrufgraphendurchquerung	Multi-Hop-Taint-Flows, kontextsensitive Analyse	Laufzeitpolymorphismus (partiell), reflektierende Aufrufe	CodeQL, Facebook Infer, SMART TS XL
Gesamtprogramm / semantisch	Vollständige Programmsemantik	Formal beweisbare Eigenschaften	Skalierbarkeit bei sehr großen Codebasen	Infer, Kani (Rust), formale Verifikationswerkzeuge

Die interprozedurale Analyse bietet ein relativ hohes Effizienzpotenzial, jedoch ein vergleichsweise geringes Leistungspotenzial. Dank des umfangreichen Programmmodells ist sie zudem weniger anfällig für falsch-negative und falsch-positive Ergebnisse und weist eine relativ höhere Effizienz auf. Aufgrund ihrer Leistungsbegrenzung, die die Entwicklungsgeschwindigkeit verringern kann, eignet sich die interprozedurale Analyse nicht optimal für CI/CD-Umgebungen. Daher wird sie häufig als dedizierter Dienst bereitgestellt, der auf Serverfarmen oder mit speziellen Tools ausgeführt wird.

Wie die interprozedurale Analyse funktioniert: Drei Schlüsselansätze

1. Zusammenfassungsbasierte Analyse

Die Analyse kann die wiederholte Untersuchung derselben Funktionen vermeiden, indem sie Funktionszusammenfassungen (manchmal auch Modelle genannt) erstellt. Eine Zusammenfassung beschreibt das Verhalten einer Funktion kompakt: Bei gegebenen Eingaben mit bestimmten Eigenschaften erzeugt die Funktion diese Ausgaben mit bestimmten Eigenschaften. Wenn ein Aufrufer die Funktion aufruft, instanziiert die Analyse die Zusammenfassung, anstatt den Funktionskörper von Grund auf neu zu analysieren.

Zusammenfassungsbasierte Analysen ermöglichen die effiziente Durchführung von prozedurübergreifenden Analysen in großem Umfang. Ohne Zusammenfassungen müsste die gesamte Bibliothek, einschließlich aller von ihr aufgerufenen Funktionen, rekursiv vom Quellcode an analysiert werden, um eine Funktion zu analysieren, die eine Bibliothek aufruft. Mit Zusammenfassungen werden Bibliotheksfunktionen einmalig voranalysiert und ihre Zusammenfassungen bei jedem Aufruf wiederverwendet.

2. Aufrufstring-Ansatz (kontextsensitive Analyse)

Die kontextsensitive Analyse unterscheidet zwischen verschiedenen Aufrufstellen derselben Funktion. Wenn sanitize(input) Wird an einem Ort mit vertrauenswürdigen und an einem anderen mit nicht vertrauenswürdigen Daten aufgerufen, liefert eine kontextsensitive Analyse für jeden Aufrufort unterschiedliche Ergebnisse, anstatt vorsichtshalber vom schlimmsten Fall für alle auszugehen. Dadurch werden falsch-positive Ergebnisse im Vergleich zu einer kontextunsensitiven Analyse deutlich reduziert.

Das IFDS-Framework (Interprozedural, Finite, Distributive, Subset) formalisiert dies als ein Graph-Erreichbarkeitsproblem. Im IFDS-Framework wird der Fluss von Datenveränderungen durch distributive Funktionen über einem endlichen Faktenbereich beschrieben, und die interprozedurale Propagation wird auf die Graph-Erreichbarkeit reduziert. Diese Formulierung macht IFDS-Analysen sowohl präzise als auch algorithmisch effizient; Tools wie FlowDroid (für Android) und diverse CodeQL-Abfragen nutzen IFDS intern.

3. Erstellung des Anrufdiagramms

Jede interprozedurale Analyse erfordert einen Aufrufgraphen: einen gerichteten Graphen, in dem die Knoten Funktionen und die Kanten Aufrufe darstellen. Der Aufbau des Aufrufgraphen selbst erfordert knifflige Entscheidungen:

Statische Dispatcher (Java-Aufrufe ohne virtuelle Schnittstellen, C-Funktionsaufrufe, Python-Modulaufrufe): einfach zu modellieren, f() Anrufe f.

Dynamischer Versand (Java virtuelle Methoden, Python Duck-Typ-Aufrufe): erfordert eine Klassenhierarchieanalyse (CHA) oder präzisere Algorithmen zur Konstruktion von Aufrufgraphen (RTA, VTA), um zu bestimmen, welche Implementierungen einer Methode an einer gegebenen Aufrufstelle tatsächlich aufgerufen werden könnten.

Reflektierende Anrufe und Funktionszeiger: die schwierigsten Fälle. Die Tools müssen entweder überapproximieren (annehmen, dass jede passende Funktion aufgerufen werden könnte, was zu falsch positiven Ergebnissen führt) oder unterapproximieren (einige Aufrufpfade auslassen, was zu falsch negativen Ergebnissen führt).

Die Genauigkeit des Aufrufdiagramms bestimmt direkt die Genauigkeit der prozedurübergreifenden Analyse. Ein Aufrufdiagramm mit zu vielen Kanten (Überapproximation) führt zu falsch positiven Ergebnissen; eines, das Kanten auslässt, zu falsch negativen Ergebnissen.

Was die interprozedurale Analyse feststellt, was die intraprozedurale Analyse nicht feststellen kann

Sicherheitslücken (Taint-Analyse)

Die meisten der OWASP Top 10-Schwachstellen erfordern eine interprozedurale Taint-Analyse, um zuverlässig erkannt zu werden:

• SQL-Injection: Nicht vertrauenswürdige Eingaben durchlaufen mehrere Funktionen und werden schließlich in einer Datenbankabfrage verarbeitet.
• XSSNicht vertrauenswürdiges HTML durchläuft Rendering-Funktionen und gelangt in einen Ausgabekontext.
• Befehlsinjektion: Benutzergesteuerte Daten erreichen exec() or system() über zwischengeschaltete Funktionen
• Pfaddurchquerung: Aus Benutzereingaben abgeleitete Dateipfade erreichen Dateisystemoperationen
• SSRF: Vom Benutzer gesteuerte URLs fließen zu HTTP-Client-Aufrufen

python

# Intraprocedural tool: sees no issue in any individual function
# Interprocedural tool: traces the full taint path and reports SSRF

def get_target_url(request):
    return request.json().get("url")              # source: attacker-controlled

def fetch_resource(url):
    return requests.get(url)                      # sink: SSRF

def api_endpoint(request):
    target = get_target_url(request)
    data = fetch_resource(target)                 # full path: source -> sink
    return data

Nullzeiger- und Speichersicherheitsprobleme

Facebook Infer ist das Standardwerkzeug für die interprozedurale Nullsicherheitsanalyse. Es verwendet Bi-Abduktion, eine Form des interprozeduralen Schließens, um Vor- und Nachbedingungen von Funktionen zu ermitteln und anschließend zu prüfen, ob die Aufrufer diese Vorbedingungen erfüllen. Eine Nulldereferenzierung, die das Wissen voraussetzt, dass eine Funktion unter bestimmten Bedingungen null zurückgeben kann, ist für intraprozedurale Werkzeuge nicht sichtbar.

Java

// Intraprocedural tool: no issue in either function
// Infer: finds that processResult() can receive null from fetchData()

String fetchData(boolean condition) {
    if (condition) return getData();
    return null;                    // can return null
}

void processResult(String result) {
    System.out.println(result.length());  // NPE if result is null
}

void run() {
    String data = fetchData(false);   // passes false: fetchData returns null
    processResult(data);              // null dereference
}

Use-After-Free- und Ressourcenlecks

In C und C++ treten Use-After-Free-Fehler häufig auf, wenn Speicher in einer Funktion allokiert und in einer anderen freigegeben wird, während eine dritte Funktion eine Referenz darauf hält. Eine Analyse einzelner Funktionen kann diese Fehlerklasse nicht aufdecken. Die interprozedurale Analyse untersucht die Integrität des Kontrollflusses und stellt sicher, dass Funktionsaufrufe den erwarteten Mustern folgen, um Sicherheitslücken zu verhindern.

Architektonische Kopplungs- und Abhängigkeitsverletzungen

Über Sicherheit und Korrektheit hinaus findet die interprozedurale Analyse auch Anwendung in der Architekturanalyse: Welche Komponenten rufen welche auf, welche Abhängigkeiten verletzen definierte Schichtgrenzen und welche Änderungen wirken sich kaskadenartig auf den Aufrufgraphen aus? Dies ist die Anwendung der interprozeduralen Analyse, die von Tools wie … genutzt wird. SMART TS XL Anwendung auf unternehmensweite Codebasen, wobei nachverfolgt wird, wie sich eine Änderung an einer Funktion durch den gesamten Aufrufgraphen ausbreitet, um den tatsächlichen Auswirkungsbereich zu ermitteln.

Wenn Sie eine interprozedurale Analyse benötigen

Nicht jedes Projekt erfordert eine vollständige interprozedurale Analyse. Die Entscheidung hängt davon ab, was Sie herausfinden möchten und welche Kosten entstehen, wenn Sie es nicht herausfinden.

Eine interprozedurale Analyse ist erforderlich, wenn:

• Sicherheit hat oberste Priorität, und Sie müssen Injection-, XSS- oder SSRF-Schwachstellen zuverlässig finden.
• Sie analysieren eine Legacy- oder Enterprise-Codebasis, in der sich die Geschäftslogik über viele Funktionen und Module erstreckt.
• Vor einem Refactoring ist eine Folgenabschätzung erforderlich, um zu verstehen, was sich ändert, wenn eine Funktion geändert wird.
• Sie führen eine Compliance- oder Auditanalyse durch, die den Nachweis von Gründlichkeit erfordert.
• Sie migrieren oder modernisieren eine Codebasis und müssen die komponentenübergreifenden Abhängigkeiten verstehen.

Eine intraprozedurale Analyse ist ausreichend, wenn:

• Ziel ist die Durchsetzung des Stils, die Einhaltung von Konventionen und das Aufspüren offensichtlicher lokaler Fehler.
• Sie benötigen schnelles Feedback, das in den Entwicklungszyklus integriert ist (Pre-Commit, IDE, CI pro Pull Request).
• Die Codebasis ist so klein, dass die Entwickler alle Aufrufbeziehungen kennen.
• Die Sicherheit wird auf einer anderen Ebene (validiertes Framework, Typsystem) durchgesetzt, und das Risiko funktionsübergreifender Schwachstellen ist gering.

Die praktische Antwort für die meisten Teams: Nutzen Sie beides. Intraprozedurale Tools (ESLint, Pylint, Clippy) werden bei jedem Commit ausgeführt, um schnelles Feedback zu erhalten. Interprozedurale Tools (CodeQL, Infer, Semgrep mit Taint-Regeln) werden bei Pull Requests oder nächtlich für eine gründliche Analyse ausgeführt. Die beiden Ebenen ergänzen sich, konkurrieren nicht miteinander.

Instrumente der interprozeduralen Analyse: Was jedes einzelne abdeckt

Werkzeug	Analyseansatz	Sprachen	Primärer Anwendungsfall
CodeQL	Vollständig interprozedural, IFDS-basiert	C/C++, Java, JS/TS, Python, Go, Ruby	Erkennung von Sicherheitslücken
Facebook Infer	Bi-Abduktion, interprozedural	Java, C, C++, Objective-C	Nullsicherheit, Speicherlecks, Race Conditions
Semgrep (Taint-Modus)	Flache interprozedurale Beeinträchtigung	Über 30 Sprachen	Sicherheitsmusterabgleich mit Datenfluss
Snyk-Code	ML-basierte interprozedurale	Java, JS/TS, Python, C#	Sicherheit mit entwicklerfreundlichem Feedback
Polyspace	Abstrakte Interpretation	C, C++, Ada	Sicherheitskritische, eingebettete Systeme
Frama-C	Vollständiges interprozedurales + formales	C	Formale Überprüfung, Sicherheitszertifizierung
SMART TS XL	Sprachübergreifend, systemübergreifend	COBOL, JCL, Java, Python, RPG, SQL	Unternehmenswirkungsanalyse, Abhängigkeitsanalyse

Interprozedurale Analyse über Sprachgrenzen hinweg

Standardmäßige interprozedurale Werkzeuge arbeiten innerhalb einer einzigen Programmiersprache. Eine CodeQL-Abfrage auf einer Java-Codebasis verfolgt Datenverluste über Java-Funktionsaufrufe hinweg, stoppt jedoch, sobald der Java-Code ein COBOL-Programm aufruft oder aus einem von einem JCL-Batch-Job erstellten Datensatz liest. An dieser Grenze stoßen Analysewerkzeuge für Unternehmen auf ein Problem, das Werkzeuge für eine einzelne Programmiersprache nicht lösen können.

SMART TS XL statische Code-Analyse Führt gleichzeitig eine prozedurübergreifende Abhängigkeitsanalyse über alle Sprachen der Unternehmensumgebung hinweg durch. Wenn ein Java-Dienst ein COBOL-Programm aufruft, das Daten aus einer DB2-Tabelle liest, die von einem anderen JCL-Job befüllt wird, SMART TS XL Sie verfolgt diese Kette und stellt sie als einheitliches Abhängigkeitsmodell dar. Wirkungsanalyse Die Funktion wendet dann diesen sprachübergreifenden Aufrufgraphen an, um folgende Frage zu beantworten: Wenn sich dieses COBOL-Programm ändert, welche Java-Dienste, welche JCL-Jobs und welche nachgelagerten Konsumenten sind betroffen?

Dies ist das interprozedurale Problem, angewendet auf Architekturebene statt auf Funktionsebene; dasselbe Prinzip (dem Abhängigkeitsgraphen über Grenzen hinweg folgen, anstatt an ihnen anzuhalten) wird auf das gesamte Unternehmenssystem angewendet, nicht auf einzelne Programme. Wie im Kontext von Codevisualisierung und AbhängigkeitszuordnungDie vollständige Offenlegung der Abhängigkeitsstruktur ist die Voraussetzung für jede Analyse, die den Einfluss einer Änderung verstehen will.

Für Organisationen, die Modernisierung des Altbestands, der Anrufgraph, der SMART TS XL Die sprachübergreifende Strukturierung dient demselben Zweck wie ein interprozeduraler Aufrufgraph innerhalb einer einzelnen Sprache: Sie ist die Karte, wie alles miteinander verbunden ist, und ohne sie basiert jede Analyse von Auswirkungen, Risiken oder Migrationssequenzen auf Annahmen statt auf Beweisen.

Der Zielkonflikt zwischen falsch positiven und falsch negativen Werten

Der Grund, warum die interprozedurale Analyse nicht überall eingesetzt wird, liegt nicht darin, dass niemand daran gedacht hat, sondern im Spannungsverhältnis zwischen Präzision und Performance. Eine vollständige kontextsensitive interprozedurale Analyse einer Codebasis mit einer Million Zeilen kann Stunden oder Tage dauern. Dieselbe Codebasis wird von ESLint in Sekundenschnelle analysiert. Dieser Performanceunterschied ist strukturell bedingt: Die interprozedurale Analyse wächst mit der Komplexität des Aufrufgraphen, nicht nur mit der Größe der Codebasis.

Der Vorteil der Investition liegt in messbar niedrigeren Raten falsch positiver und falsch negativer Ergebnisse:

• Fehlalarm (Tools, die fälschlicherweise einen Fehler melden): Intraprozedurale Tools erzeugen deutlich mehr Fehlalarme, da sie ohne Kenntnis des Kontextes der Aufrufer nicht feststellen können, ob ein verdächtiges Muster tatsächlich gefährlich ist. Ein intraprozedurales Tool, das eine SQL-Abfrage mit einer verketteten Zeichenkette erkennt, kann nicht wissen, ob diese Zeichenkette von einer Benutzereingabe oder aus einer vertrauenswürdigen internen Quelle stammt.
• Falsch negative (Tools, die echte Schwachstellen übersehen): Intraprozedurale Tools erzeugen viel mehr falsch negative Ergebnisse, weil sie Schwachstellen, die Funktionsgrenzen überschreiten, nicht erkennen können, was für sicherheitsrelevante Analysen die Mehrheit der echten Schwachstellen ausmacht.

Die Disziplin, den richtigen Zeitpunkt für die Anwendung der einzelnen Analyseebenen zu wählen und diese in einer mehrschichtigen Toolchain zu kombinieren, unterscheidet Security Engineering von der bloßen Erfüllung von Sicherheitsanforderungen. Zu wissen, dass Ihr Linter fehlerfreie Ergebnisse liefert, sagt wenig über Ihren Sicherheitsstatus aus. Zu wissen, dass Ihre interprozedurale Taint-Analyse jeden Pfad von externen Eingabequellen zu sensiblen Zielen in Ihrer Anwendung verfolgt und keinen nicht validierten Datenfluss gefunden hat, ist wesentlich aussagekräftiger.