Enterprise Vulnerability Management: How to Build a Scalable Remediation Program

Most enterprise security teams don't have a shortage of vulnerability data. They have a shortage of decisions. A single quarter of scanning across cloud infrastructure, containers, and application dependencies routinely produces far more findings than any team can act on individually, and many of them share the same fate: they sit in a backlog until someone closes the ticket without really fixing anything, or a compliance deadline forces a scramble. The technical problem isn't detection. Modern scanners are good at finding vulnerabilities. The problem is turning that raw output into a small number of decisions engineers can execute against, on a timeline that matches real exploitation risk rather than a scan's severity field.

This is what a scalable enterprise vulnerability management program aims to do: narrow a large, noisy finding set down to a short list of vulnerabilities worth immediate action, and wire that short list into the systems engineers already use, with a verification step that confirms the fix landed. The sections below cover how that works, including the operational friction that a purely severity-based approach tends to create.

Why Scanners Alone Don't Scale

A large environment with cloud infrastructure, Kubernetes workloads, and CI/CD-integrated dependency scanning can generate more open findings than any team can reasonably triage manually, and that volume climbs further once container base images and transitive dependencies enter the count. The exact volume varies enormously by scanner configuration, asset count, and how aggressively base images are rebuilt, but a significant portion of it tends to be overlapping or duplicate signal, such as the same CVE reported by a network scanner and an agent, or the same vulnerable package flagged separately by SAST, SCA, and container scanning because none of the tools know the others exist. Layer in findings with no clear owner, findings against decommissioned or soon-to-be-replaced assets, and findings that are technically present but never execute, and the actionable subset of that list is usually a small fraction of the total.

Treating every "Critical" severity finding as equally urgent guarantees two outcomes: engineers stop trusting the list, and the vulnerabilities that matter get lost in the ones that don't. A workable program has to solve the filtering problem before it solves the workflow problem.

Getting Asset Visibility Right First

Prioritization only works if the inventory underneath it is accurate. Cloud-native environments break the assumptions older vulnerability management tooling was built on: workloads spin up and disappear within minutes, autoscaling groups change the running fleet size hourly, and a single Kubernetes node can host dozens of short-lived pods that a periodic network scan will never catch mid-life.

One approach is to complement scanner inventories with cloud-native inventory sources such as AWS Config, Azure Resource Graph, GCP Asset Inventory, and Kubernetes APIs, since these reflect what's running rather than what was running at scan time. That kind of visibility is foundational to broader cloud security engineering work: it's difficult to reason about exposure or IAM blast radius for an asset the inventory doesn't know about. Source repositories and their dependency manifests need similar treatment: an inventory that only tracks deployed workloads will miss vulnerable libraries sitting in code that hasn't shipped yet, which matters once you're trying to catch problems in CI rather than in production.

Prioritization Beyond CVSS

CVSS measures theoretical severity in isolation from where a vulnerability lives. That's a known limitation of the score, not a flaw in how any particular team uses it, and it's the reason three complementary signals have become standard inputs to enterprise triage:

The Exploit Prediction Scoring System, maintained by FIRST, is a machine-learning model trained on exploit telemetry, vulnerability metadata, and public exploit-code availability. FIRST is explicit that EPSS is not a complete risk score; it says nothing about compensating controls or whether the vulnerable component is even reachable in your codebase. It's a likelihood signal, not a verdict.

CISA's Known Exploited Vulnerabilities catalog is a stronger signal in one specific sense: inclusion requires evidence that exploitation has already happened, not that it's statistically likely. CISA's own Stakeholder-Specific Vulnerability Categorization model, developed with Carnegie Mellon's Software Engineering Institute, formalizes this further by walking exploitation status, technical impact, and asset prevalence through a decision tree that outputs an action call (Track, Track*, Attend, or Act) rather than a numeric score. The output is deliberately not a single global number, because the same CVE can land in different action bands depending on what it's running on.

A Worked Prioritization Example

The following illustrates how naive severity ranking and risk-based triage can diverge, using a hypothetical scenario for explanatory purposes only (not a specific CVE, and not a SiegePal engagement):

