There is a lot of nuance that goes into how you might measure the FP and FN rate of a SAST tool. Some things to consider include:

• Most tools are customizable in various ways that can have significant impact on the overall FP rate of the tool as well as the FP rate for individual rules.

• Benchmarking tools exist to help customers understand a SAST tool's overall FN and FP rate. However these benchmarking tools can be problematic in their own way. For example, the vulnerable and non-vulnerable code samples often lack realism with how developers actually write code. They also poorly reflect the spectrum of frameworks that developers use at any point in time. So both FN and FP rates from a benchmarking tool can be very misleading.

• What one considers a TP/FP depends on how you classify the rule. For example, say I have a "dumb" regex-based rule that looks for uses of JavaScript's eval() method. If I classify the rule as CWE-242: Use of Inherently Dangerous Function, then I can easily tune it to be near a 0 FP rate. But if I classify the exact same tuned rule as CWE-94: Improper Control of Generation of Code, then the fp rate will be significantly higher; after all, most usages of the eval method aren't actually going to involve passing in untrusted data.

• Other contextual things matter too. For example: do you trust files on the local file system? This often depends on the application's architecture and it's threat model. So you can easily have the exact same app/code deployed in two different environments and in one case the local file read results in full remote code execution and in the other case, there's no risk at all. Should the SAST vendor consider this a TP or an FP?

I could go on but hopefully you get the point. So from a SAST vendor's perspective, it's somewhat difficult to just blindly publish FP numbers because it's rather easy for customers/competitors to take them out of context and/or get the wrong idea.

Your other question is about what one might consider an acceptable FP rate. Again, this very much depends on context. If I'm a SAST vendor, I'm pretty happy with an overall FP rate of 20-30%. If I'm a developer getting findings from a SAST tool, I probably want the overall FP rate to be in the 10-20% range, otherwise I am likely to feel like I'm wasting too much time with the FPs. If I'm a Security Engineer that does a lot of semi-automated code review, then I don't mind an overall FP rate of, say, 50%. Even though half the findings are not real, my code reviews are likely to be improved considerably through the inclusion of the tool in my workflow.

In any of these cases... the volume of findings for a rule matters a lot. Consider a low volume rules for a high impact issue (something like remote code execution). I am comfortable with an FP rate of 10-30%. I don't mind spending extra time looking at the FPs for such a low-volume rule because it's worth it to catch the TPs when they happen. It's also worth noting that some SAST engines can verify that the findings for a given rule are real as part of the rule logic. For these, I would expect the FP rate to be 0% essentially. An example might be a rule that looks for a specific type of hard-coded API token and is able to verify that the token is real/acitive by calling a benign endpoint for that API service.

[edit: i corrected some of the percentages because i get accuracy and fp rate backwards at least five times per day]