ROOTVIELROOTVIEL
← Knowledge Base

Knowledge Base

Implemented8 min

Taint analysis and exploitability

A dangerous sink is only a guess. The real question is whether untrusted input actually reaches that sink along a real path — and whether that path is reachable in the real deployment.

Sources, sinks, sanitizers

Taint analysis tracks the flow of untrusted data through a program. It names sources (where untrusted input enters), sinks (dangerous operations like a shell call or a database query), and sanitizers (operations that neutralize the danger). It then follows definitions and uses across the program’s structure to answer a precise question: can data from a source reach a sink without passing through a sanitizer?

This replaces a weaker heuristic — "a source and a sink both appear in this function" — with a real definition-use analysis that produces the actual source-to-sink path as evidence.

From "a path exists" to "it is exploitable"

A path in the code is necessary but not sufficient. The engine promotes a taint finding only when the path provenance marks it as proven — a route that is merely co-located stays UNKNOWN. Reachability into the real deployment is expressed through attack-surface and correlation graphs and invariants like "a critical asset must not be reachable from untrusted input" or "server-side request forgery must not reach cloud credentials".

Verified

The verifier re-reads the source to confirm the finding is re-derivable, not a stale rule hit from a cached scan. A finding you cannot reproduce from the code is not a finding.

A concrete flow

illustrative — untrusted parameter reaching a shell sink
name = request.args.get("name") # source: untrusted input greeting = "hello " + name # taint propagates through assignment subprocess.run(greeting, shell=True) # sink: command execution

The taint engine emits the source-to-sink path as evidence; a verifier settles the invariant "tainted data must not reach a sensitive tool"; the membrane marks it SUPPORTED. A controlled sandbox proof — a benign command whose observed output cannot be faked — is what turns SUPPORTED into CONFIRMED. The chain mirrors the whole platform: propose, verify, prove.

Honest limits

The native taint analysis is strongest for one language, with provenance for the common injection classes. It is, by its own description, single-pass and straight-line — interprocedural, alias and branch precision are the next slices of work. For other languages the analysis is presence-based rather than full taint, and is marked as partial. This is the code family’s known weakness, stated plainly rather than hidden behind a precision figure we will not quote.

References

  1. [1]Denning, A lattice model of secure information flow
  2. [2]Sabelfeld & Myers, Language-based information-flow security
  3. [3]Yamaguchi et al., the Code Property Graph
  4. [4]MITRE CWE Top 25
  5. [5]OASIS SARIF (static-analysis results format)

References point to public, well-known technical sources for further study.

Related articles