SAST
In application security, SAST is static application security testing: analysing source code, bytecode or binaries for weaknesses without running the software. It reads the code the way a compiler does, tracing how data moves from where it enters to where it is used, and reports the paths that look unsafe.
How it works
The analyser parses the code into a syntax tree, builds control flow and data flow graphs, and then follows tainted values from sources, such as a request parameter, to sinks, such as a query builder or a shell call, checking whether a sanitiser sits on the path. On top of that it applies pattern rules for things that need no data flow at all: a hard-coded secret, a disabled certificate check, a weak cipher choice.
Its structural advantage is coverage and timing. It sees code paths that are hard to reach at runtime, including error handlers and unused routes, it runs on every commit, and it points at the exact line, which is what makes a finding cheap to fix.
What goes wrong
Two limits, both worth stating in a report because they are what justifies further work. The first is that static analysis reasons about code, not about intent, so an entire class of defect is invisible to it: whether this user should be allowed to read this record is not a property of the source. Business logic flaws and most authorisation failures fall in that gap.
The second is that it does not know what is deployed. It cannot see a permissive reverse proxy, a debug flag set in the environment, an old version of the service still running, or a dependency resolved at build time, which is why it is paired with software composition analysis rather than expected to replace it.
Operationally the failure is noise. A tool tuned to miss nothing produces enough false positives that teams stop reading it, and a suppressed rule stays suppressed for years. The measure of a useful deployment is not how many findings it raises but how many it raises that anybody fixed.
Where this shows up in an audit
Where a client has static analysis in their pipeline we ask for the output, and we use it as a map rather than as a result: it shows which parts of the code have been looked at and which rules are switched off. Findings we confirm dynamically are reported as confirmed; findings the tool raised that are not reachable are reported as such, because closing them costs the client money for nothing. Compared with DAST, this half of the pair sees everything and proves nothing, which is exactly why both exist. This is part of where automated analysis stops and manual testing begins.