A source is a place where untrusted data enters your program, such as a request parameter. A sink is a place where that data could do harm, such as a database query or a shell command. Static analysis tools trace whether data can travel from a source to a sink without being cleaned.
The vocabulary
Source: any input an attacker may control. Examples: query strings, form fields, headers, uploaded files, values read from a message queue.
Sink: a function whose behavior becomes unsafe with hostile input. Examples: running a SQL string, writing to a file path, rendering HTML, starting a process.
Sanitizer: code that makes data safe for a given sink, such as a parameterized query or an HTML encoder.
Taint: the label a tool puts on data that came from a source. If tainted data reaches a sink with no sanitizer on the path, the tool reports a finding.
A small example
A request handler reads a name from the URL. It passes the name to a helper. The helper concatenates it into a SQL string and runs it. The source is the URL parameter, the sink is the query call, and the path crosses two functions. A good tool reports the whole path, not only the last line.
Why the path matters
OWASP notes that SAST tools report the file, line number and affected snippet, and that confirming a flagged issue as a real vulnerability can be hard. The path is what lets you confirm it. Ask three questions when you read a finding:
- Can an outside user really control the source?
- Is there a sanitizer on the path that the tool did not recognize?
- Is the sink used the way the tool assumes?
Common reasons findings are wrong
| Cause | What it looks like |
|---|---|
| Custom sanitizer | Your own validation function is unknown to the tool |
| Trusted source | The tool treats an internal config value as user input |
| Dead path | The route is never called in production |
| Framework magic | Escaping happens in a layer the tool cannot see |
Common mistakes
A frequent mistake is trusting a single layer of defense. Input validation at the edge helps, but the sink should also be used safely, for example with parameterized queries. If a tool flags a path, check both ends. Another mistake is treating internal data as safe. Values read from a database or a queue may have started as user input, so a careful tool follows them. When you write custom rules, name sources and sinks explicitly so the tool and the team share the same model.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a code finding and follow the path from where the data enters to where it lands.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis and pull request policy gates. The free scan covers your dependency side.
Quick check
Is every source to sink path a vulnerability?
No. It is a candidate. A sanitizer the tool missed, or a source an attacker cannot reach, can make it harmless.
Can I teach the tool my sanitizer?
Many tools let you declare custom sanitizers or sinks in rules. Check your tool's documentation.
Sources
Last reviewed: 19 October 2026.
