Every finding is urgent. That is the problem this solves.

On a 100-point scale from four weighted factors: critical findings contribute up to 40 points, high findings up to 25, exposure level up to 8, and asset criticality up to 5. Every report shows the breakdown, so a score of 78/100 arrives with the arithmetic that produced it. The weights are published deliberately. A score you cannot decompose is a score you cannot defend to engineering.

No. Every finding carries its CVSS 3.1 score and full vector string, unmodified. Contextual weighting is applied as a separate layer on top, never by editing the base score. You always see both numbers, which is what keeps the finding portable to your other tooling and acceptable to an auditor.

Because exposure and asset criticality differ. An internet-facing production system holding customer data and an internal staging instance with test data are not the same risk, even running the identical vulnerable component. CVSS scores them identically by design, because a portable score has to be context-free. Prioritisation cannot afford to be.

You do. No scanner can know which of your systems matters most. The low-traffic internal service holding payment reconciliation logic looks unremarkable from outside. Setting criticality accurately is the highest-leverage configuration on the platform, because it is the input that most changes the ordering.

Findings that reach confirmed status were exploited, with the request, response and a reproducible curl command captured. That is observation rather than estimation, and it removes the usual triage question of whether something is genuinely exploitable in your environment. Where a finding cannot be safely exploited, it is reported without that proof, and proven and predicted are kept distinct rather than blended into one number.

They move to accepted, with the person, the date and the reason recorded. Accepting risk is a legitimate decision; the platform's job is to make sure it was a decision rather than a finding that quietly stopped being discussed. When an audit asks why a High from March is still open, the record is the answer.

Findings close only when the exploit stops working on retest, and reports carry trend comparison against previous assessments. That makes the 100-point score a tracked measurement over time rather than a snapshot, which is what turns it into something reportable to a board.

It moves when the evidence does. A completed assessment produces the score, and a retest that closes a finding changes it, which is what makes the trend comparison between reports meaningful. Between runs it is a measurement with a date on it rather than a live gauge, and treating it as the latter is how a number ends up on a dashboard describing an application that has since shipped four times.

No, and this is the reason the weights are published rather than described as proprietary. You can see each factor, its contribution and the resulting total. Where the model is wrong for your environment, you can identify which factor is wrong and say so specifically, which is more useful than a number nobody can interrogate.

Yes. The four factors and their weights are configurable per environment, and a security team that treats a regulated database as categorically more important than an internal tool should say so rather than argue with the default. Two guardrails: a change re-scores the whole backlog rather than only new findings, so the queue stays internally consistent, and the previous weighting is kept alongside it, so a finding that moved can be shown to have moved because the policy changed and not because the evidence did.