Definition and guide

What is SAST? A complete guide to Static Application Security Testing

What to know

Start your free trial

Verify all code. Find and fix issues faster with SonarQube.

始めましょう

TRUSTED BY 7M+ DEVELOPERS & 400K+ ORGANIZATIONS

Why application security can't wait 

Speed is the new currency of innovation. In a world where software powers every digital experience, whether it’s mobile banking, online shopping, or critical infrastructure, organizations are racing to deliver new features faster than ever. Code is being shipped continuously, often multiple times a day, to keep up with user expectations and market demands.

But this velocity comes with significant risk. One overlooked vulnerability, hidden among millions of lines of code, is all it takes for an attacker to break in. The result can be catastrophic: data breaches leading to millions in fines, lost revenue, and irreversible damage to customer trust. Modern defenses should focus on code security across the entire lifecycle, not just at release.

The truth is, many organizations still treat security as an afterthought, a final hurdle before deployment. This outdated “security gate” approach simply can’t keep up with today’s rapid release cycles. It slows down innovation, and it creates a culture of friction between development and security teams.

Modern development demands a modern approach to security. That means bringing it forward, embedding it directly into the coding process itself. This proactive mindset, “shift left”, empowers developers to identify and fix vulnerabilities early, during the coding process, long before they ever reach production. And at the heart of this transformation is Static Application Security Testing (SAST), a technology designed to make secure coding a natural part of how software gets built.

What does "static" in SAST actually mean? 

SAST stands for Static Application Security Testing, a method of automatically scanning and analyzing application source code to find security vulnerabilities, hotspots, or flaws before the code is compiled or run. By analyzing code early in the development lifecycle, SAST helps developers fix issues like insecure coding patterns or missing validation, which reduces the risk of breaches and is more cost-effective than fixing them after deployment.

To understand SAST, it helps to use an analogy. Imagine you're building a skyscraper.

Dynamic Application Security Testing (DAST) is like hiring an inspector after the skyscraper is built. The inspector tests doors, alarms, and elevators, interacting with the building as an outsider would to uncover weaknesses. This is DAST: it tests a running application, trying to find exploitable vulnerabilities from an attacker's perspective.

Static Application Security Testing (SAST), on the other hand, is like having an expert engineer review the blueprints before a single piece of steel is put in place. The engineer isn't walking around a real building; they're reading the architectural plans to find flaws in the design itself. They can see a weak support beam, a missing emergency exit, or a flawed electrical plan just by analyzing the design.

SAST is a "white-box" testing method that scans your application's source code—its blueprints—to find quality and security issues before the application is ever compiled or run.

Key advantages of static analysis

This "blueprint" approach gives SAST unique advantages:

  1. Complete code coverage: Scans 100% of the codebase, including code that is hidden or hard for a dynamic scanner to reach
  2. Early detection: Helps find issues as developers write code, does not require the application to be running.
  3. Pinpoint accuracy: Identifies the exact line of vulnerable code.
  4. Fast feedback: Modern SAST tools analyze code in seconds, not hours

What does a modern SAST tool detect?

The term "SAST" has evolved significantly. A decade ago, it might have just referred to finding common vulnerabilities like SQL injection. But today's applications are far more complex. The "attack surface" no longer just includes your own code; it includes your cloud infrastructure, your internal credentials, and more.

A comprehensive, modern SAST tool secures all static code assets across three key areas: 

1. Core security vulnerabilities in your application code

This is the classic, and most critical, function of SAST. It involves analyzing the logic and data flows within your own proprietary code to find flaws that could be exploited by an attacker. Taint analysis, a core SAST technique, tracks how untrusted data moves through your code. The outcome is that teams can focus on the most critical vulnerabilities first.

How Taint Analysis Works

Taint analysis is the powerful technique that allows modern Static Application Security Testing (SAST) tools to precisely detect vulnerabilities in your code. It works by modeling the flow of data through your application to identify paths that could be exploited by an attacker. In simple terms, taint analysis works by:

  1. Identifying "sources": Any place where untrusted data can enter your application (like a user-filled web form or a URL parameter). This data is marked as "tainted."
  2. Tracking "sinks": Any sensitive part of your code where that data could do something dangerous (like a database query, a file system command, or rendering HTML on a page).
  3. Finding the path: The tool scans for any path where "tainted" data from a source can reach a "sink" without being properly cleaned or sanitized first.

When such a path is found, the tool flags a precise security vulnerability. This deep-flow analysis is how Sonar finds the most critical flaws, which align with major industry lists like the OWASP Top 10 and CWE Top 25.

  • SQL injection: Tainted user input is used directly in a database query, allowing an attacker to steal or corrupt your entire database
  • Cross-site scripting (XSS): Tainted user input is rendered back to a web page, allowing an attacker to inject malicious scripts into your users' browsers
  • Command injection: Tainted user input is used to run a system command, allowing an attacker to take over your server
  • Path traversal: Tainted user input is used to build a file path, allowing an attacker to read or write sensitive files on your server

