GitHub code scanning shows critical, high, medium or low only for rules that carry a security-severity property, a score as a string above 0.0 and up to 10.0. Over 9.0 is critical, 7.0 to 8.9 high, 4.0 to 6.9 medium, 0.1 to 3.9 low. Without it, there is no security level to show.
Two different severity ideas in SARIF
SARIF has a level on results and rules, with the values note, warning and error. GitHub's documentation lists those as the valid values for the default configuration level of a rule. That field says how serious a rule is in general terms and shows up as the problem severity.
The security-severity property is separate and lives in the rule properties. GitHub describes it as recommended only for security rules. If you include it, results for the rule are treated as security results.
| Field | Where | Values | Effect on GitHub |
|---|---|---|---|
| level | Rule default or result | note, warning, error | General severity of the finding |
| security-severity | Rule properties | String from above 0.0 to 10.0 | Security level shown as critical to low |
| precision | Rule properties | Documented set of precision values | Combined with severity to order results |
The mapping
The documentation gives the translation of the numeric score exactly: over 9.0 is critical, from 7.0 to 8.9 is high, from 4.0 to 6.9 is medium, and from 0.1 to 3.9 is low. A value of 0.0, or any value outside those ranges, is regarded as having no security severity.
Note that the value is a string, for instance the text 9.8, not a number. A tool that writes a JSON number may not be read as expected, so follow the documented example.
A minimal rule entry
{
"id": "R01",
"properties": {
"security-severity": "9.8"
}
}
That fragment follows the shape of GitHub's own example, where the rule also has name and problem severity fields.
Practical advice for tool builders
- Decide where your score comes from. If your rules map to CVSS, convert the base score to the string form.
- Set security-severity only on security rules. Quality rules should omit it.
- Keep level and security-severity consistent, so a rule that says note does not carry 9.8.
- Do not invent a score for rules you cannot rate. Leaving the property out is more honest than a made up number.
- Document your mapping for users, since two tools can score the same weakness differently.
What users see
GitHub says the score, together with the precision property, determines whether results show by default and in what order. The highest severity and highest precision results come first. So a rule with a high score and poor precision can still bury better findings. Rate both fields with care.
Try it yourself
Click through it at your own pace, or open it full screen. Compare how findings are ranked, and ask whether the top item deserves to be there.
Where this fits
If you choose a static analysis tool, check how it fills these fields. See which SARIF fields matter when choosing a SAST tool. Safeguard offers code and dependency scanning, and the free scan is a quick way to look at real output.
Quick check
What does a security-severity of 9.5 become on GitHub?
Critical, because the documentation maps scores over 9.0 to critical.
What happens if the rule has no security-severity?
There is no security score to translate, so no critical to low level comes from it. Add the property to security rules.
Sources
Last reviewed: 19 October 2026.
