SAST runs against code without deploying the application. That lets it see what DAST cannot (internal logic, paths unreachable from the outside, dead code) and it also blinds it to what only appears at runtime (configuration drift, real authentication, runtime behaviour). The two techniques are complementary and used together.
What SAST is
SAST (Static Application Security Testing) is the security analysis of an application by inspecting source code or compiled binaries without running them. The tool walks the syntax tree, the call graph and the data flow to surface insecure patterns: SQL or command injection, XSS via string concatenation, unsafe deserialisation, secrets pasted into the repository, weak cryptography or dependencies with known CVEs. It runs in the developer's IDE, on the pull request or inside the CI/CD pipeline before deployment. SAST is one of the practices recommended by OWASP SAMM under Implementation and appears as a central coding-phase control in the NIST Secure Software Development Framework (SSDF, SP 800-218). Its natural companion is DAST, which probes the running application from the outside.
Why it matters
For an organisation that ships its own software, finding a vulnerability in production costs between one and two orders of magnitude more than finding it in the coding phase. SAST shifts the cost left in the cycle: the developer sees the finding while writing the code or, at the latest, when opening a pull request, and they fix it with the context still fresh. What reaches the pentest is then reserved for findings that only emerge once the application is assembled. For teams preparing an ISO 27001 audit, working under NIS2 or DORA, or operating ENS, SAST delivers continuous evidence of secure code review for the software the organisation owns. The classic trap is to turn SAST into a bottleneck: if the tool flags five thousand findings per project and most of them are noise, the team will either disable it or ignore it.
Key points
Report quality depends heavily on the language and framework being analysed. Strongly typed languages with stable rules (Java, C#) usually produce fewer false positives than dynamic ones (Python, JavaScript). Before choosing a tool, pilot it against the real repository and measure signal versus noise — do not rely on the vendor brochure.
The right integration point is the pull request, not an isolated nightly build. Developers need to see the finding next to the line they just wrote, not in a report that arrives three days later to a different team. CI/CD with selective gating (block only critical categories) is the usual balance that keeps velocity and still reduces risk.
Hardcoded secrets are SAST's highest-return finding. An API token or service key pasted into a repository propagates to every mirror, fork and pipeline; rotating it after the fact is slow. Catching it on the commit that introduced it and blocking the push removes most of the risk.
SAST does not replace pentesting or ethical hacking. A serious pentest uncovers business-logic flaws, abuse of functionality and chains the static tool cannot model. What SAST does is prevent the pentest from spending its time on classes of bugs the tool should have caught.
Finding management matters as much as the tool itself. Without clear ownership in the development team, severity-based SLAs and a documented way to mark a finding as a false positive or accept the risk with an expiry date, the backlog inflates and stops driving decisions. Integrating SAST into an ASPM layer that deduplicates findings is usually the right move.
Example: introducing SAST across a portfolio of Java and Python applications
A company runs its product portfolio on Java (Spring) and its internal services on Python (FastAPI) and decides to launch a secure development programme. In phase one it picks a SAST tool that covers both languages and integrates it into GitHub Actions so every pull request triggers an analysis. To avoid the classic bottleneck, blocking gating is not enabled on day one: the pipeline informs but does not block. The security team classifies the first thousand findings into four buckets: secrets in the repository (immediate action), injection and deserialisation (high), weak cryptography (medium) and the rest (informational).
Six weeks in, selective gating is introduced: the pipeline blocks pull requests that add new secrets or introduce fresh weak cryptography but lets through legacy informational findings. The number of critical issues found in the half-yearly pentest drops measurably and, crucially, the ones that still appear are business-logic flaws SAST would never have caught — which means the pentest budget is being spent where it matters. The evidence emitted by the pipeline feeds the ISO 27001 control panel and the preparation of the next audit.
Common mistakes
- Switching blocking gating on from day one. A first wave of legacy findings paralyses development and ends with the tool disabled or configured to ignore everything. Start in informational mode and raise gating one category at a time as the team matures.
- Treating every language with the same template. Each engine analyses some languages better than others. Without a pilot against real code with measured signal-versus-noise, the choice ends up driven by commercial criteria and does not pay back.
- Buying SAST without a finding management process. Without ownership, SLAs and a documented way to mark false positives or accept risk with an expiry date, the backlog inflates and stops being an actionable signal.
- Assuming SAST detects vulnerabilities in third-party dependencies. That is the job of SCA and the SBOM. Asking SAST to cover that ground leads to false negatives and to surprises in production.
- Leaving developers out of the design of the programme. SAST without training and concrete remediation patterns by category becomes an opaque tax. A short guide of secure patterns per language closes the loop.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
How does SAST differ from DAST?
SAST inspects code without executing it: it sees internal logic, unreachable paths and secrets pasted into the repository. DAST probes the running application from the outside: it sees real configuration, effective authentication and runtime behaviour. They are complementary, and a serious application security programme uses both.
When in the development cycle should SAST run?
Ideally in three places. A lightweight linter inside the IDE, the full engine on every pull request, and a final pass on merge to the main branch as evidence. The point is that the finding reaches the developer while the code is still fresh in their head, not days later in a separate report.
How do you handle SAST false positives?
Assume they exist and design the process so they do not destroy trust. Every finding should be markable as a false positive with a justification signed by a reviewer other than the author, with an expiry date and a re-evaluation on every change. Without that workflow the team disables the tool.
Does SAST help with ISO 27001, ENS, NIS2 or DORA?
It supplies concrete evidence of technical review of in-house software during the development cycle, which is one of the controls these frameworks require when the organisation builds applications. On its own it does not cover every aspect of secure software, but it is one of the strongest pieces of evidence for that control.
How long until the first useful result?
The initial report lands within hours of connecting the tool to the repository. The actionable signal — findings classified, baseline cleaned, selective gating in place — usually emerges between weeks four and eight. Before then noise dominates and informational mode is the right setting.