​

Severity model

Severity describes impact. It does not describe the model’s confidence. A finding can be low severity with high confidence, or critical severity with lower confidence. Severity answers: “How bad would this be if it is real and ships to production?”

​

Severity levels

​

Reach caps impact

Severity is the worst realistic outcome, capped by who can reach it and how far it goes:

• Who can trigger it: anyone, any signed-in account, or only a privileged account; from the internet or only an internal surface. An effect only an admin or an internal surface can reach is medium at most.
• How far it reaches: one user, one tenant, or every tenant. Crossing a tenant boundary is what makes a finding high or critical. The same effect within one tenant is medium.
• What was shown: a real record body rates higher than ids or an empty list, which rate higher than an error with no data.

Code scan findings are rated the same way. A second pass re-derives severity from reachability instead of carrying the scanner’s headline rating, so a vulnerable package used only in tests or tooling is not filed as critical.

​

Severity vs confidence

Confidence is the model’s belief that the finding is valid. Severity is the impact if it is valid. Qodex keeps these separate so a finding can be filtered, sorted, and triaged by impact without hiding uncertainty.

​

Evidence guard

High and critical findings need stronger evidence. Qodex will not file a high or critical finding from exploration without captured proof of the failure. This prevents a stale selector from becoming a false critical issue.

​

Change severity yourself

Your team has the final say. Open a finding on the Findings page, pick a new Severity under Review, write why, and click Save. A severity change needs a reason. The list then shows a set mark beside that severity so readers can tell a person’s decision from the agent’s rating, and a finding your team already reviewed keeps your severity when it is seen again. Click the Severity column header to sort the list worst first.

​

Security scenarios

Security testing uses inverted semantics: pass means the app blocked the attack, and fail means the app may be vulnerable. Severity for security findings reflects the impact of the successful attack. A BOLA issue that reads another tenant’s records is high because it crosses the tenant boundary, even if the test itself is a simple request. The same read between two workspaces of one tenant is medium.

​

Related