Skip to main content

Severity Model

1. Purpose​

This model keeps PCL severity language consistent across advisories, reports, and coordination notes. It prevents common failure modes: CVSS-only thinking, hype-driven severity, under-described prerequisites, and conflating technical severity with operational priority.

2. Severity vs Priority​

Severity describes the intrinsic and contextual security consequence of a vulnerability.

Priority describes how urgently a defender should act in a specific environment.

A medium-severity vulnerability may be high priority when it is actively exploited, internet-facing, easy to chain, or present on a critical asset. A critical vulnerability may be lower immediate priority when it affects an isolated lab-only component with compensating controls.

3. Required Fields​

A PCL severity assessment should include:

  • severity label;
  • confidence level;
  • affected security properties;
  • attacker position;
  • required privileges;
  • user interaction;
  • attack complexity;
  • affected scope;
  • evidence basis;
  • exploit maturity;
  • known exploitation status;
  • remediation status;
  • limitations.

4. Labels​

Informational​

Security-relevant observation without direct exploitable impact in the assessed context.

Examples:

  • minor header omission without practical impact;
  • version disclosure with no known affected vulnerability;
  • best-practice deviation without demonstrated consequence.

Low​

Limited impact, significant prerequisites, narrow exposure, or strong compensating controls.

Examples:

  • low-sensitivity information exposure;
  • self-contained user-context behavior;
  • local-only issue requiring unusual conditions.

Medium​

Meaningful security impact with realistic prerequisites, limited scope, or partial mitigation.

Examples:

  • authenticated data exposure within a bounded class;
  • moderate authorization flaw;
  • denial-of-service in a non-critical component;
  • misconfiguration enabling targeted abuse under specific conditions.

High​

Material confidentiality, integrity, or availability impact with practical exploitation conditions.

Examples:

  • cross-tenant data exposure;
  • privilege escalation within a production service;
  • unauthenticated access to sensitive functionality;
  • reliable service compromise with meaningful prerequisites.

Critical​

Severe impact with broad exposure, low attacker requirements, systemic reach, or safety/critical-service consequences.

Examples:

  • unauthenticated remote code execution on internet-facing systems;
  • mass credential compromise;
  • wormable or highly automatable compromise path;
  • control-plane compromise affecting many tenants;
  • safety-impacting system manipulation.

5. Confidence Levels​

Confirmed​

Validated by vendor, patch, deterministic authorized reproduction, or multiple independent high-quality evidence sources.

Probable​

Strong evidence supports the finding, but some affected-version, exploitability, or environmental detail remains unconfirmed.

Limited​

The issue is plausible but evidence is incomplete, indirect, or environment-specific.

Unverified​

The claim is not mature enough for publication except as an explicitly labeled intake or research note.

6. Scoring Inputs​

PCL may use external scoring systems as inputs:

  • CVSS v4.0 or v3.1 for structured technical characteristics;
  • EPSS for exploitation probability signal;
  • CISA KEV for known in-the-wild exploitation;
  • vendor severity for product-owner context;
  • CNA or ADP records for CVE metadata;
  • asset exposure and criticality for defender priority.

When using CVSS, include the vector when possible. Do not publish a naked number without rationale.

7. Priority Modifiers​

Increase operational priority when:

  • active exploitation is known;
  • the issue appears in CISA KEV;
  • a public exploit exists;
  • exploitation is automatable;
  • the affected service is internet-facing;
  • the affected asset handles sensitive data;
  • the product is widely deployed;
  • remediation is simple and low-risk;
  • exploit chaining is likely;
  • the issue affects identity, update, CI/CD, logging, backup, or management planes.

Decrease immediate priority when:

  • exploitation requires extensive local prerequisites;
  • the affected component is not deployed;
  • strong compensating controls are verified;
  • remediation introduces higher safety risk;
  • exposure is limited to a controlled lab environment.

8. Publication Language​

A public severity statement should be short and supported.

Preferred form:

Severity: High. The issue allows an authenticated low-privilege user to access another tenant’s metadata under default configuration. Impact is limited to metadata fields; no credential exposure was observed. Confidence: probable pending vendor version confirmation.

Avoid unsupported labels, adversarial framing, or broad claims not proven by evidence.

9. Unknowns​

Unknowns must be explicit. A good severity section can say:

  • affected versions are not fully confirmed;
  • exploitability outside a test tenant was not assessed;
  • active exploitation is not known;
  • remediation status is pending vendor confirmation;
  • public exploit availability was not evaluated beyond listed references.