This glossary defines fifteen terms you will hear on SAST vendor calls, in plain words, with one question to ask for each. Several come straight from OWASP's description of static code analysis, and the interchange format comes from the OASIS SARIF standard.
Core analysis terms
| Term | Plain definition | Question to ask |
|---|---|---|
| Static analysis | Checking code without running it | What input does it need, source or compiled? |
| Taint analysis | Tracing variables holding user controlled input to risky functions, flagged if they arrive unsanitized | Does it follow data across files? |
| Source | Where untrusted data enters, such as a request parameter | Can I define custom sources? |
| Sink | A risky operation the data should not reach unchecked, such as a database call | Can I define custom sinks? |
| Sanitizer | Code that makes data safe for a sink | Does it recognize my own helper functions? |
| Data flow analysis | Following how values move through a program | How deep, within a function or across the app? |
| Control flow graph | A graph of the paths execution can take through code | Does the engine use it for path sensitivity? |
| Lexical analysis | Turning code into tokens so it is easier to process | Is the tool doing more than token matching? |
Result terms
| Term | Plain definition | Question to ask |
|---|---|---|
| False positive | A reported issue that is not a real flaw | What controls exist to suppress and track these? |
| False negative | A real flaw the tool does not report | How would we measure what you miss? |
| Severity | How bad the issue could be | Is it separate from confidence? |
| Confidence | How sure the tool is that the finding is real | Is it shown per finding? |
| CWE | A category of software weakness | Is every finding mapped to one? |
| SARIF | A standard format for the output of static analysis tools | Can I export results in it? |
Process terms
| Term | Plain definition | Question to ask |
|---|---|---|
| Baseline | A saved snapshot of existing findings so later scans show only new ones | How does it handle moved code? |
| Triage | Deciding whether each finding is real, and what to do | Can statuses and reasons be recorded? |
How the terms fit together
A scan builds a model of your code, often using a control flow graph and data flow analysis. Taint analysis then looks for paths from sources to sinks that skip a sanitizer. Each path becomes a finding with a CWE, a severity and a confidence. You triage the findings, mark false positives, and save a baseline so the next scan shows what is new.
OWASP says taint analysis identifies variables tainted with user controllable input and traces them to possible vulnerable functions, called sinks. If the tainted variable reaches a sink without being sanitized, it is flagged. That is the heart of most injection checks, and it explains why sanitizer recognition has such a large effect on false positives.
Terms that sound the same but are not
- Severity and confidence are different. A high severity finding can have low confidence.
- False positive and accepted risk are different. One is not real. The other is real and knowingly kept.
- SAST and SCA are different. One reads your code, the other reads your dependencies.
Use the glossary on a call
Pick five terms and ask the vendor to show each on a real finding. A vendor who can point to the source, the sink, and the missing sanitizer on screen is explaining something concrete. One who stays at the level of slogans may not have the depth.
A worked example: reading one finding with the glossary
Here is a finding described in words, with each glossary term marked in brackets.
The tool reports a possible SQL injection [CWE]. A request parameter called customerId enters the application in the controller [source]. It passes through a helper that trims whitespace and then into a method that builds a query string [data flow analysis]. The query string reaches the database execute call [sink]. No function on the path escapes or parameterizes the value [no sanitizer]. The tool assigns high severity [severity] and medium confidence [confidence], because it does not know whether the trimming helper does more than it appears to. The path was found by following paths through the program [control flow graph] with tracking of tainted values [taint analysis].
A developer reviews it, finds that the value is a numeric id converted earlier by the framework, and marks it as not exploitable [triage, false positive]. The team saves a baseline [baseline] so the same finding does not return in the next scan unless the code changes.
Reading a finding this way takes a few minutes and teaches a new reviewer the vocabulary faster than a list of definitions.
Questions that separate depth from slogans
- Show me the source, the sink and the path on a real finding.
- What recognizes a sanitizer, and can I add my own?
- Does the analysis cross files and modules, and how deep does it go?
- What controls confidence, and is it shown separately from severity?
- How are suppressions and false positives recorded and reviewed?
- What happens to the baseline when files move or are renamed?
- What output formats can I export?
A vendor who answers these with examples is describing a working engine. One who answers with general statements about "advanced analysis" may not be.
Term pairs that get mixed up
| Pair | Difference |
|---|---|
| Source and sink | Where untrusted data enters, and where it becomes dangerous |
| Sanitizer and validator | One transforms data to make it safe, the other checks it and may reject |
| False positive and false negative | A wrong alarm, and a missed real flaw |
| Severity and priority | How bad a flaw could be, and when your team should fix it |
| Baseline and suppression | A snapshot of existing findings, and a decision about one finding |
| Rule and policy | A check the tool runs, and a decision about what to do with its output |
Having the difference clear avoids many internal arguments.
Using the glossary in training
If you are rolling out SAST to developers, give them a one page version of the core terms. Add two examples from your own code, one finding that was real and one that was a false positive. Developers who understand sources and sinks resolve findings faster, and they write fewer issues in the first place because they begin to see where untrusted data goes.
Terms you may hear that are not in the list
Vendors also use words like "SAST engine," "ruleset," "query language," "incremental scan" and "triage assistant." Treat each as a prompt for a question: what exactly does it do, what does it need, what does it send out. The OWASP page on static code analysis is a neutral reference for the core ideas, and the SARIF specification defines the interchange format in detail for readers who want to go deeper.
Try it yourself
Click through it at your own pace, or open it full screen. Pick one finding and find its source, its sink and its weakness type using the terms above.
Quick check
Which term causes the most confusion?
Severity versus confidence. Ask for both on each finding, and sort by them separately.
Why does SARIF matter to a buyer?
It is a standard output format, so results can move between tools and into your tracker without custom conversion.
Which three terms should a new developer learn first?
Source, sink and false positive. With those, they can read most findings and explain why a report may be wrong.
Safeguard offers SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
