SAST tools: what static code scanning can catch
SHORT ANSWER
SAST tools inspect application code without running the application to find potential security weaknesses. SetRepo includes SAST capabilities in its source-code scans, using bundled static rules and structural checks. It also offers separate secret, dependency and live-site checks; paid Deep scans add AI review of selected code. Static findings need confirmation and do not prove runtime exploitability.
What are SAST tools in plain language?
SAST tools read application code to look for security weaknesses without starting the application.
SAST stands for static application security testing. A tool may match a dangerous pattern, examine code structure or track how input reaches a sensitive operation. For example, it may notice a request parameter being joined into a SQL query instead of passed as a parameter. OWASP's source-code analysis overview explains the strengths and limits of this approach.
Static analysis can be useful before deployment because it can point to a file and line to review. It still needs enough language, framework and library knowledge to interpret that code correctly.
What can static code scanning catch?
Static scanning can flag supported unsafe patterns and missing protections visible in the supplied source.
Examples to investigate include:
- Request input concatenated into a database query rather than bound as a parameter.
- A privileged server route with no recognized authorization guard.
- A payment handler that accepts the browser's price instead of calculating it from server records.
- Permissive database policies present in the repository's configuration or migrations.
These examples describe code-review questions, not guaranteed detection across every framework. For a price finding, trace where the total comes from and whether the payment provider uses a server-calculated value. For an authorization finding, inspect the route and its middleware before deciding that a guard is absent. Read the client-trusted prices guide for a concrete example.
Does SetRepo include SAST capabilities?
Yes: SetRepo's source-code pipeline runs static rules and structural checks without building, installing or executing the submitted application.
Its Quick scan uses bundled Opengrep rules and additional source checks. The pipeline also integrates Bandit for Python and ESLint security checks where applicable. SetRepo builds an inventory of supported server routes and their guards to support access-control analysis. Coverage depends on the language, framework, rule and files supplied; the presence of a source file does not imply complete analysis of it.
Opengrep uses SetRepo's bundled rules rather than automatically selecting a public registry ruleset. Its taint analysis can follow input through helper functions within the same file; that is not unrestricted tracing across the whole application. Oversized or unparseable files, analysis timeouts and unsupported rule coverage can leave gaps that need review.
These capabilities support describing SetRepo as a scanner with SAST capabilities. Its secret checks, dependency advisory checks and live-site observations are additional forms of analysis, not interchangeable names for SAST.
How is SAST different from a live website scan or AI review?
SAST examines code, live website checks observe the deployment, and AI review evaluates selected code context with a model.
A source rule can flag an unsafe handler even when the site is not deployed. A live scan can see a header added by the hosting layer even when that configuration is absent from the repository. Neither input gives a complete picture alone. The website scanner's coverage explains what SetRepo can observe from a URL.
SetRepo's paid Deep scan adds AI review of selected handlers, supporting code and data-model context for object-level access and business logic, plus review of uncertain critical and high pattern findings. Quick scans do not use that AI security review. Deep is not a complete reading of every file and can misinterpret intent. See how AI-assisted scanning works and how code is handled.
How should I evaluate and use a SAST tool?
Evaluate a SAST tool against the code and review workflow you actually maintain, then confirm findings in context.
- Check language, framework and rule coverage for your app's sensitive operations, not just a list of supported file extensions.
- Provide the current source and relevant configuration. Production settings stored elsewhere will need a separate review.
- Inspect findings at the reported location, including helper functions and middleware that could change their meaning.
- Read coverage notes for skipped files, tool failures and unsupported patterns. No findings from a failed check is not a clean bill of health.
- Fix confirmed weaknesses in your development workflow, verify the affected behavior and rescan.
With SetRepo, connect a GitHub repository or upload a ZIP, review setup and choose Quick or Deep. Review scan pricing before authorizing processing.
What cannot a SAST result prove?
A SAST result cannot prove that an issue is exploitable at runtime or that an application is secure.
Static analysis can miss custom guards, indirect data flows and business intent. It cannot observe production-only settings that are not supplied. SetRepo does not log in as different users, run application workflows or perform a full penetration test, and it does not provide malware detection.
For example, a route may check login while omitting ownership checks on individual records. Manually verify account boundaries with separate users even after scanning. Read how vulnerability scanners differ from penetration tests, then start a repository scan to collect source-level evidence.