What it means
SAST inspects program structure without exercising the running application. Some rules recognize risky patterns; others follow data from an input to an operation such as a database query or command execution. A finding can point developers to the relevant location early, when changing the code is relatively inexpensive. Results depend on language support, configuration, build context, and the rule’s understanding of the application. Findings can be incorrect, and real vulnerabilities can be missed. SAST therefore complements review and other tests instead of replacing them.
The idea at a glance / Software
See the code path before running a request.
SAST identifies a suspected path from untrusted input to a database operation by examining code, without executing the target application.
SearchDesk is a fictional teaching fixture with source snapshot C51. Its exact-name search reads request.query.name and joins it into SQL text. Finding A51 is an authored static-analysis example. This picture sends no HTTP request and executes no database query; the source stays unchanged.
READ THE PICTURE
Compare the evidence
A51 follows the name input into SQL text built by joining strings. The suspected operation and source are visible without running SearchDesk. Confirming the runtime conditions and verifying a change are separate work. The code has not been repaired in this picture.
Keep in mindStatic findings need review of reachability, validation, and runtime conditions; tools can miss problems or report infeasible paths. Other code, dependencies, and deployed state are outside this picture. C51 remains unchanged; parameter binding is proposed, with no verified repair or deployment recorded.
Read the complete example
- Compare the evidence. A51 follows the name input into SQL text built by joining strings. The suspected operation and source are visible without running SearchDesk. Confirming the runtime conditions and verifying a change are separate work. The code has not been repaired in this picture. The fixture constructs this SQL text: "SELECT name FROM customers WHERE name = '" + name + "' ORDER BY name". The name comes from request.query.name. It is placed inside the query’s syntax rather than supplied as a bound value. The proposed replacement is "SELECT name FROM customers WHERE name = ? ORDER BY name", with the input bound separately to the placeholder. That separates data from query structure on this path. This comparison does not claim a scanner was rerun, that all findings are correct, or that this change is present in a running build. The DAST example uses the same unchanged C51 fixture to illustrate a different kind of evidence.
Static findings need review of reachability, validation, and runtime conditions; tools can miss problems or report infeasible paths. Other code, dependencies, and deployed state are outside this picture. C51 remains unchanged; parameter binding is proposed, with no verified repair or deployment recorded.
Diagram references: OWASP: Static Code Analysis · OWASP: SQL Injection Prevention
AN ILLUSTRATIVE SCENARIO
A code path that needs review
SearchDesk snapshot C51 reads request.query.name and joins it into SQL text for an exact-name customer search. Authored finding A51 highlights the input-to-query path without running the application. A developer confirms the source, how it is reached, and any relevant validation. A proposed parameterized query keeps the SQL structure fixed and binds the name separately. The shown snapshot remains unchanged. After making a real correction, the team should check both ordinary search behavior and a controlled injection probe, and rerun the configured analyzer.
Put it to work
- Choose tooling that supports the application’s language and build process. Establish a baseline and give each new finding a clear route to the team that can change the code.
- Review the reported source, data flow, and sensitive operation. Reproduce the risk safely where possible, then prioritize by reachable behavior and impact rather than treating the tool label as proof.
- Fix the underlying coding pattern, add a meaningful regression check, and rerun analysis. Keep suppressions narrow, explained, and reviewable when code or assumptions change.
How to check your work
Run the scanner against a small deliberately vulnerable test fixture and its corrected version. Confirm the expected finding changes, then review the real fix and its test independently; a quiet scan alone does not establish security.
Connect the ideas
- DAST
Testing a running application from the outside to find exploitable behavior.
- SCA
Inspection of dependencies and libraries for known vulnerabilities and license issues.
- Vulnerability
A weakness in a system, process, or person that makes a loss easier to cause.