How risk is scored
The rules behind the severity number, and why the model cannot lower it.
Severity is calculated by rules you can read, not by the model. The model contributes its own estimate, and the higher of the two wins — so a security keyword cannot be talked down by a confident-sounding narrative.
Levels
| Level | Score |
|---|---|
| CRITICAL | 80 or more |
| HIGH | 60–79 |
| MEDIUM | 35–59 |
| LOW | below 35 |
What adds points
| Factor | Points |
|---|---|
| Production environment | +20 |
| Staging environment | +5 |
| Fatal level | +30 |
| Error level | +20 |
| Warning level | +10 |
| Seen more than 1,000 times | +30 |
| Seen more than 100 times | +20 |
| Seen more than 10 times | +10 |
| More than 100 users affected | +30 |
| More than 10 users affected | +20 |
| More than 1 user affected | +10 |
| First seen under 10 minutes ago | +15 |
| Last seen under 5 minutes ago | +10 |
| Mentions password, secret, private_key, or api_key | +40 |
| Mentions SQL injection, XSS, or CSRF | +50 |
| Mentions payment, checkout, invoice, or transaction | +30 |
| Mentions login, auth, jwt, token, or session | +25 |
| Mentions memory, heap, or out of memory | +25 |
| Mentions database, mongo, mysql, postgres, or connection | +20 |
| Mentions timeout, econnrefused, or connection refused | +15 |
| Backend platform (node, python, ruby, java, go, php) | +15 |
| Any other recognised platform | +5 |
Because environment contributes, the environment you choose when creating a project changes how loudly it can page you. Marking a staging project as production is the quickest way to make alerts meaningless.