SAST Tool Guide: How Static Application Security Testing Finds Vulnerabilities in Your Code

A SAST tool reads your source code and flags security flaws before the code ever runs. SAST stands for static application security testing, and it is the earliest point in the software lifecycle where you can catch an SQL injection, a hardcoded API key or an unsafe eval(). This guide explains what a SAST tool does, how SAST code scanning works under the hood, what separates a good SAST tool from a noisy one, and how to run code security analysis in your IDE, your pull requests and your CI/CD pipeline.

Quick facts
What it is	A SAST tool analyses source code, not a running app, to find vulnerabilities
When it runs	In the IDE, on every pull request, and as a CI/CD security gate
What it finds	Injection, XSS, insecure crypto, hardcoded secrets, unsafe deserialization, risky LLM code
What it misses	Runtime and configuration issues on the live site (that is what DAST covers)
Main standard	Findings mapped to CWE IDs and the OWASP Top 10

What is a SAST tool? Static application security testing explained

Static application security testing is "white-box" testing: the SAST tool has full access to the code and inspects it without executing it. It parses files, follows how data moves from inputs to dangerous functions, and matches the result against a library of known vulnerability patterns. Every finding points at an exact file and line, which is why developers tend to prefer a SAST tool over a scanner that only reports symptoms from the outside.

SAST is one of three scanning layers most teams combine. Software composition analysis (SCA) checks your open-source dependencies for known CVEs, which we cover in the software composition analysis guide. Dynamic testing (DAST) attacks the running application. If you are unsure which one you need first, read static vs dynamic analysis. The short answer: a SAST tool is the cheapest place to fix a bug, because the developer who wrote it is still looking at it.

How SAST code scanning works

Under the hood, every SAST tool does some combination of four things:

1. Parsing. The code is turned into an abstract syntax tree (AST), so the SAST tool understands structure (a function call, a JSX attribute, a string concatenation) instead of just text.
2. Pattern and rule matching. Rules describe dangerous constructs: innerHTML assigned from a variable, a query string built with +, yaml.load without a safe loader.
3. Data-flow and taint analysis. More advanced SAST code scanning tracks a value from a "source" (request body, URL parameter, LLM output) to a "sink" (a database call, a shell command) to decide whether the dangerous construct is actually reachable by an attacker.
4. Prioritisation. Findings get a severity, a CWE ID and an OWASP category, so the team can fix critical issues first. The OWASP Top 10 (2025) is the most common way to group them.

The depth of step three is the biggest difference between SAST tools. Rule-based scanning is fast and predictable. Deep inter-file data-flow analysis catches more subtle bugs but needs more compute and is harder to explain when it is wrong.

What a good SAST tool should find

Whatever SAST tool you pick, check that its rules cover at least these categories:

• Injection: SQL, NoSQL, command and template injection (CWE-89, CWE-78).
• Cross-site scripting: unescaped output, dangerouslySetInnerHTML, innerHTML from user data.
• Hardcoded secrets: API keys, tokens and private keys committed to the repo. Our guide to fixing hardcoded secrets walks through cleanup, and secrets in git history explains why deleting the line is not enough.
• Insecure cryptography: MD5 or SHA-1 for passwords, Math.random() for tokens, disabled TLS verification.
• Unsafe deserialization and code execution: eval(), pickle.loads, new Function().
• AI and LLM code risks: model output passed to exec or a shell, API keys exposed in browser bundles, agents given dangerous tools. This is new ground, and many older SAST tools have no rules for it yet.

Developer-first SAST: why speed and accuracy matter

A SAST tool is only useful if developers act on its output. Two things decide that.

Speed. If SAST code scanning takes 40 minutes, it gets moved to a nightly job and nobody reads the report. A developer-first SAST tool should scan a typical repository in seconds to a few minutes, so it can run on every pull request.

Accuracy. False positives are the main reason teams abandon a SAST tool. Every finding a developer marks "not a real issue" teaches them to ignore the next one. Look for a SAST tool that lets you mark false positives once and remembers them across scans, and that explains each finding with a vulnerable example and a secure example.

Actionable results matter as much as detection. The best SAST tools pair every finding with a concrete fix: the corrected code, not just a link to a CWE page.

Where to run your SAST tool

In the IDE

Running the SAST tool in the editor catches problems at the moment they are cheapest to fix. Some SAST tools scan as you type; others scan the workspace on demand. Either way, the developer sees the finding next to the code they just wrote.

On every pull request

A PR check makes SAST code scanning part of code review. Reviewers see new security findings beside the diff, and the author fixes them before merge.