This kind of sophisticated SAST doesn't just find these big, critical issues; it also finds thousands of other less severe security risks and common code quality bugs, providing you with actionable code intelligence across your entire codebase.

2. Hard-coded secrets (secrets detection)

Modern applications are built on a complex web of APIs and cloud services, all of which require sensitive credentials: API keys, database passwords, private tokens, and security certificates. Out of convenience, developers often make a critical mistake "hard-coding" these secrets directly into the source code.

db_password = "MySuperSecretPassword123!"

If this line of code is committed to a repository—even a private one—the secret is now compromised. The entire repository history contains the credential, meaning anyone who gains access, including an attacker, can use it to compromise your production systems and data. This is a common and high-impact security failure. Secrets detection is a specialized form of static analysis that acts as an essential safety net for your team. It actively scans all files and commits history for patterns that look like hard-coded credentials, providing a real-time warning before you can commit a sensitive token. Since it analyzes static text files for flaws, it is a key part of a modern SAST strategy.

3. Infrastructure as Code (IaC) misconfigurations

Today's applications run on complex cloud infrastructure that is defined entirely by code. Infrastructure as Code (IaC) tools like Terraform, Kubernetes, CloudFormation, and Docker allow you to define your entire cloud environment—servers, networks, databases, storage—in static configuration files. This is incredibly powerful, but also carries significant risk.

Since your infrastructure is now defined by code, a single-line misconfiguration can lead to massive security failures:

  • Data Exposure: Accidentally making a private S3 bucket (containing customer data) public to the entire internet
  • Access Control: Opening a firewall port that grants unauthorized access to a production database
  • Compliance Failure: Granting excessive permissions to a service, which violates the principle of least privilege

IaC scanning is a vital form of static analysis that checks these static configuration files before deployment. It acts as a preventative measure, validating your infrastructure definitions against security best practices and compliance rules.  By integrating this analysis early in your workflow, you prevent building a flawed, insecure foundation for your application. This is a critical step in complete code strategy.

The benefits of "shifting left" by building code security into your workflow 

Integrating SAST into the earliest stages of development—a practice known as "shifting left"—transforms security from a last-minute roadblock into a business accelerator. Here are the key benefits of this approach:

1. Fix issues early, reduce costs

The data is definitive: security issues found and fixed during the development phase are significantly cheaper to resolve than those found in production. A study by IBM found that a bug found and fixed during the development phase costs over 100 times less than the same bug found in production.

When a developer finds a security issue with a SAST tool right in their IDE, it's a five-minute fix. They're already in the context of the code and can correct it immediately.

When that same issue is found in production, it's an "all hands on deck" emergency. It requires security teams to investigate, developers to be pulled off new features, a new patch to be written and tested, and an emergency deployment—all while the company is actively vulnerable. SAST saves enormous amounts of time, money, and stress.

2. Enforce consistent security standards at scale

How do you ensure that 500 developers across 50 different teams are all following the same security standards? Manual code reviews alone can't scale, and they're inherently subjective.

SAST acts as an automated, impartial security expert that reviews 100% of all code changes, 24/7. It enforces your security policies consistently across your entire organization, regardless of team size, time zone, or individual expertise.

3. Achieve faster, safer releases 

When security is "bolted on" at the end, it becomes a bottleneck. A last-minute security scan that reveals a critical flaw means delaying the release, scrambling to patch the code, and retesting everything.

By integrating SAST into your CI/CD pipeline, security checks happen automatically with every commit and pull request. Issues are caught and fixed incrementally, eliminating any major surprises and allowing your team to ship faster and safer.

4. Empower developers with actionable intelligence

Modern SAST tools do more than just block a commit–they function as a real-time coach. When a tool flags a SQL injection vulnerability, it doesn't just point out the problem; it explains:

  • What the vulnerability is
  • Why it is a risk 
  • How to fix it properly

This approach provides developer enablement, helping your team grow their security skills while delivering high-quality code. 

5. Essential safety net for AI-generated code

As AI code assistants become mainstream, developers are generating more code faster than ever. But AI models can also generate insecure code, as they're trained on public repositories that include vulnerable examples.

SAST provides an automated safety net, verifying that all code—whether written by a human or generated by AI—meets your security standards before it reaches production.

6. Compliance and audit support

Many security and privacy regulations (like PCI DSS, HIPAA, SOC 2, and GDPR) require organizations to demonstrate that they have secure development practices in place.

SAST tools provide auditable proof of your security efforts. They generate reports showing:

  • What vulnerabilities were found
  • When they were detected
  • How and when they were remediated
  • What security rules are being enforced

