SAST analyses your source code without running it, looking for insecure patterns that could become vulnerabilities once the code ships.
The short answer
Static application security testing reads the code itself, tracing how untrusted input flows through the application to a sensitive operation. It runs before anything is deployed, which makes it the earliest place a security flaw can be caught, and the cheapest place to fix one.
SAST looks at code you wrote. SCA looks at code you imported. Together they cover most of what ends up in a build, which is why compliance frameworks ask about both.
On this page
Where SAST runs
What it finds, and what it misses
| SAST finds | SAST misses |
|---|---|
| Injection paths where user input reaches a query or command | Authorisation flaws, because intent is not visible in code |
| Hardcoded secrets and credentials in the repository | Configuration problems in the deployed environment |
| Unsafe cryptographic and random number usage | Vulnerabilities in third-party dependencies, which is SCA’s job |
| Missing output encoding leading to cross-site scripting | Anything that only appears at runtime under real load |
Why it cannot judge authorisation
A function that returns a record by ID looks identical whether or not the caller was entitled to it. Static analysis sees the code path, not the business rule, which is why broken authorisation is found by testers rather than by scanners.
Making it usable
SAST fails in practice for one reason: too many findings, too little confidence, so developers stop reading them. Three things keep it alive.
Run it on the diff
Scan what changed in the pull request rather than dumping the whole backlog on every build.
Fail on high, log the rest
Break the build only for high-confidence, high-severity findings. Everything else is a ticket.
Tune once, properly
Suppress rule families that do not apply to your stack, with a written reason, instead of ignoring the tool.
How Osto runs code security
Osto’s code security module combines SAST with SCA, SBOM generation and open-source licence compliance, so findings from your own code and your dependencies arrive in one place rather than from separate tools. Because it sits in the same platform as the WAF, vulnerability testing and compliance modules, a code finding can be read alongside whether the affected path is exposed in production, which changes how urgently it needs fixing.
Free security assessment
Catch it in the pull request, not in production
Osto combines SAST with SCA, SBOM generation and licence compliance, so code and dependency findings arrive in one place.
Get a free security assessment Book a platform walkthroughSAST + SCA + SBOM · One toolchain · One platform, everything
Frequently asked questions
What does SAST stand for?
Static application security testing. It analyses source code without executing it, tracing how untrusted input flows through the application to identify insecure patterns before deployment.
What is the difference between SAST and DAST?
SAST reads the code before it runs and can point at the exact line. DAST tests the running application from the outside and sees what an attacker would see. SAST finds more, earlier; DAST confirms what is actually reachable.
Is SAST the same as SCA?
No. SAST analyses code your team wrote. SCA identifies third-party and open-source dependencies and checks them against known vulnerability databases. Most modern applications are mostly dependencies, so both are needed.
Do frameworks require SAST?
ISO 27001:2022 covers secure coding in Annex A 8.28 and security testing in development in A 8.29. PCI DSS requires secure development practices and code review. Neither mandates a specific tool, but both expect evidence that code is checked before release.