As a CI/CD security gate

The CI/CD security gate is where a SAST tool turns policy into enforcement: fail the build if a new high or critical issue appears. Export results as SARIF so they show up in your code host's security tab. Our guide to securing your CI/CD pipeline and the article on code quality audits in CI show how to wire this up without blocking every merge on day one.

AI auto-fix in SAST tools

The newest SAST tools use AI to write the fix, not just describe it. The workflow looks like this: the SAST tool finds the issue, an AI model drafts a patch, and the tool opens a pull request so a human reviews the change. Treat AI fixes as a strong first draft. Always review the diff, run your tests, and re-scan, because a fix that compiles is not automatically a fix that is secure.

How to choose a SAST tool

Use this checklist when comparing SAST tools:

• Language coverage: does the SAST tool support every language in your stack, and how deep is support for each one?
• Analysis depth: pattern rules only, AST rules, or full inter-file data-flow analysis?
• Noise control: false-positive marking, severity filters, ignore files.
• Fixes: written guidance, code snippets, or AI-generated pull requests?
• Workflow: IDE extension, CLI, PR checks, CI/CD gate, SARIF export.
• Privacy: does your source code leave your machine or CI runner?
• Beyond SAST: secrets, dependencies, infrastructure as code and container checks in the same scan.
• Price: per-developer pricing gets expensive fast for small teams.

For a wider market view, see our roundup of the best code quality tools and SonarQube and Snyk alternatives.

Snyk Code and other SAST tools

Snyk Code is one of the best-known developer-first SAST tools. Its strengths are deep data-flow analysis across files, a large vulnerability knowledge base, real-time scanning in popular IDEs and AI-generated fixes. SonarQube is the other common choice, with a broader focus on code quality alongside security. Both are strong products. They are also priced for teams with a security budget, which is why many smaller teams look for a lighter SAST tool that covers the essentials. Our head-to-head pages compare them directly: Scanverra vs Snyk and Scanverra vs SonarQube. If dependency scanning is your main concern, npm audit vs Snyk vs Dependabot covers that side.

Scanverra as a SAST tool: what it does and what it does not

Scanverra's code scanner includes a SAST tool built for small and mid-sized teams. Here is exactly what it covers:

• Rule-based SAST code scanning with a database of 700 rules, each with a CWE mapping, an OWASP category, a vulnerable example, a secure example and a fix. Coverage is deepest for TypeScript, JavaScript and Python, with rules for Java, Go, C#, PHP, Ruby and more.
• AST rules for TypeScript, React and Next.js, which understand code structure rather than matching text.
• AI and LLM code security: model output reaching eval or a shell, AI API keys exposed through public environment variables, risky agent tools and MCP configuration.
• Secrets, dependencies, infrastructure as code and containers in the same scan, so one SAST tool run also covers Terraform, Kubernetes, Dockerfiles and vulnerable packages.
• AI fix pull requests on GitHub and Bitbucket: Scanverra drafts the patch and opens a PR for you to review.
• False-positive memory: mark a finding as a false positive or ignored once and it stays that way on later scans.
• Local scanning: the Scanverra CLI runs on your machine or CI runner and, by default, uploads only findings, not your source code. Use --fail-on high as a CI/CD security gate and --sarif for your code host's security tab (see the CI/CD docs).
• IDE: the VS Code extension runs the same engine on your workspace.

And where it does not match the enterprise SAST tools, stated plainly:

• Scanverra's SAST is rule- and AST-based. It does not do deep inter-file taint analysis the way Snyk Code does, so some multi-file data-flow bugs will be missed.
• The VS Code extension scans on demand, not as you type.
• Language depth outside TypeScript, JavaScript and Python is narrower than the largest commercial SAST tools.

If you need full data-flow coverage across a large polyglot codebase, a dedicated enterprise SAST tool is the right call. If you want a fast SAST tool that also covers secrets, dependencies, IaC and AI code in one scan, try a free repository scan.

Getting started with SAST

1. Scan the main branch once to get a baseline, and fix the critical findings first.
2. Mark false positives so the next scan is clean.
3. Add the SAST tool to pull requests, reporting only new issues.
4. Turn on the CI/CD gate for high and critical severity once the baseline is under control.
5. Re-scan after every fix, including AI-generated ones.

Static application security testing will not catch everything. Pair your SAST tool with dependency scanning and a scan of the live site; our guide to reading a security scan report helps you make sense of the results. Started early and kept quiet enough that developers trust it, a SAST tool is one of the highest-value security checks a team can run.