Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
The SAST backlog for the customer-support portal has grown past the point anyone reads it, and the proposed fix is to mute the low-severity rules and let the tool auto-close whatever it scores low. This post shows a better lever: rank findings by reachability and exposure so that engineers work the right bugs first, while every real bug stays visible and every risk decision has a person’s reason behind it.
A SAST false positive incorrectly reports a weakness. A real weakness with low exposure, compensating controls or accepted risk is not automatically a false positive. Ranking helps manage attention but does not improve detector precision by itself. Improve rules and framework modelling, while using ranking to order findings by reachability and exposure, keep every finding visible and countable, and require a named person and recorded reason for false-positive and accepted-risk decisions.
The portal makes a useful test case. It has a public ticket form that anyone can submit, an agent console behind single sign-on, and an internal export job that runs overnight with no external ingress. Suppose the taint engine reports the same kind of unsanitised query construction in all three. The findings are equally real as code, but they are not equally urgent.
Ranking reorders the backlog; suppression deletes part of it
Suppression removes findings from view according to a rule written in advance about which categories are unimportant. Ranking reorders the complete list so that the highest-confidence, highest-impact findings surface first, while every other finding stays present, counted and reviewable. One optimises for a shorter list. The other optimises for the right thing being at the top of a list that remains complete.
The difference is practical. A suppression is a decision made once, in the abstract, and applied to every future instance, including the one where the pattern is genuinely exploitable. If the portal team mutes the query-construction rule below a chosen severity, the ticket-form flaw disappears along with the export-job one. A ranked finding can still be disputed or reviewed in bulk when the team has capacity, and it stays in the audit trail as something that was seen and assessed.
Reachability and exposure should move SAST findings, not remove them
Two signals shift a finding’s rank the furthest without deleting anything. Reachability asks whether an entry point an attacker controls can reach the vulnerable path, traced through the call graph rather than assumed from a risky call somewhere in the file. Exposure asks whether the artefact carrying that code is deployed somewhere reachable from outside its intended trust boundary.
Applied to the portal, the ticket-form flaw is reachable from unauthenticated input and exposed to the internet, so it goes to the top. The agent-console flaw is reachable only after sign-in, so it ranks below. The export-job flaw is real but has no external entry point, so it sits lower still. All three remain in the backlog, and anyone preparing audit evidence can still sort the full list by severity alone. The same signals apply well beyond first-party code, as risk-based vulnerability management with reachability explains.
Disposition is a judgement, so a person must make it
Ranking is a computed estimate. Disposition is different in kind: it is the decision that a finding is a true positive to fix, a false positive because something the analysis did not model protects the path, or an accepted risk with a documented reason. It settles the finding’s status, and it is the record an auditor will ask to see.
Keeping disposition human-only, with a mandatory reason code for every call, does two things. It puts a name and a rationale behind every closure, which is what survives a post-incident review; “the pipeline scored it low” does not. It also keeps the ranking honest, because the ranking’s only job is to help a person choose what to read first. Once a model or rule engine can close findings itself, the pressure to tune it towards a smaller open count, rather than towards accuracy, becomes hard to resist.
Closing on a low score can hide a bad ranking
Closing solely because of a low score looks like the ranking problem solved: the backlog shrinks, the dashboard goes green and the triage meeting gets shorter. What it removes is the one check that catches a wrong ranking before it becomes permanent. Reachability models make mistakes, such as an unrecognised sanitiser, a framework behaviour they do not model, or a call path added by a refactor they have not yet analysed.
Suppose a refactor quietly routes ticket-form input into the export job’s query builder. If a person reviews the low-ranked export finding, the wrong rank costs a few minutes of attention. If the finding closed itself, the record says it was resolved and nobody looks again. A good ranking system tells a team what to read first this week; it does not persuade the team to stop reading the rest.
Measure SAST precision by what reviewers decide
The honest test of a ranking approach is what happens after a person looks at a finding. Track how often top-band findings are dispositioned as true positives, how often low-band findings turn out to be misranked when someone does review them, and how false-positive reason codes cluster. A recurring “sanitiser not recognised” reason points at a gap worth fixing in the analysis, not at the individual findings.
None of this is a claim about an absolute detection rate, since no static analysis tool can prove it has found every real bug and nothing else. It is a claim that the ranking agrees with what informed people decide, and the disposition history lets you check that directly instead of trusting the tool’s own confidence score. The source-to-sink tracking behind these findings is explained in SAST taint analysis explained.
Key takeaways
- Replace category-wide suppressions with ranking, so that no finding leaves the backlog without a decision.
- Order SAST findings by reachability and exposure, and keep severity-only sorting available for audit reviews.
- Require a named person and a reason code for every true-positive, false-positive or accepted-risk call.
- Review false-positive reason codes regularly and feed recurring patterns back into the analysis.
How SecurityVault approaches this
SecurityVault combines native analysis and supported scanners with available code and deployment context. Ranking helps reviewers choose what to inspect; it does not make a low-ranked finding false. Human false-positive and accepted-risk decisions require a reason. Separate evidence-based lifecycle updates can follow successful re-scans, while preserving human-held decisions.
Pick a small set of findings your engineers have already investigated, including a confirmed weakness, a detector mistake and a real issue with low deployment exposure. Compare their evidence, rank and disposition options. Then change the relevant code and run another scan to inspect the lifecycle record. This tests whether the workflow preserves the distinction between accuracy, urgency and remediation. Reviewers should be able to explain why a finding moved or closed without assuming that a lower score means the underlying weakness was never real.
Explore SAST or talk to our team about an evaluation with your engineering, security and compliance stakeholders.