What is a good SAST false positive rate?

Below 20% is considered good. Well-tuned commercial SAST tools achieve 10–15%. Open source tools may have 30–50% without customization. Any rate above 50% typically causes developers to stop reviewing SAST results.

How do I reduce false positive rates?

Customize rules for your frameworks and libraries, suppress known false positive patterns with verification, configure language-specific rules, exclude generated code and test files, and use SAST tools that support flow-sensitive analysis. Running this calculation with a range of plausible inputs can help you understand the sensitivity of the result and plan for different scenarios.

How often should I run SAST scans?

Ideally on every commit or pull request for incremental analysis, and full scans weekly or per release. CI/CD integration ensures consistent scanning without manual effort. Incremental scans are faster and more developer-friendly.

Should I use multiple SAST tools?

Multiple tools increase coverage but also increase false positives and operational complexity. One well-tuned primary tool is usually more effective than multiple poorly configured tools. Add a second tool only if your primary tool has known blind spots.

What is the difference between SAST and DAST?

SAST analyzes source code without executing it (white-box). DAST tests the running application from outside (black-box). SAST finds coding errors early; DAST finds runtime and configuration issues. Both are complementary and recommended.

How do I measure SAST ROI?

Track: cost of findings discovered by SAST vs. cost if found in production (10–100x multiplier), reduction in production security incidents, developer time saved by early detection, and compliance requirements met through automated scanning.

SAST Finding Rate Calculator

Calculate static analysis finding rate and false positive rate from SAST scan results. Track true vs false positive trends over time.

Total Findings

Scans Performed

False Positives

Critical

High

Medium

Low

Scan Type

Avg Remediation Time

min

Dev Hourly Rate

True Positive Rate

60.00%

192 actionable findings

False Positive Rate

40.00%

128 wasted triage items

Findings per Scan

26.7

per full scan

Actionable per Scan

16.0

true positives only

Remediation Cost

$10,800

144.0 dev hours total

Cost per Finding

$56.25

avg remediation cost each

FP Triage Waste

$2,400

32.0 hours at ~15 min each

Total SAST Cost

$13,200

remediation + FP triage

Severity Distribution

Critical

2.5%

High

12.5%

Medium

37.5%

Low

47.5%

Scan-over-Scan Projection

Scan #	Cumulative Findings	True Positives	False Positives	Remediation Cost
1	27	16	11	$900
2	53	32	21	$1,800
3	80	48	32	$2,700
4	107	64	43	$3,600
5	134	80	54	$4,500
6	160	96	64	$5,400
7	187	112	75	$6,300
8	214	128	86	$7,200
9	240	144	96	$8,100
10	267	160	107	$9,000
11	294	176	118	$9,900
12	320	192	128	$10,800

Industry Benchmarks

Metric	Good	Average	Poor
False Positive Rate	< 20%	20-40%	> 40%
Findings / Scan	< 10	10-50	> 50
Critical %	< 5%	5-15%	> 15%
Avg Remediation	< 30 min	30-60 min	> 60 min

Planning notes, formulas, and examples

About the SAST Finding Rate Calculator

Static Application Security Testing (SAST) tools scan source code to find vulnerabilities before runtime. While essential for shift-left security, SAST tools are notorious for high false positive rates that can erode developer trust and slow remediation. Tracking the ratio of true to false positives across scans is crucial for tuning tools, measuring effectiveness, and maintaining developer confidence.

This calculator helps you analyze SAST scan results by computing the finding rate (findings per scan), false positive rate, true positive rate, and actionable finding density. Enter your total scan results and confirmed false positives to see how effective your SAST configuration is and where tuning is needed.

When This Page Helps

A high false positive rate wastes developer time triaging non-issues and causes alert fatigue, leading teams to ignore real findings. Tracking these metrics helps you tune SAST rules, demonstrate security testing ROI, and maintain a productive relationship between security and development teams.

How to Use the Inputs

Enter the total number of findings from SAST scans.
Enter the number of scans performed.
Enter the number of confirmed false positives.
View the finding rate, false positive rate, and true positive rate.
Track these metrics over time to measure SAST tuning effectiveness.

Formula used

Finding Rate = Total Findings / Number of Scans. False Positive Rate = False Positives / Total Findings × 100. True Positive Rate = (Total − False Positives) / Total × 100. Actionable Findings = Total − False Positives.

Example Calculation

Result: FP Rate: 40% | 26.7 findings/scan | 192 true positives

From 12 scans producing 320 total findings, 128 were confirmed false positives (40% FP rate). This leaves 192 actionable findings (16 per scan). A 40% FP rate is typical for uncustomized SAST tools but should be reduced through rule tuning to below 20%.

Tips & Best Practices

Target a false positive rate below 20% to maintain developer trust.
Tune SAST rules incrementally — suppress only confirmed false positive patterns.
Use SAST findings in code reviews to build security awareness.
Track finding rate per language/framework to identify areas needing custom rules.
Integrate SAST into CI/CD for continuous, automated scanning.
Prioritize remediation by severity: fix critical/high first, then medium.

SAST Metrics That Matter

Beyond false positive rate, track: detection rate (what percentage of known vulnerabilities does the tool find), fix rate (what percentage of findings are remediated), mean time to remediate, and finding recurrence rate.

Tuning for Effectiveness

Effective SAST tuning is iterative: run scans, review findings, confirm true/false positives, adjust rules, and measure the impact. Focus on eliminating high-volume false positive patterns first for maximum efficiency gain.

Developer Experience

SAST adoption depends on developer experience. Provide findings in the IDE, include fix guidance, and never block builds on false positives. A developer-friendly SAST workflow dramatically improves remediation rates.

Integration Best Practices

Run incremental SAST on pull requests (fast, focused feedback) and full scans on main branch merges (comprehensive coverage). Gate merges on critical/high findings only to avoid blocking development velocity.

Sources & Methodology

Last updated: February 8, 2026

Frequently Asked Questions

Below 20% is considered good. Well-tuned commercial SAST tools achieve 10–15%. Open source tools may have 30–50% without customization. Any rate above 50% typically causes developers to stop reviewing SAST results.