Static application security testing (SAST)
SAST analyses source code without running it to find security flaws such as injection. How it works, its limits, and how AI CodeOps' diff review relates to it.
Static application security testing (SAST) analyses an application's source code, bytecode or binaries without running it, to find security weaknesses such as injection flaws, unsafe deserialisation or hard-coded credentials. It's "white-box" testing: the tool sees the code, not a running system.
What it is
A SAST tool parses the code and applies rules: data-flow analysis that follows untrusted input to a dangerous call, pattern matches for risky APIs, configuration checks. Each match becomes a finding with a rule ID, a location and a severity. Because nothing runs, SAST can scan every branch and give file-and-line results early, often on each pull request.
Its known weaknesses are false positives, and blind spots for flaws that depend on runtime behaviour or business logic. Dynamic testing (DAST) and software composition analysis cover other ground.
Why it matters
Security bugs are cheapest to fix before they merge. SAST in the pull request puts the finding in front of the author while the change is still fresh. With AI agents writing code, a second pair of eyes that doesn't trust the author matters even more.
In AI CodeOps
AI CodeOps doesn't include a SAST engine. What it has is an AI security review of every change's actual diff, which is static (nothing is executed during the review) but model-based rather than rule-based. Keep your SAST tool; the two catch different things.
How the review works:
- The Security Auditor runs in nine of the sixteen built-in workflows, for example Security-Sensitive Change: Scope change, Risk analysis, Implement, Audit diff, Validate.
- After the change is written and tested, a findings pass reads the diff, with the review and audit notes as context, and records up to 12 findings.
A blocking security finding, as your CI sees it in the release check response:
{
"severity": "high",
"category": "security",
"title": "Coupon code is passed to the pricing query without validation",
"agentID": "security-auditor",
"filePath": "src/api/checkout.ts"
}
Open findings of severity high or critical block the pull request and a merge from the console. If the review can't finish, the change is held: "The automated review of this change didn't complete, so its findings are unknown. Re-run the session". Secure → Security lists open security findings by severity, and Fix with AI starts a session aimed at one.
To make your SAST tool and AI CodeOps agree, fail the CI job if either says no: your scanner's exit code, and allowed: false from POST /api/release/check.
Related terms
- Quality gate: where findings become a pass or a block.
- Secrets scanning: a check SAST tools often include.
- Multi-agent system: why the reviewer isn't the agent that wrote the code.
Frequently asked questions
Is the AI CodeOps security review a SAST tool?
No. It's a language model reviewing the diff, not a rule-based analyser. Run your SAST tool in CI as well and let both feed the gate.
Do security findings block the pull request?
Yes, at high or critical severity, while they're open, acknowledged or in progress. Triage them as fixed, won't fix, false positive or duplicate to clear them.
How many findings can one review record?
Up to 12. An empty list means a completed review that found nothing; a review that didn't finish holds the change.