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.

Research documentation should explain method and evidence boundaries without creating operational instructions for abuse. The goal is reproducible judgment, not public weaponization.

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.

Research documentation should explain method and evidence boundaries without creating operational instructions for abuse. The goal is reproducible judgment, not public weaponization.

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.

Research documentation should explain method and evidence boundaries without creating operational instructions for abuse. The goal is reproducible judgment, not public weaponization.