Tracing untrusted input from source to sink to find exploitable data flows.
Taint analysis is a classical program analysis technique that marks data from untrusted sources as "tainted" and then follows that data as it flows through the program. If tainted data reaches a sensitive operation — a database query, a shell command, a file path — without being sanitised along the way, the analyzer flags an exploitable data flow.
It is the technique behind most high-confidence SQL injection, command injection, path traversal, and SSRF findings. Unlike pattern scanners, taint analysis proves that a concrete input path exists from an attacker-controlled surface to a dangerous sink — which is exactly what a reviewer wants to see before triaging a finding as real.
The analysis is built around three concepts — sources, sinks, and sanitizers:
eval, raw SQL concatenation, shell execution, file-system APIs, deserialization, template rendering. Each sink has a taint signature that tells the engine what kind of flow would be exploitable.Most commercial SAST tools lean heavily on pattern matching. They find uses of dangerous APIs and flag them regardless of whether attacker-controlled data can actually reach them. The result is a backlog of mostly-false-positive findings and an engineering team that stops reading the alerts.
Taint analysis inverts that. It produces fewer findings, each one backed by a specific data flow you can replay in a debugger. That is the difference between a scanner that annoys engineers and an analyzer that changes how code gets shipped.
Every finding ships with a source-to-sink trace. A developer can see exactly how input travels and where to break the flow.
Pattern scanners flag every risky API call. Taint analysis only flags the ones reachable from untrusted input — usually 5–10x fewer findings.
If the team already routes input through a validator, the engine understands that and stops flagging the sanitised flow. Existing defenses actually count.
Second-order SQLi, template injection through config, and SSRF via indirect URL construction are taint problems by nature — and invisible to grep-style rules.
Structured taint paths are the right input for remediation PRs, policy gates, and AI-generated fixes. Findings without traces cannot drive automation.
Taint analysis is the core of Safeguard's reachability engine and the structured signal behind zero-day discovery. Every taint path becomes evidence that Griffin AI uses to reason about exploitability and draft remediations.
Point Safeguard at a repo. Get a list of source-to-sink flows back. Compare it to your current SAST output.