Finding A: a CVSS 9.8 remote code execution vulnerability in a library used by an internal nightly batch job, running in a private subnet with no inbound internet access, no KEV listing, and a low EPSS score. Finding B: a CVSS 7.2 vulnerability in a package used by a public-facing API gateway service, running with an IAM role that has read access to a customer data store, listed in the KEV catalog with confirmed active exploitation.

A severity-only view ranks Finding A above Finding B, because 9.8 beats 7.2. A risk-based view flips that immediately. Finding A has no network path to exploitation and no evidence anyone is targeting it; it can reasonably sit in the standard patch cycle. Finding B combines confirmed exploitation, internet exposure, and a service identity with access to sensitive data. It gets an emergency ticket, not a backlog entry. This is the core mechanism that makes risk-based triage worth the setup cost: it isn't about ignoring severity, it's about weighting severity against exposure, exploitation evidence, and the blast radius of the identity attached to the vulnerable asset.

Where CI/CD Pipeline Gates Work Well

Bolting a security scan onto the end of a release process, after code is already built and staged, guarantees friction: by that point a finding either blocks a release everyone expected to ship, or it gets waived to avoid the delay. Pipeline gates work better when they're matched to the stage where a fix is still cheap.

SAST findings generally work better surfaced in the pull request itself, as PR comments rather than pipeline failures for anything below a defined severity threshold, so developers see the issue while the code is still fresh in their head. SCA (dependency) scanning has a real trade-off at the PR stage: scanning only the lockfile diff keeps a PR that doesn't touch dependencies from getting blocked by unrelated legacy findings, but it also means a PR won't surface a newly disclosed CVE in a dependency it didn't touch, which a full-tree scan would catch. Some teams handle that by running the diff-scoped check as the PR gate and a full dependency scan on a schedule instead of on every PR; which approach fits depends on dependency churn and how noisy the existing backlog already is. Container scanning is different from both: it needs to run against the final built image, since base layer composition and multi-stage build artifacts aren't visible from source alone.

A concrete gate policy might look like this in a GitHub Actions step using Snyk, one of the SAST/SCA tools commonly wired into CI/CD for this purpose:

- name: Container vulnerability gate
  uses: snyk/actions/docker@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  with:
    image: '${{ env.IMAGE }}'
    args: --severity-threshold=high --fail-on=upgradable
  # --fail-on=upgradable fails the build only when a fix is
  # available, which is what keeps this gate from
  # training teams to suppress everything under deadline pressure.

The --fail-on=upgradable flag matters operationally: failing a build over a CVE with no available patch just trains teams to add blanket suppressions, which defeats the gate for the next finding that does have a fix. It's worth being clear about what a gate like this does and doesn't cover: a severity-based threshold alone doesn't account for KEV status, so a Medium-severity CVE that CISA has listed as under active exploitation can still pass a Critical/High-only gate untouched. Snyk has added a Known Exploited Vulnerabilities filter to its issue views, useful for backlog triage, but folding KEV status directly into an automated pipeline gate is additional integration work beyond a standard severity threshold, not something the threshold gives you by default.

Operational Problems That Slow Programs Down

Several operational issues recur across vulnerability management programs, independent of which specific tools are in use:

• Duplicate findings across scanners. A network-based scanner, an agent, and a CI-integrated SCA tool can all report the same underlying CVE on the same asset, usually with different identifiers and no shared key by default. General practice is to normalize findings onto some shared identifier, commonly a combination of CVE ID and affected asset (sometimes package identifiers as well), before tickets get created; without that consolidation step, the same underlying issue can generate separate tickets in separate queues, and teams end up addressing the same vulnerability multiple times administratively. The right normalization key depends on which tools are in play and how their outputs are structured.
• Findings without a clear owner. Service accounts, shared infrastructure repos, and assets left behind after a team reorg can produce findings with no obvious assignee. A commonly recommended practice is an explicit fallback queue, with a named owner responsible for triaging orphaned findings within a defined window; without one, these findings tend to accumulate as a permanent pile of tickets nobody is accountable for.
• Inherited base image vulnerabilities. An application team generally can't patch a CVE that lives in the base image their platform team maintains. The fix has to happen upstream, with the base image rebuilt and republished, and downstream images rebuilt against the new digest. Without some automated rebuild-and-redeploy process tied to base image updates, this tends to become a manual chase that lags well behind actual patch availability.
• Risk exceptions that quietly become permanent. A documented risk acceptance, tied to a specific compensating control and an expiration date, is a widely recommended part of a mature program. An exception that never gets re-reviewed, because the tracking process doesn't force a renewal decision, is functionally permanent whether or not the compensating control is still in place.
• SLA breaches that don't get surfaced. A ticket that misses its remediation window ideally triggers an escalation rather than just accumulating age silently in a dashboard nobody checks. Treating SLA breach purely as a lagging metric reviewed monthly, rather than a near-real-time trigger, tends to mean the backlog problem surfaces during an audit rather than during routine team check-ins.

