Prioritising and remediating: understanding CVSS scores

Any real application has more problems than any team can fix in a week. The question is never “can we fix everything?” but “what do we fix first?”. A fair, consistent way of rating vulnerabilities helps teams make that decision. The most widely used system is CVSS, and understanding it also helps you read the CVE entries we met in chapter 6.

What is CVSS?

The Common Vulnerability Scoring System (CVSS) is an open standard for describing the characteristics and severity of a vulnerability. It produces a number between 0.0 and 10.0, together with a compact text string (a “vector”) that records how the score was calculated. Several versions have been published; recent versions are in use side by side, so always note which one a score refers to. The National Vulnerability Database at nvd.nist.gov displays CVSS scores for CVE entries and offers calculators to try it yourself.

The standard severity bands are:

Score	Rating
0.0	None
0.1 – 3.9	Low
4.0 – 6.9	Medium
7.0 – 8.9	High
9.0 – 10.0	Critical

The base metrics: reading the building blocks

The score is computed from a handful of questions about the vulnerability. The names vary slightly between versions, but the ideas are the same. Think of them in two groups.

How hard is it to exploit?

• Attack vector: from where can it be attacked? Over the internet (network), from a neighbouring network, only with local access, or only with physical access. The more remote, the higher the risk.
• Attack complexity: does it work straight away, or does it need special conditions that are outside the attacker’s control?
• Privileges required: none, a low-privilege account, or an administrator?
• User interaction: does a victim have to do something, such as click a link? XSS reflected needs it; many server-side flaws do not.

How bad is the impact?

• Confidentiality: how much information could be exposed?
• Integrity: how much data could be altered?
• Availability: how much could service be disrupted?
• Scope: can the impact spread beyond the vulnerable component to others?

Each question has a few possible answers (for example none, low, high) and the formula combines them into a number. You do not need to remember the formula; you need to understand the questions, because they reveal why two flaws with the same name can deserve different ratings.

Two examples

Consider two fictional XSS findings.

	Finding A	Finding B
Description	Stored XSS in a product review, displayed to all visitors and to administrators	Reflected XSS only reachable in a page requiring login, needing the victim to click a long link
Privileges required	Low (any account can post a review)	None, but the victim must be logged in
User interaction	None beyond viewing the page	Required
Impact	Admin session could be hijacked: high confidentiality and integrity	Limited actions of the victim’s own account
Likely rating	High	Medium

Same vulnerability class, different priorities. CVSS gives a structured way to explain why.

Limits of CVSS

CVSS is a useful tool, not an oracle. Be aware of its limits.

• It measures technical severity, not business risk. A medium-scored flaw in the payment system may matter more to the organisation than a high-scored flaw in a test server with no data.
• The base score ignores context. It does not know whether the system is exposed to the internet, whether compensating controls exist, or whether exploit code is in circulation. Optional temporal and environmental metrics let you adjust for this, and many organisations use them.
• It involves judgement. Two reasonable people can choose slightly different values and get different scores. Document your reasoning.
• It rates single vulnerabilities, not chains. Three medium findings that can be combined into account takeover may represent a high overall risk. Report the chain explicitly.
• Scores do not tell about likelihood. Whether attackers are actively exploiting a flaw is a separate, important factor. Public lists of vulnerabilities known to be exploited, kept by national security agencies, help to prioritise.

A practical prioritisation approach

A sensible way to combine these ideas is to ask four questions for each finding.

1. Severity: what is the CVSS rating, or your own consistent rating scale?
2. Exposure: who can reach it? The open internet, any customer, only administrators, only the internal network?
3. Value at stake: what data or function does it protect? Personal data, payments, administration, or a low-value feature?
4. Effort and quick wins: how hard is the fix? Some high-impact flaws are fixed by a one-line change; those go first.

Then group findings into a roadmap: immediately (critical, easily reachable, high value), short term (high and medium with simple fixes), planned (larger architectural changes) and accepted risk (documented, with an owner and a review date, when the organisation consciously decides not to fix something).

Remediation: how fixes are handled

Remediation is a process with its own steps. As a tester, you contribute at several stages.

1. Triage. The team confirms the finding, assigns an owner and a priority. Be available to clarify.
2. Fix. Developers implement the recommended change. Where possible, fix the root cause (for example, parameterised queries across the code base) and not only the one case you found.
3. Mitigate in the meantime. If a full fix takes time, a temporary measure can reduce risk: disabling a feature, adding a restriction, or increasing monitoring.
4. Retest. Verify that the fix works by repeating the original reproduction steps and checking for related variants. Update the finding’s status to “fixed” or “not fixed”.
5. Learn. Feed the finding back into secure development: coding guidelines, automated tests, training, and checks in the delivery pipeline.

Defence in depth

You have seen throughout the course that no single control is enough. Strong remediation layers several: fix the code (primary control), add secondary controls (headers, CSP, least privilege), add detection (logging and alerts) and prepare response (an incident plan, which the French national agency ANSSI and cybermalveillance.gouv.fr describe in their public guidance). The NIST Cybersecurity Framework at nist.gov offers a widely recognised way to organise these activities: identify, protect, detect, respond and recover.

Your turn: rate and rank your findings

Take your lab findings (at least six). For each, answer the CVSS-style questions informally (attack vector, complexity, privileges, interaction, impact on confidentiality, integrity and availability), choose a rating from Low to Critical, and add a one-sentence justification. Then order the findings into a four-column roadmap: immediately, short term, planned, accepted risk. Optionally, try the NVD calculator with a few of them.

See a solution

An illustrative extract:

Finding	Rating	Justification	Roadmap
SQL injection in the search	Critical	Network, no account needed, read and modify database content	Immediately
IDOR on orders	High	Any customer reads others’ personal data	Immediately
Reflected XSS in the search heading	Medium	Needs a victim to click; limited to the victim’s session	Short term
Missing security headers	Low	Defence in depth, no direct exploit	Short term (configuration)
Verbose server banner	Low	Information disclosure only	Planned

Note that the first two share a root cause family, a missing server-side check, so a single pattern fix and a training session could address many instances.

What if you find a vulnerability in a system that nobody has asked you to test? That is where bug bounty and responsible disclosure come in.