A CVSS Base score is computed once, by the vendor or by NVD, from the vulnerability alone: how it is reached, how complex the exploit path is, what privileges and user interaction it needs, and what happens to confidentiality, integrity and availability if it fires as designed. That score never looks at your network. It does not know that the affected host sits behind a default-deny firewall, that the data on it is synthetic test data, or that three redundant instances absorb an outage without anyone noticing. A 9.8 on an internet-facing payment API and a 9.8 on an air-gapped lab VM are the same number for a reason that has nothing to do with your risk. The Environmental metric group exists specifically to close that gap, and it does it without ever touching the shared CVE record everyone else relies on.
Why a global base score cannot know your network
The Base group is deliberately context-free. NVD and vendors score a CVE once against the worst plausible deployment of the affected component, because the same score has to travel to every organization running that software, from a single laptop to a bank’s core ledger. It cannot account for compensating controls such as a web application firewall in front of the endpoint, network segmentation that removes the “Network” attack vector in practice, or a data classification that makes the confidentiality impact irrelevant because the box holds nothing sensitive.
Ignoring this gap has a real operational cost. If every finding is triaged on Base score alone, a CI runner in a segmented build VLAN and an unauthenticated login endpoint on the public website compete for the same “Critical, 24 hour SLA” bucket. Analysts learn to distrust the queue, SLAs get missed on the things that matter, and the team eventually starts silently deprioritizing without a documented reason, which is worse than not scoring at all. The Environmental group gives you a legitimate, auditable way to re-score a CVE for one specific deployment, using two mechanisms: Security Requirements, which weight how much you care about each impact type for that asset, and Modified Base Metrics, which let you restate the attack characteristics to match reality.
Security Requirements (CR/IR/AR): weighting CIA per asset class
Three metrics, Confidentiality Requirement (CR), Integrity Requirement (IR) and Availability Requirement (AR), each take one of three values and multiply directly into the impact calculation:
| Value | Numeric weight | Typical asset signal |
|---|---|---|
| Low | 0.5 | Synthetic data, disposable environment, redundant capacity |
| Medium (default, Not Defined) | 1.0 | Standard internal system, no special classification |
| High | 1.5 | Regulated data, single point of failure, core ledger or identity store |
The mistake teams make is assigning CR/IR/AR from memory during a triage call. That does not scale past a handful of hosts and it is not defensible in an audit. Set these values once, per asset class, from data you already maintain: map your data classification tiers (public, internal, confidential, restricted) to CR, map system criticality tiers from your BC/DR plan (tier 0 through tier 3, tied to uptime SLA) to AR, and map change-control class (financial ledger, DNS, identity provider, CI/CD pipeline) to IR. If your asset inventory already tags hosts with a data classification and a business criticality tier, CR/IR/AR should be a lookup, not a judgment call made under a deadline. If it does not carry that metadata yet, environmental scoring is the wrong project to start with; fix the inventory first, because a Security Requirement guessed on the spot is worse than the Base score it replaces.
Modified Base Metrics: legitimately downgrading a “Network” vector
Eight Modified metrics (MAV, MAC, MPR, MUI, MS, MC, MI, MA) let you override any Base metric for this deployment while leaving it “Not Defined” wherever nothing changes, in which case it simply inherits the Base value. The most commonly misused one is Modified Attack Vector, and the most common misuse is downgrading Network to Adjacent because “we have a firewall,” without verifying the claim.
A Network to Adjacent downgrade is defensible only when you can show, not assert, that the vulnerable interface has no unrestricted network path to it: a default-deny ACL with an explicit allow-list, no NAT or port-forward that republishes the port, and no VPN split-tunnel that bridges the segment back to an internet-reachable network. The verification step matters more than the firewall rule itself, because rules drift and split-tunnels get added for one engineer’s convenience and never removed. Continuous reachability testing against the actual segment, rather than a one-time reading of a firewall config, is what turns MAV:A from a guess into a fact; this is the same discipline behind reachability mapping that checks whether a path exists today, not whether a diagram says it should not.
The same rigor applies to the other five metrics. Modified Privileges Required can move to High when a compensating control, such as a mutual-TLS gateway or an internal auth proxy, sits in front of every path to the vulnerable code, not just the primary one. Modified Confidentiality, Integrity and Availability can be restated when the actual technical impact in this deployment differs from the generic case, for example a service that runs under a restrictive container profile where a break-out cannot reach the host filesystem. What you should never do is set a Modified metric to a lower-severity value because it is convenient and skip recording why; every override needs a one-line justification tied to a control you can point to.
Worked example: a Critical dropping into the Medium band
Take a hypothetical CVE with a Base vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, Base score 9.8, Critical. It sits on an internal build server: reachable only from a dedicated build VLAN behind a default-deny firewall verified by active reachability scanning, fronted by a service proxy that requires an authenticated build-agent credential, holding no secrets because those are vaulted externally, and backed by three redundant runners that absorb a single host outage without stopping the pipeline. A tampered build, however, still poisons every downstream artifact, so integrity impact stays high.
That reasoning translates into: MAV:A (segmented, verified), MPR:H (the proxy requires a credential the base vulnerability does not), MC:L (no secrets on the box), MA:L (redundant capacity), CR:M, IR:H, AR:L, with MAC, MUI, and MI left unchanged. Running that vector through a CVSS v3.1 calculator lands the Environmental score at 6.7, Medium, down from a Critical 9.8. Notice that changing MAV alone would barely move the score, since exploitability is a small fraction of the total; the meaningful drop only comes from combining a verified network restriction with an honest reassessment of impact and requirements. That is also the useful diagnostic: if one Modified metric change alone would already justify closing a Critical, be suspicious of it.
The consequence is not cosmetic. Critical usually carries a same-day or 24 hour remediation SLA and lands at the top of every analyst’s queue; Medium typically carries weeks. Feeding the environmental vector, not the raw Base score, into whatever ranks the backlog is what keeps triage and prioritization pointing at the findings that actually threaten the business first. A system that only re-triages on a schedule will still show the stale Critical badge for days; one that re-ranks as soon as the vector changes, the way SITEY does when an environmental override is recorded against an asset, drops the ticket out of the urgent queue the same hour, instead of after the next batch run.
Governance: who is allowed to modify metrics, and how to keep an audit trail
Environmental overrides change SLA and priority, so they need the same rigor as a change to a firewall rule. A workable model:
- Two-person rule for downgrades. An analyst can propose an environmental vector, but any change that lowers severity or extends an SLA needs a second, named approver, typically someone in security architecture or the asset owner’s manager.
- Record the full evidence chain. CVE identifier, original Base vector and score, proposed Modified vector, each changed metric with its justification text, and a pointer to the control that justifies it: a firewall rule ID, a network diagram revision, a ticket for the compensating control. Store it where it survives the person who wrote it.
- Set an expiry, not a permanent state. Segmentation changes, proxies get decommissioned, redundant capacity gets removed to cut cost. Every override needs a review date, and any change ticket that touches the referenced control should trigger a re-check of overrides that depended on it.
- Reject blanket profiles. Applying one environmental vector to an entire subnet without validating each host individually is how a justified override for one build server quietly becomes a severity discount for a host that got reassigned to something internet-facing six months later.
Wherever your compliance evidence for ISO 27001, SOC 2 or a BDDK audit already lives, the environmental justification belongs next to it, not in a separate spreadsheet nobody remembers during the audit. Attaching it to the same trail your reporting pulls from means an auditor asking “why is this Critical showing as Medium” gets an answer in one click instead of a scramble.
Scaling environmental scoring beyond a spreadsheet
A hand-maintained spreadsheet of CVE vectors works for a dozen assets and breaks past a few hundred. Nobody updates it when a firewall rule changes, nobody notices when the compensating control it depended on gets removed, and during discovery for an audit or an incident it is usually the first thing that turns out to be stale. The fix is to stop scoring per CVE per host and start modeling the environmental inputs at the asset level instead.
Practically, that means: CR/IR/AR live on the asset record, inherited from data classification and criticality tags that already exist, and get applied automatically to every new finding on that asset rather than re-typed each time. MAV claims stay honest through continuous, not one-time, reachability testing, so a segment that becomes reachable next month flips the override back automatically instead of silently keeping an outdated Adjacent rating. Change management for the network or the compensating control triggers a re-evaluation of any override that cited it, closing the gap where stale justifications outlive the control they described. Platforms that automate this phase, such as SITEY, attach CR/IR/AR and verified reachability to the asset record once and recompute the environmental vector automatically as new CVEs land on it, instead of asking an analyst to rebuild the same vector by hand every time. Whether or not you use a platform for it, the design goal is the same: the environmental score should be a live consequence of what your inventory and network actually look like today, not a snapshot someone typed in during a triage call last quarter.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.