Verifying the Fix, Not Just the Ticket Status

A ticket marked "resolved" isn't the same as a vulnerability that's gone. A common recommended practice is a rescan that confirms the specific finding is absent, ideally triggered automatically after deployment rather than relying on the next scheduled full scan to eventually catch it. This matters more than it sounds: cached scan results, stale SBOMs, and scanners that only re-evaluate on a fixed interval can all report a "still vulnerable" false positive against a system that was patched days earlier, which erodes trust in the tooling just as much as a real miss would.

Where This Intersects Compliance

Vulnerability management sits underneath several distinct compliance obligations, and they're not interchangeable. HIPAA's Security Rule is a federal regulation that requires a documented risk analysis and reasonable safeguards, without prescribing a specific scanning cadence. SOC 2 is an attestation framework administered by the AICPA, not a regulation, and an auditor examining the Security criteria will look for evidence that vulnerability management operates consistently over the audit period. PCI DSS is a contractual requirement from the payment card industry, not a law, and it does specify more concrete expectations around scanning frequency for systems in cardholder data scope.

What ties these together operationally is evidence. A platform that tracks discovery date, assignment, remediation date, and any risk acceptance with its expiration gives an auditor a defensible trail, which is the same underlying evidence a compliance assessment engagement will ask a team to produce. That evidence supports an audit; it doesn't automatically satisfy a control on its own; auditors are evaluating whether the documented process was followed, not just whether a dashboard exists.

Metrics Worth Tracking (and Their Blind Spots)

Mean Time to Remediate is the most commonly reported program metric, and it's also the easiest to misread. An average MTTR gets dragged around by a small number of very old, exception-covered findings sitting in the tail of the distribution; a median or a p90 figure segmented by severity tier tells you far more about whether the program is keeping pace. SLA breach rate is more useful when it's broken out by severity and asset criticality rather than reported as a single blended number, since a breach on an internet-facing critical finding and a breach on an internal low-severity finding represent very different levels of risk. False positive rate, tracked separately, is a useful proxy for whether scanner tuning is reducing noise or just shifting it somewhere else.

Frequently Asked Questions

Is EPSS a replacement for CVSS?

No. CVSS estimates theoretical severity; EPSS, maintained by FIRST, estimates the probability of exploitation in the next 30 days. Industry guidance generally recommends using both together, alongside KEV status, rather than replacing one score with another.

Who should own base image vulnerabilities in a large organization?

Typically a platform or infrastructure team that maintains the base image itself, with an automated rebuild pipeline that pushes updated digests downstream. Application teams generally can't fix these findings directly since the vulnerable component isn't in their code.

How SiegePal Helps

SiegePal's continuous vulnerability management work has included deploying and configuring SAST and SCA scanning (Snyk, SonarQube) inside CI/CD pipelines via GitHub Actions and GitLab Pipelines, building severity-based gating policies and vulnerability triage workflows, along with developer remediation guidance designed to move findings through remediation rather than leaving them in the backlog. That work has also included identifying cryptographic weaknesses and dependency vulnerabilities across production codebases using Snyk and ArmorCode. The broader prioritization concepts covered in this article, EPSS and KEV in particular, are useful context for evaluating a program's maturity even where the specific tooling differs from what a given engagement uses.

References

• CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA / Carnegie Mellon SEI, Stakeholder-Specific Vulnerability Categorization (SSVC) Guide: https://www.cisa.gov/resources-tools/resources/stakeholder-specific-vulnerability-categorization-ssvc
• FIRST, Exploit Prediction Scoring System (EPSS): https://www.first.org/epss/
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final
• CIS Controls v8, Control 7: Continuous Vulnerability Management: https://www.cisecurity.org/controls/v8