Every organisation running SAST, DAST and SCA at any scale arrives at the same place: a five-figure count of open findings, a severity distribution shaped like a pyramid, and a developer population that stopped reading the notifications months ago.
The instinct is to attack the number. Burn down the criticals, get the count under some threshold, report progress. It does not work, because the number was never measuring the right thing.
Scanner severity is not your risk
A CVSS score describes a vulnerability class in the abstract. It is calculated without any knowledge of your environment — and it cannot be otherwise, because the people who assigned it have never seen your architecture.
It does not know that the vulnerable function is never invoked in your codebase. It does not know the service has no inbound path from the internet. It does not know the affected dependency ships in a build target you stopped deploying two years ago. And it does not know that the medium two rows down sits in the authentication path of the system holding your customer data.
So when you hand a team a list sorted by severity and tell them it is prioritised, you are telling them something that is not true. They find out quickly — usually by spending a day on a critical that turns out to be unreachable — and after that they discount everything you send.
That loss of credibility is far more expensive than the individual finding. It is very hard to win back.
Three questions that do most of the ranking
You do not need a sophisticated model. Most of the value comes from three questions the scanner cannot answer and your team can:
Is the vulnerable code actually reachable? Not "is the dependency present" — is the path executed. Reachability analysis, where your tooling supports it, routinely eliminates a large share of dependency findings outright. Where it does not, a developer can usually answer in two minutes for their own service.
What does this component touch? A vulnerability in a service holding regulated data is a different proposition from the same vulnerability in an internal dashboard. Your data classification already encodes this — the work is joining it to the finding, not inventing it.
What is the exposure? Internet-facing, internally reachable, or accessible only from a deployment pipeline. This changes the practical exploitability more than most severity adjustments do.
Three questions, applied consistently, and the five-figure list becomes a two-figure list that is genuinely worth someone's week.
Make the matrix theirs, not yours
The temptation is for security to build the risk matrix and hand it over. Do not.
A matrix engineering did not help define is a matrix engineering will argue with, finding by finding, for as long as the programme lasts. You will spend more time defending rankings than fixing anything.
Build it with the delivery leads. Let them push back on the weightings. Accept some you disagree with. What you lose in theoretical precision you gain many times over in the arguments you never have to have — and their version is usually better anyway, because they know which services actually matter.
New findings and old findings are different problems
Worth stating plainly because most programmes conflate them.
A new finding is a change someone is making right now. The author has the context loaded, the code is not yet depended upon, and the fix is minutes. This should block.
An inherited finding is attached to code that shipped and has been running. It is worth fixing, it is not an emergency, and treating it as one destroys your credibility on the findings that are.
Different queues, different SLAs, different conversations. Mixed together, the backlog's volume makes the urgent findings look routine.
What to actually deliver to a team
Not a dashboard. A short, ordered list, in their existing workflow, where every item answers:
- What is wrong, in one sentence, without vendor language
- Why it is ranked here, referring to the matrix they helped build
- What fixing it looks like — the change, not a link to a CVE description
- What happens if they do not
If you cannot fill in the second and fourth lines for a finding, it should not be on the list. That constraint alone will cut most dumps down to something reasonable.
The measure that matters
Not open-finding count. Not mean time to remediate across everything, which averages the urgent with the archaeological and tells you nothing.
Track time to fix for findings introduced this sprint. That number tells you whether the control is working where it is cheap — at the point of change, while the author still remembers what they were doing. If that number is low and stable, the backlog will drain on its own as code gets touched.
If it is high, no amount of dashboard improvement will save the programme, because the pipeline is filling faster than anyone can bail.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.