# Risk-Based Vulnerability Management: 28 Critical Findings, 20 Fixed in a Day, 8 No Patch Could Fix

Source: https://truvocyber.com/blog/risk-based-vulnerability-management
Published: 2026-11-10
Topic cluster: Cybersecurity

> Risk-based vulnerability management ranks findings by exposure, exploitability and ownership instead of CVSS alone. A real 28-critical triage shows how.

Risk-based vulnerability management is the practice of ranking scanner findings by the risk each one carries in a specific environment (exposure, known exploitation, what the affected component can reach, and whether a fix exists) instead of by the CVSS severity printed on the finding. The severity score describes the CVE. The risk depends on where the vulnerable file lives, who owns the component, and what an attacker could reach through that component.

At a glance

- **Definition**: prioritizing vulnerabilities by environmental risk, with CVSS as one input among several
- **Main inputs**: internet exposure, known exploitation (CISA KEV), exploit likelihood (EPSS), asset access to data and secrets, fix availability
- **Framework basis**: CIS Controls v8 Safeguard 7.2 calls for a *risk-based remediation strategy* reviewed monthly or more often
- **SOC 2 link**: CC7.1 (detect vulnerabilities), with evidence in patch records, tickets and approved exceptions
- **Part policy templates often leave out**: an exception register for findings that have no fix

## What is risk-based vulnerability management?

Risk-based vulnerability management (RBVM) treats a scanner's output as raw input and adds the context the scanner lacks. A severity-based program works the list from the highest CVSS score down. A risk-based program asks four questions about each finding first: can an attacker reach the vulnerable component, is the flaw being exploited somewhere already, what does the component have access to, and is a fix available today.
QuestionSeverity-based vulnerability managementRisk-based vulnerability managementOrder of workHighest CVSS score firstHighest environmental risk firstUnit of workOne CVEOne fix and one owner (a single upgrade often closes many CVEs)Findings with no patchStay open, dashboard stays redDocumented exception with owner, compensating control and review dateDefinition of doneCount reaches zeroEvery finding is fixed, scheduled within SLA, or formally acceptedAudit evidenceScan reportsScan reports, patch records, tickets and approved exceptions

