Topic starter
02/08/2026 12:06 pm
TL;DR: Inconsistent vulnerability severities across scanners make automated remediation hard to trust, because the same finding can be scored differently depending on the tool, the asset type, and the context, according to Nucleus. The real shift is from chasing generic criticality to building a defensible, business-aware exposure model that operators can explain and automate.
Editorial analysis by NHI Mgmt Group, based on content published by Nucleus: “Custom Risk Scoring Is the Missing Link Between Disconnected Findings and Real Exposure Management”.
Key questions
Q: How should vulnerability teams handle conflicting severity scores from multiple scanners?
A: They should define a common internal risk model that sits above each scanner's native severity scale.
Q: Why do generic vulnerability scores fail in enterprise environments?
A: Generic scores fail because they assume the same weakness has the same importance everywhere.
Q: What are the signs that exposure prioritisation is breaking down?
A: Common signs include heavy spreadsheet reconciliation, frequent disputes over whether a finding is really critical, and remediation work that does not track business risk.
Practitioner guidance
- Define a single internal risk translation model Map each scanner's output to a common set of business and technical inputs so different severities can be compared consistently.
- Weight exploitability and asset criticality explicitly Use contextual factors such as internet exposure, dependency value, and likely exploitability to override generic severity labels where needed.
- Tie scores to remediation policy and SLA logic Make sure the same scoring model determines prioritisation, ticketing, and due dates rather than leaving each tool to act independently.
Bottom line: Multiple vulnerability tools create a prioritisation problem when each one uses a different scoring model for the same exposure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:10 pm
Custom scoring is a governance layer, not a cosmetic tuning exercise. The core problem in multi-scanner environments is not that teams lack data, but that they lack a defensible rule for comparing signals that were never designed to be compared. A shared internal score creates consistency across vulnerability, cloud, container, and exposure tools. That is a governance decision about risk ownership, not a product feature choice. Practitioners should treat scoring policy as part of the security control stack.
A question worth separating out:
Q: How can organisations make vulnerability scoring auditable and actionable?
A: Link the scoring model to clear policies, remediation thresholds, and owner accountability. Document why weights exist, when overrides are allowed, and which findings trigger escalation. That creates a system leaders can explain to auditors and engineers, while also ensuring the score drives work rather than sitting in a dashboard.
👉 Read our full editorial: Custom risk scoring is closing the exposure prioritisation gap