This documentation is invaluable during compliance audits and can significantly reduce the time and stress of proving your security posture.

What are common challenges and limitations of SAST? 

While SAST is powerful, it's important to understand its limitations and common challenges.

The problem of false positives and noise 

The most common complaint about older, first-generation SAST tools was that they were "noisy." They would flag hundreds of issues that weren't real vulnerabilities, creating "false positive" fatigue. When developers are flooded with alerts, they eventually start to ignore all of them—including the real ones.

This is why the accuracy of a modern SAST tool is paramount. Actionable code intelligence must be built on trust. High-quality tools use sophisticated taint analysis and finely-tuned rules to ensure a low false-positive rate. When the tool flags an issue, you can trust that it is a real problem that warrants your attention.

What SAST can't find (runtime flaws)

By its very definition, SAST only analyzes static code. It cannot find vulnerabilities that only appear when the application is running.

These "runtime" or "logical" flaws include:

  • Business logic errors: For example, a flaw in a shopping cart's checkout process that allows a user to apply a coupon multiple times
  • Broken access control: A flaw where a user can access another user's data just by changing an ID number in the URL
  • Live environment misconfigurations: A problem with your production server, as opposed to the code that defined it
  • Vulnerabilities in third-party libraries: This is a crucial distinction, which we'll cover in the FAQ

This is why a comprehensive code security program requires a layered approach. SAST must be complemented by other tools, most importantly Software Composition Analysis (SCA) to track vulnerabilities in third-party dependencies, and Dynamic Application Security Testing (DAST) for runtime checks.

Integration and adoption hurdles

Introducing any new tool into a development workflow can be challenging if it slows down development or creates friction. Common adoption hurdles for security tools include:

  • Developer resistance: If SAST is perceived as slowing down development or creating busywork
  • Toolchain integration: Ensuring SAST works seamlessly with your existing IDEs, version control, and CI/CD systems
  • Customization needs: Different projects may need different security rules and thresholds
  • Legacy code burden: Old codebases may have thousands of existing issues

These challenges are solvable with a modern platform that prioritizes Developer Experience. Look for tools that offer flexible, seamless integration with your IDE and CI/CD systems, and support incremental adoption strategies to tackle legacy issues without immediately overwhelming your teams.

Understanding these challenges is essential when selecting a SAST platform. Modern solutions like SonarQube are specifically designed to overcome these limitations while delivering comprehensive security coverage.

How Sonar Helps You Integrate SAST in your development workflows

SonarQube provides a comprehensive, integrated solution for code quality and security, helping developers build better, more secure software, faster. The platform is designed to fit seamlessly into your existing developer workflow, providing the right feedback at the right time.

Comprehensive SAST Coverage

SonarQube's powerful Static Application Security Testing (SAST) engine detects the full spectrum of issues discussed in this article. It uses advanced techniques like taint analysis to find critical vulnerabilities (like SQL injection and XSS) with industry-leading accuracy and low false positives.

This core capability is augmented with secrets detectionto prevent credentials from leaking and Infrastructure as Code (IaC) scanning to secure your cloud configurations before deployment.

Advanced Security Features

To provide a complete security picture, SonarQube's Advanced Security capabilities add Software Composition Analysis (SCA), finding known vulnerabilities (CVEs) in your third-party open-source dependencies.

This, combined with Advanced SAST, allows the analysis engine to trace data flows into your dependencies, uncovering hidden vulnerabilities in the interactions between your code and third-party libraries.

Seamless Developer Integration

Sonar integrates this holistic feedback directly into the developer's workflow:

  • Real-time analysis in SonarQube for IDE as developers code
  • Automated feedback in pull requests with clear guidance on how to fix issues
  • Quality Gates in CI/CD pipeline that prevent vulnerable code from reaching production

This ensures all code—human-written and AI-generated—is secure and production-ready from the start.

Ready to strengthen your application security? Get started with SonarQube today.

Frequently asked questions

This is the most common and important question in application security.

  • SAST (Static Application Security Testing): Reads your code blueprints. It analyzes your (first-party) code "at rest" to find flaws in its design
  • DAST (Dynamic Application Security Testing): Inspects the finished building. It attacks your running application from the "outside" to find exploitable runtime vulnerabilities

SCA (Software Composition Analysis): Checks your list of ingredients. Modern applications are built from hundreds of open-source libraries (third-party code). SCA scans your project's dependencies and checks them against a database of known vulnerabilities (called CVEs). It answers the question: "Am I using any pre-made components that have a known security recall?"

  • Follow SonarSource on Twitter
  • Follow SonarSource on Linkedin
language switcher
日本語 (Japanese)
  • 法的文書
  • トラスト センター

© 2025 SonarSource Sàrl.無断複写・転載を禁じます。