CIS Controls v8 Safeguard 7.2 asks organizations to *establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews* ([CIS Control 7](https://www.cisecurity.org/controls/continuous-vulnerability-management)). The safeguard's wording makes risk, not raw severity, the basis for remediation order.

## Why a CVSS critical rating says little about risk in a specific environment

A CVSS base score measures the vulnerability itself. The CVSS v3.1 specification describes the base metric group as *the intrinsic characteristics of a vulnerability that are constant over time and across user environments* ([FIRST CVSS v3.1](https://www.first.org/cvss/v3-1/specification-document)). A CVE in a compiler toolchain scores the same on an internet-facing web server as in a build tool cache that nothing serves to the network.

Two public sources add the context CVSS leaves out:

- **CISA Known Exploited Vulnerabilities (KEV) catalog:** CVEs with confirmed exploitation in the wild ([CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)).
- **Exploit Prediction Scoring System (EPSS):** a daily probability that a CVE will be exploited in the next 30 days ([FIRST EPSS](https://www.first.org/epss/)).

Even with KEV and EPSS, the two inputs that decide the order of work are local: where the vulnerable file is stored on disk and what that component can reach. No external feed knows either one.

## A real triage: 28 critical findings on one cloud server

A small firm turned on the free, built-in agentless vulnerability scanner in Google Cloud Security Command Center for the firm's only server, a self-hosted git server holding confidential work. The scanner reported 28 findings on the VM, and every one was rated CRITICAL. The server had no public IP address, accepted connections only through a zero-trust tunnel, and had daily automatic security updates turned on. On the dashboard, the server still looked like the riskiest asset in the company.

Sorting the 28 findings by the file path on disk, a field many teams skip, split them into three groups in under a minute:
Group of scanner findingsCountOwnerFixGit application the team was worried about0Application ownerNone neededCI build runner binary, compiled with an outdated toolchain13CI/CD ownerOne runner upgradeCI runner tool cache (old Node, Python and npm copies left by past jobs)7CI/CD ownerOne cache wipeOS packages with no fix in the installed distribution release8Infrastructure ownerDocumented exception, then rebuild on a newer OS

Key insight

**Twenty of the 28 critical findings closed the same day with two actions.**

One CI runner upgrade and one tool cache wipe removed every CI finding.

The remaining eight had no patch to apply. The Linux distribution had fixed them only in the next major release, the distribution's security team had marked two as minor and postponed, and one applied to a server component that was not installed (only a shared library was present).

A severity-based program would have read *28 critical* as an emergency on the git server. The risk-based reading pointed to a component nobody had listed as part of the attack surface: the CI runner.

## How the file path in a scanner finding assigns the owner of the fix

The file path in a vulnerability finding is the fastest triage field available, because the path tells the team which component owns the vulnerable code and therefore who can fix the finding. A CVE ID tells the team what is wrong. The path tells the team where to act.

Agentless scanners in particular inspect the disk, so they flag every vulnerable binary present, including binaries no process loads. Disk inspection gives broad coverage plus noise, and the file path separates the two:

- **Paths under the OS package manager** (for example `/usr/lib`) belong to the infrastructure owner and are fixed by package updates or an image rebuild.
- **Paths under a CI runner's home or tool cache** belong to whoever owns the build pipeline and are fixed by upgrading the runner or clearing the cache.
- **Paths inside an application directory or container image** belong to the development team and are fixed in the dependency manifest.

Key insight

**One upgrade frequently closes a dozen CVEs.**

Counting fixes and owners instead of CVEs turned the 28-item scanner list into three tickets.

## Why self-hosted CI runners belong in vulnerability management scope

Self-hosted CI runners belong in vulnerability management scope because they execute code from every repository they serve and usually hold credentials to deploy, publish and read secrets. In many small teams the runner falls outside the OS package manager and outside the application, so no patch process covers the runner binary or the runner's tool cache.

SOC 2 ties the pipeline to two criteria. CC7.1 covers detecting vulnerabilities in the system, and CC8.1 covers change management, which includes the build and deployment pipeline that changes production. A CI runner with 20 known-vulnerable binaries on disk is a finding against both.

The same review found a second CI gap. A retired project's scheduled workflows were still executing four times a day with live API credentials, long after anyone used the project. Reviewing scheduled jobs and the secrets attached to each one is part of keeping the CI runner patched, because an unused workflow with valid credentials is exposure with no owner.

The runner upgrade in this case crossed a major version with breaking changes. Searching every repository's workflow files for the removed features before upgrading turned a risky swap into a routine one.

## How to handle vulnerabilities with no patch available

A vulnerability with no available patch needs a documented exception, because a *patch everything* policy cannot reach zero while the vendor has no fix available. Without an exception process, the open count never closes, the dashboard stays red, and teams either stop reading the dashboard or start suppressing findings informally. Both outcomes leave the auditor with less to trust.

An exception register entry for each unpatchable finding should record:
Exception register fieldExample from the 28-critical triageFinding and affected componentOS library CVE, server component not installedReason the finding stays openFixed only in the distribution's next major releaseRisk assessmentNo public IP, zero-trust tunnel access, component not reachableCompensating controlsNetwork isolation, daily automatic security updates, restricted admin accessOwnerInfrastructure ownerReview date90 days, or when the distribution releases a fixExit planRebuild on a newer hardened OS image

CIS Controls v8 Control 7 expects a documented process for findings that cannot be remediated, and SOC 2 auditors test exceptions by sampling them: approval, compensating control and a review that took place on schedule. The [SOC 2 vulnerability risk acceptance guide](https://truvocyber.com/blog/soc-2-vulnerability-risk-acceptance) covers the approval workflow and the evidence auditors sample.

## Why automatic security updates alone fail as SOC 2 patch evidence

Automatic security updates fix packages but typically leave no record an auditor can sample, so an *auto-updates are on* answer proves configuration and leaves the operation of the control unproven. In the triage above, daily automatic updates had been running for months, and the team had nothing dated to show for them.

Three gaps between patching and proving the patching came up:

1. **No dated records.** The cloud provider's native patch service (free at this scale) produces dated patch-job records. Turning the patch service on was blocked by a missing provider-managed service account that nothing flagged until the team ran the provider's troubleshooting command.
2. **Scanner confirmation lag.** The free scanner tier rescanned weekly and could not be triggered on demand, so a fix verified locally the same day stayed open on the dashboard for up to a week.
3. **Exceptions living in someone's head.** The eight unpatchable findings had a reason to stay open, but no written record until the exception register existed.

The evidence chain auditors look for under CC7.1 has three parts: scan results showing detection on a schedule, tickets or patch records showing remediation of critical and high findings within SLA, and approved exceptions for the rest. The [guide to automatic patching and SOC 2 change management](https://truvocyber.com/blog/soc-2-automatic-patching-change-management) covers how automatic updates fit the change management criteria.

## Which risk factors decide vulnerability remediation priority

Remediation priority in a risk-based program comes from a short list of factors, applied in roughly this order. Each one can be answered from data the team already has.
Risk factorQuestion to answerWhere the answer comes fromKnown exploitationIs the CVE in CISA KEV?CISA KEV catalogExposureCan the vulnerable component be reached from the internet or by untrusted users?Network config, load balancer and firewall rulesAsset accessDoes the component hold or reach secrets, customer data or deploy rights?Asset inventory, IAM and CI configurationExploit likelihoodWhat is the EPSS probability?FIRST EPSSReachabilityIs the vulnerable code loaded or installed, or only present on disk?File path, package list, process listFix availabilityIs there a patch now, or only in a future release?Vendor or distribution security trackerSeverityWhat is the CVSS score?Scanner finding

Severity comes last on purpose. CVSS is still useful as a tiebreaker and as the input most SLA tables use, and the SLA table should stay simple: critical and high findings on internet-facing systems within 24 to 48 hours, medium within 30 days, low within 90 days, as covered in [what a vulnerability scan is and how often to run one](https://truvocyber.com/blog/what-is-a-vulnerability-scan). The risk factors decide which findings count as critical for the business before the SLA clock applies.

## How to start risk-based vulnerability management on a small cloud team

A small cloud team can move from a severity-sorted list to a risk-based program in one working session plus a monthly review:

1. **Turn on the native scanner.** AWS, Azure and Google Cloud each offer built-in vulnerability scanning. The [SOC 2 vulnerability scanner comparison](https://truvocyber.com/blog/soc-2-vulnerability-scanner-datadog-wazuh-nessus) covers third-party options when coverage needs to extend past one cloud.
2. **Group findings by file path and owner.** Count fixes, not CVEs. Expect one upgrade to close many findings.
3. **Add CI runners, build caches and scheduled workflows to scope.** Review which secrets each runner and workflow can reach, and retire workflows nobody uses.
4. **Check KEV and exposure for anything left.** Internet-facing findings in KEV go to the front of the queue regardless of score.
5. **Write an exception for every finding with no fix.** Owner, compensating control, review date, exit plan.
6. **Turn on a patch service that leaves records.** Automatic updates plus dated patch-job history gives the auditor something to sample.
7. **Review monthly.** CIS Safeguard 7.2 sets monthly as the minimum review frequency, and a monthly snapshot of open findings, closed findings and active exceptions builds the trend auditors value.

## Vulnerability management as a security capability

Vulnerability management is one of the roughly 19 security capabilities that make up an effective security program. The scanner is the tool. The capability is the loop around the scanner: scope that includes the build pipeline, triage by owner and risk, fixes within SLA, exceptions with review dates, and records that prove the loop keeps working.

Built that way, compliance follows as a byproduct. The same patch records, tickets and exception register that keep real exposure down are the evidence SOC 2 CC7.1, ISO 27001 A.8.8 and customer security questionnaires ask for. A dashboard showing 28 criticals tells a buyer's security team very little. A register showing 20 closed in a day and 8 accepted with review dates answers their question.

### Turn scanner noise into a working program

Truvo builds the effective security program around the scanner: triage, exceptions and audit-ready patch evidence.[Book Your Strategy Call](/contact-us)

## Frequently asked questions

### What is risk-based vulnerability management?

Risk-based vulnerability management prioritizes vulnerabilities by the risk they carry in a specific environment, using exposure, known exploitation (CISA KEV), exploit likelihood (EPSS), asset access and fix availability alongside CVSS. Teams fix the findings an attacker could use first, and document exceptions for findings with no available patch.

### How is risk-based vulnerability management different from CVSS-based prioritization?

CVSS scores the vulnerability itself and stays constant across environments. Risk-based prioritization adds environmental context: whether the component is reachable, what the component can access, and whether the flaw is exploited in the wild. A critical CVE in an unreachable build cache can rank below a medium CVE on an internet-facing server.

### Does SOC 2 require risk-based vulnerability management?

SOC 2 CC7.1 requires procedures to detect and monitor vulnerabilities and leaves the prioritization method to the organization. Auditors test the documented policy against evidence: scan schedules, remediation records within the stated SLA, and approved exceptions. A risk-based policy with exceptions is easier to follow, and therefore easier to evidence, than a policy promising to patch everything.

### What should happen to a vulnerability that has no patch?

A vulnerability with no available patch goes into an exception register with the affected component, the reason the finding stays open, a risk assessment, compensating controls, an owner, a review date and an exit plan such as an OS upgrade. The exception is reviewed on schedule and closed once a fix is released.

### Why do agentless scanners report so many critical findings?

Agentless scanners read the disk snapshot, so they flag every vulnerable binary present, including build tool caches and libraries no running process loads. The result is broad coverage with extra noise. Reading the file path on each finding separates OS packages, CI tooling and application code, and assigns each group to the owner who can fix the finding.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is risk-based vulnerability management?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Risk-based vulnerability management prioritizes vulnerabilities by the risk they carry in a specific environment, using exposure, known exploitation (CISA KEV), exploit likelihood (EPSS), asset access and fix availability alongside CVSS. Teams fix the findings an attacker could use first, and document exceptions for findings with no available patch."
      }
    },
    {
      "@type": "Question",
      "name": "How is risk-based vulnerability management different from CVSS-based prioritization?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "CVSS scores the vulnerability itself and stays constant across environments. Risk-based prioritization adds environmental context: whether the component is reachable, what the component can access, and whether the flaw is exploited in the wild. A critical CVE in an unreachable build cache can rank below a medium CVE on an internet-facing server."
      }
    },
    {
      "@type": "Question",
      "name": "Does SOC 2 require risk-based vulnerability management?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SOC 2 CC7.1 requires procedures to detect and monitor vulnerabilities and leaves the prioritization method to the organization. Auditors test the documented policy against evidence: scan schedules, remediation records within the stated SLA, and approved exceptions. A risk-based policy with exceptions is easier to follow, and therefore easier to evidence, than a policy promising to patch everything."
      }
    },
    {
      "@type": "Question",
      "name": "What should happen to a vulnerability that has no patch?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A vulnerability with no available patch goes into an exception register with the affected component, the reason the finding stays open, a risk assessment, compensating controls, an owner, a review date and an exit plan such as an OS upgrade. The exception is reviewed on schedule and closed once a fix is released."
      }
    },
    {
      "@type": "Question",
      "name": "Why do agentless scanners report so many critical findings?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Agentless scanners read the disk snapshot, so they flag every vulnerable binary present, including build tool caches and libraries no running process loads. The result is broad coverage with extra noise. Reading the file path on each finding separates OS packages, CI tooling and application code, and assigns each group to the owner who can fix the finding."
      }
    }
  ]
}