Some maintainers decline to score their own vulnerabilities because impact depends on how the code is used. The Go Security team issues CVEs without severity labels or CVSS scores for that reason. Third parties may still add scores, so consumers should judge impact against their own use of the affected function.
The argument
The Go Security Policy says the team does not assign fine grained severity labels such as critical, high, medium or low, because severity depends heavily on how a user is using the affected API or functionality. It also says it does not assign CVSS scores when issuing CVEs, stating it fundamentally disagrees with the applicability of the scoring system to Go for the same reasons. Third parties such as MITRE or NIST, via the National Vulnerability Database, may assign scores, but the team says it does not endorse them as accurate reflections of impact.
The policy gives an example. A resource exhaustion issue in a JSON parser has low impact if you parse trusted files from a local disk, and may have much higher impact if you parse arbitrary JSON from an HTTP request body.
What the project does instead
The policy says its issue tracks signal how severe or wide reaching the team believes an issue is. A medium to significant impact for many users is a private track issue, and a negligible or limited impact is public track. So there is a signal, just not a number.
| Source of signal | What it tells you |
|---|---|
| Maintainer track or advisory text | The team's view of breadth and impact |
| Third party score | A generic estimate that may not fit your use |
| Your own code | Whether you call the affected function with untrusted input |
What this means for your triage
If an advisory has no score from the maintainer, do not default to the highest or the lowest. Look up the affected function and check if your code calls it. Check what data reaches it. Check if the code runs in an internet facing service. A reachability check on your own code answers the question the maintainers say they cannot answer for you.
Steps
- Read the advisory text, not just the score field.
- Note whether any score shown came from the maintainer or from a third party.
- Find where your code uses the affected package or function.
- Decide if untrusted input can reach it.
- Record your reasoning in the ticket so a reviewer can follow it.
- Set the fix deadline from your own risk, using your policy's categories.
For maintainers
You can follow the same logic without refusing scores. Say what the issue affects, which uses are exposed, and which are not. Plain advice on who needs to act is often worth more than a number.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how checking whether code actually reaches a vulnerable function changes the list, and compare that with relying on a generic score.
Quick check
Does no score mean not serious?
No. The project signals impact through its tracks and advisory text instead.
Can I still see a score somewhere?
Third parties may assign scores, but the policy says the team does not endorse them as accurate.
What should I use instead?
Your own context: whether you call the affected code with untrusted input.
How Safeguard helps
Safeguard's zero-day discovery and dependency scanning watch for newly published issues in the components you actually use, and reachability analysis helps you judge whether your code touches the affected path. Policies and gates can hold a risky version out of a release. Autonomous remediation can open fix pull requests; it is off by default, with every category on Manual. Start with the free scan.
Sources
- The Go Project, Go Security Policy: severity and CVSS statement, tracks and example. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
