Static Application Security Testing Tutorial

This static application security testing tutorial explains how to run, tune, and operationalize SAST findings in a practical engineering workflow safely.

A SAST scan that produces 4,000 findings on its first run has not made an application safer. It has created a triage problem. The practical value of Static Application Security Testing comes from finding code-level weaknesses early, validating which findings are real, and giving developers fixes they can apply before risky code reaches production.

This static application security testing tutorial is built around that operating model. It focuses on the decisions an Application Security Engineer must make: where to scan, which rules matter, how to control noise, and how to turn results into an engineering process rather than a security report nobody owns.

What SAST Actually Examines

Static Application Security Testing, commonly called SAST, analyzes source code, bytecode, or compiled artifacts without executing the application. A SAST engine models code paths and looks for patterns associated with vulnerabilities, such as untrusted data reaching a database query, unsafe deserialization, insecure cryptography, missing authorization checks, or dangerous command execution.

The central concept is data flow. A scanner identifies a source of attacker-controlled input, follows how that data moves through the program, and determines whether it reaches a sensitive sink without an appropriate control. In a SQL injection case, an HTTP parameter may be the source, string concatenation may propagate the value, and a database execution function may be the sink.

SAST is not a substitute for secure code review, threat modeling, dependency analysis, or DAST. It answers a distinct question: does the code contain a potentially exploitable implementation pattern? The answer can be highly useful, but it depends on the language, framework support, rule quality, and the scanner's ability to understand your application context.

Prepare the Repository Before You Scan

Start with a defined scope. Scan the application code that your team builds and deploys, then decide deliberately whether to include infrastructure code, test fixtures, generated files, and shared libraries. Including everything by default often inflates findings and hides the code that presents real production risk.

Confirm that the scanner can build or parse the project correctly. Some tools need build commands, dependency resolution, compiler settings, or framework configuration to create accurate code models. A scan that silently skips modules or cannot resolve imports can appear successful while missing the very paths you expect it to inspect.

Before enabling CI enforcement, run a baseline scan on the default branch. Record the repository revision, scan configuration, ruleset version, and finding count. This baseline is not an approval of existing vulnerabilities. It is a controlled starting point that lets the team prevent new security debt while remediating the existing backlog according to risk.

A useful baseline separates findings into three groups: confirmed issues, likely false positives, and findings that need contextual review. Do not rush this step. Tuning decisions made from an unreviewed result set usually create either alert fatigue or blind spots.

Run Your First SAST Scan With a Narrow Goal

Your first goal is not maximum coverage. It is validating that the tool recognizes your code and can produce actionable results. Begin with high-confidence rules for vulnerability classes that have clear remediation paths: injection, path traversal, command injection, unsafe deserialization, hardcoded secrets, and weak cryptographic use.

For example, consider a Java handler that accepts a sort parameter and adds it directly to a query string. A scanner may flag the database execution method as a sink. Your review must determine whether the value is constrained by a server-side allowlist, passed through a safe query builder, or concatenated into executable SQL. The finding's title is only the start of the investigation.

When reviewing a result, trace four facts: the entry point for untrusted input, the propagation path, the sensitive operation, and the control that should stop exploitation. If you cannot explain those four elements, you are not ready to mark the result as a false positive or assign a severity with confidence.

Triage Findings Like an AppSec Engineer

Severity from a tool is a prioritization signal, not a final risk decision. A high-severity finding in unreachable administrative code may deserve less immediate attention than a medium-severity authorization flaw on a public API. Prioritization should account for exploitability, exposure, data sensitivity, business impact, and the availability of compensating controls.

Validate whether the vulnerable path is reachable in the deployed application. Then determine whether an attacker can control the relevant input and whether the sink performs a security-sensitive action. Finally, assess impact. A command injection path running under a privileged service account is materially different from the same pattern in an isolated developer utility.

Use clear resolution states. Confirmed findings should be assigned to an engineering owner with a remediation expectation. False positives should include a concise technical rationale, not just a label. Accepted risks require an accountable owner, a documented reason, and a review date. Fixed findings should be rescanned or verified in code review before closure.

This evidence matters because SAST programs accumulate history. Six months later, another engineer should be able to understand why a finding was suppressed and whether the assumptions behind that decision still hold.

Tune Rules Without Hiding Risk

Every mature SAST deployment requires tuning. The wrong approach is disabling a rule because developers dislike its results. The right approach is identifying why the rule produces noise and adjusting it at the narrowest level possible.

If a rule misidentifies an internal sanitization method, configure that method as a sanitizer only after reviewing its behavior. If generated code creates recurring findings, exclude the generated path rather than suppressing the rule across the repository. If a framework-specific API is safe only when used with a particular configuration, create a targeted rule or review guidance that reflects that condition.

Custom rules are valuable when they protect organization-specific security boundaries. Examples include preventing use of an internal logging method with sensitive fields, requiring a shared authorization helper for certain endpoints, or detecting access to restricted configuration values. However, custom detection logic must be tested like production code. A rule that is too broad will be ignored; one that is too narrow will create misplaced confidence.

Treat suppression comments cautiously. They are useful for a documented, local exception, but they can become permanent blindfolds. Require a reason, a ticket or risk reference where appropriate, and a periodic review of older suppressions.

Integrate SAST Into Pull Requests and CI

A scan that runs only once a quarter finds problems late, when code context has faded and remediation is more expensive. Run SAST in CI on pull requests or merge requests, with feedback attached to the code change whenever practical. Developers can fix a vulnerable API call far faster when the finding appears beside the diff that introduced it.

Do not initially fail every build for every finding. A better rollout is to block merges for new, high-confidence findings in high-impact categories while reporting lower-confidence or legacy findings for review. As rule quality and team confidence improve, enforcement can expand.

Set service expectations with engineering leadership. Define which findings block a release, who owns triage, when AppSec should be consulted, and how exceptions are approved. These workflow details determine whether SAST becomes a useful control or a source of friction.

Measure more than total finding count. Track new findings introduced per release, time to triage, time to remediate confirmed vulnerabilities, false-positive rate by rule, and the percentage of repositories with active scanning. These metrics reveal whether the program is improving engineering behavior rather than simply generating alerts.

Connect SAST to Secure Code Review and Threat Modeling

SAST is strongest when it supports human analysis. Threat modeling identifies the attack surfaces, trust boundaries, assets, and abuse cases that deserve focused attention. Secure code review determines whether controls make sense in the application's actual architecture. SAST adds repeatable coverage across large codebases and catches recurring implementation errors.

Consider an API that processes file uploads. Threat modeling may identify path traversal, malware upload, content-type spoofing, and storage authorization as relevant threats. A SAST rule may identify unsafe path construction. Code review then confirms whether normalization, canonicalization, storage isolation, and authorization checks work together. No single activity provides the full answer.

This layered approach also improves scanner tuning. When your threat model identifies a sensitive sink or a custom validation library, you have the context needed to decide whether a rule should be added, adjusted, or prioritized.

Build Competence Through Repetition

Learning SAST requires more than reading scanner output. Practice tracing tainted data through real code, reproducing confirmed findings, writing secure fixes, and explaining why a false positive is not exploitable. Work across several languages and frameworks when your role demands it, because scan behavior and remediation patterns vary substantially.

For professionals building toward an Application Security Engineer role, a structured program should connect SAST to threat modeling, secure code review, DAST, and vulnerability communication. appsec.training applies that model through focused lessons, hands-on labs, and certification-based validation.

The standard to aim for is simple: every SAST result should lead to an informed engineering decision. When your team can explain the data flow, the risk, the remediation, and the reason for any exception, SAST has become part of how secure software is built.