SAST, or static application security testing, reads your source code without running it and flags patterns that tend to become security flaws. Think of it as an automated reviewer that checks every change before release. It is cheaper to fix a flaw in a pull request than after customers find it.
What is the one-minute version?
Your engineers write code all day. Some of it will contain mistakes that an attacker can use, such as building a database query from untrusted input. A SAST tool follows data from where it enters the program to where it is used, and warns when the path looks unsafe.
It runs on a schedule or on each change, so it scales without adding headcount. The CFO question is simple: does it reduce the number of flaws that reach production, and at what ongoing effort?
What does it not do?
Be honest about limits, because a CFO who hears "complete coverage" will be disappointed later. OWASP's description of static analysis lists real weaknesses. Authentication problems, access control issues and insecure use of cryptography are hard to find automatically. It often produces false positives. It usually cannot see configuration issues, because those are not in the code. It struggles with code that cannot be compiled, and with flaws that depend on the runtime environment.
That last point matters for budgeting. SAST is one control, not the program. It pairs with dependency scanning, secrets scanning, testing of the running app, and human review for access control logic.
Where does the cost really sit?
The licence is the visible part. The larger cost is engineer time spent reading findings. A tool that produces a thousand alerts and no ranking costs more than one that produces fifty you can act on.
Ask vendors how findings are explained, for example whether a developer can see the path from input to flaw. Ask how suppressions are recorded. Ask how long a first scan takes on your biggest repository.
How should a buyer judge a SAST tool?
Use criteria that survive a procurement review and do not require reading marketing pages.
- Languages and frameworks you actually use. Coverage in a language you do not ship is worth nothing.
- Where it runs. Some teams need the scan to run inside their own network so source code stays put. Others are fine with a hosted scan.
- Signal quality. Ask for a trial on your own code and count how many findings your team agrees are real.
- Workflow fit. Findings should appear in the pull request or the editor, not in a separate portal nobody opens.
- Evidence. Can you export scan history for an auditor?
NIST's Secure Software Development Framework gives buyers and suppliers a common vocabulary for this conversation, which helps when the CFO asks what "good" looks like and needs a neutral reference rather than a vendor's pitch.
What to do
- Write down what you want SAST to prevent, in one sentence, such as injection flaws reaching production.
- List the languages and where source code may be processed.
- Run a trial on one real repository and have two engineers rate each finding.
- Set a rule for blocking: block on high severity in new code, report on the rest.
- Track two numbers for a quarter: findings fixed and time to fix.
- Review at renewal. Drop it or widen it based on those numbers, not on seat count.
Quick check
Can SAST replace a penetration test?
No. Static analysis cannot reliably find many access control and authentication problems, and it cannot see runtime configuration. A penetration test covers gaps the tool cannot.
What single number should a CFO ask for?
Ask for the share of findings your own engineers judge real during a trial on your code, plus the time it takes them to triage a finding.
Sources
Last reviewed: 18 October 2026.
