Key Takeaways
- A CVSS score alone can’t tell you what to patch first. Cloud teams need exploitability data, asset context, and business impact in the mix too.
- Multi-cloud and containerized environments change fast. A scan from last week is already out of date.
- Kubernetes, containers, serverless, and infrastructure as code each need their own vulnerability workflow, not one scanner bolted onto everything.
- CISA’s KEV catalog and EPSS scores help teams separate the vulnerabilities attackers are actually using from the ones sitting quietly on a shelf.
- Risk-based vulnerability management works best when it’s a living loop: scan, score, fix, confirm, repeat, not a quarterly report nobody reads.
A mid-size fintech company runs workloads across three cloud providers. Their last scan turned up 4,200 open findings. 380 were marked critical. The security team has three people and about ten hours a week set aside for patching. That math doesn’t work, and it never will if every finding gets treated the same way.
This is the reality for most cloud-first teams today. The old model of “patch everything marked critical” made sense when infrastructure sat still in a data center. It falls apart the moment workloads spin up and down by the hour across multiple providers.
Why Do Vulnerability Programs Struggle in Multi-Cloud Environments
Most vulnerability programs were built for a world that doesn’t exist anymore. Servers used to stay put for years; now a container might live for twenty minutes. Here’s what’s really breaking:
Assets Multiply Faster Than Teams Can Track Them
Every cloud account, container, serverless function, and infrastructure as code template adds a new surface to scan. Analyst research points to customer-side misconfiguration, not the cloud provider itself, as the leading cause of cloud security failures going forward, and most security leaders now rank misconfigured services among their top risks. That’s not a scanning problem. That’s a scale problem.
Multi-Cloud Means Multiple Sets of Rules
Running workloads across more than one provider means juggling different identity systems, different logging formats, and different default settings. Most organizations today run more than one cloud provider, and each one carries its own weak spots. Security teams end up stitching together three or four different views of risk just to get one picture.
Everything Looks Urgent, So Nothing Gets Fixed
When a scanner hands back thousands of “critical” findings, teams freeze or default to whatever’s loudest. Research on CVSS-only triage has found that only a small fraction, around 2%, of high-severity vulnerabilities ever see an actual exploitation attempt, while a meaningful share of the CVEs attackers do use carry only a medium severity score. Severity and real-world risk are two different things, and treating them as the same thing wastes weeks of engineering time on flaws nobody is actually going after.
Staffing Hasn’t Caught Up With Sprawl
Nearly half of security teams say they don’t have enough qualified people to manage multi-cloud risk properly, and cloud engineers and security teams often disagree about who even owns the problem in the first place.
What Risk-Based Vulnerability Management Actually Means for Cloud-Native Teams
Risk-based vulnerability management, or RBVM, swaps out the “patch everything critical” approach for one built around a simple question: is this specific flaw, on this specific asset, something an attacker could actually reach and use right now?
The Signals That Actually Matter
RBVM pulls in more than one signal instead of leaning on a single score:
- CVSS for theoretical severity, what could go wrong if the flaw is exploited
- EPSS for the probability a given CVE gets exploited in the next 30 days
- CISA’s Known Exploited Vulnerabilities (KEV) catalog for confirmed, real-world attacks
- Asset criticality so a flaw on a production database gets treated differently than the same flaw on a dev sandbox
- Threat intelligence to catch what’s trending among attackers before it shows up in a formal advisory
The Gap Between “Severe” and “Exploited”
The gap between severity and actual exploitation is bigger than most teams assume:
- CISA’s KEV catalog covers well under one percent of all published CVEs.
- In any given month, only a small handful of published CVEs show any real exploitation activity at all.
- Most of the “critical” pile a scanner hands you was never going anywhere.
FIRST, the group that runs EPSS, tracks this gap closely, and it’s the reason severity alone keeps sending teams after the wrong findings.
How Can Cloud-First Organizations Implement Risk-Based Vulnerability Management
Start small and build outward. A working rollout usually looks like this:
- Inventory what you actually have, across every cloud account, and tag assets by business criticality.
- Pull exploitability data (EPSS, KEV) into your existing scan results instead of relying on CVSS alone.
- Set remediation SLAs by risk tier, not by a single severity label.
- Automate ticket creation and routing so findings land with the team that owns the asset.
- Track time to remediate, not just findings closed, so you can see if the backlog is actually shrinking.
If you want a deeper walkthrough of the scoring side of this, we put together a full breakdown of how to build a vulnerability risk scoring framework that blends these signals into one usable number.
How to Implement Risk-Based Vulnerability Management in Multi-Cloud Environments
Multi-cloud adds a wrinkle: the same CVE can carry different real-world risk depending on which provider, which network configuration, and which identity permissions surround it. A few things that help:
- Normalize findings from every provider into one shared risk model instead of three separate dashboards.
- Weight exposure by whether the asset is internet-facing, since public exposure changes the exploitation math fast.
- Fold in identity and permission context. A vulnerable service with broad IAM access is a very different risk than the same flaw on a locked-down function.
How to Implement Risk-Based Vulnerability Prioritization for Cloud Workloads
Prioritization for workloads (VMs, containers, serverless functions) needs a formula, not a gut call. Most teams land somewhere close to this:
- Severity (CVSS) sets the ceiling on how bad it could get.
- Exploitability (EPSS, KEV status) sets how likely it is to actually happen.
- Reachability checks whether the vulnerable code path is even exposed at runtime.
- Asset value decides how much it matters if it does get hit.
Multiply those together, even informally, and the backlog sorts itself out. Our exposure prioritization playbook walks through this scoring approach in more detail if you want to see it applied to a real backlog.
Applying Risk-Based Vulnerability Management Across Every Cloud-Native Surface
Kubernetes clusters, containers, serverless functions, and infrastructure as code templates don’t behave the same way, so a single generic workflow won’t cover all of them well.
How to Implement Vulnerability Management in Kubernetes Environments
Kubernetes adds layers most traditional scanners were never built for: the cluster itself, the container images running inside it, and the workload configurations controlling what those containers can do.
- Scan images before they ever reach the registry, not after they’re already running.
- Check cluster configuration separately from image vulnerabilities. A misconfigured role binding can matter more than a missing patch.
- Watch for drift. A cluster that passed a scan on Monday can look completely different by Friday once new deployments roll out.
How to Implement Vulnerability Management for Containerized Applications
Containers move fast, which is exactly why old-school patch cycles don’t work here.
- Bake scanning into the CI/CD pipeline so a vulnerable base image gets flagged before it ships, not after.
- Rebuild instead of patch. Containers are usually disposable, so replacing the image is often faster and cleaner than patching a running one.
- Track base image age. Stale base images quietly accumulate risk even when the application code hasn’t changed at all.
How to Implement Continuous Vulnerability Assessment in Cloud Environments
A point-in-time scan is stale the moment it finishes in an environment that changes by the hour.
- Move from scheduled scans to continuous, agent-based or API-driven monitoring.
- Feed new findings straight into the same risk-scoring workflow you already use, so nothing sits in a separate queue.
- Set alerts for newly disclosed CVEs that match software already running in your environment, so you know within hours, not weeks.
How to Implement Vulnerability Management for Serverless Applications
Serverless shrinks the attack surface but doesn’t remove it. The risk shifts to code dependencies, permissions, and event triggers.
- Scan function dependencies the same way you’d scan any application library.
- Review the permissions attached to each function. Overly broad access is the most common serverless misstep.
- Check event sources (queues, storage triggers, APIs) for the same misconfiguration patterns that show up elsewhere in the cloud.
How to Implement Vulnerability Management for IaC and Cloud Infrastructure
Infrastructure as code lets a single bad template turn into hundreds of misconfigured resources overnight.
- Scan Terraform, CloudFormation, and similar templates before they’re applied, not after deployment.
- Treat IaC findings with the same urgency as runtime findings. A misconfiguration baked into a template will keep reproducing itself.
- Pair template scanning with drift detection to catch changes made manually outside the pipeline.
Where Secure.com’s Infrastructure Security Teammate Fits In
The Grunt Work Nobody Has Time For
Running all of this by hand across multiple clouds, a Kubernetes fleet, containers, serverless functions, and IaC templates is exactly the kind of grunt work that burns out good security engineers:
- Chasing down which scanner flagged what, across three or four separate dashboards.
- Re-checking severity by hand because the scanner won’t factor in exploitability or asset value.
- Writing tickets, routing them to the right team, and following up when they stall.
- Re-running scans to confirm a fix actually held.
What the Infrastructure Security Teammate Handles
Secure.com’s Infrastructure Security Teammate takes that layer off your team’s plate:
- Continuous scanning across cloud, container, and endpoint surfaces
- Misconfiguration and drift detection as environments change
- Risk-based prioritization that pulls in exploitability and asset context instead of relying on severity alone
- Action inside the scope, permissions, and approvals your team sets, so nothing gets touched without your say-so
- A full audit trail your team can review for every action taken
That’s the core of what we mean by Governed Defense, Powered by Offense. Your team sets the rules. The teammate does the work, and hands you back the hours you’d otherwise lose to console-stitching and report chasing.
FAQs
What’s the difference between vulnerability management and risk-based vulnerability management?
Do I need a different tool for Kubernetes, containers, and serverless, or can one program cover all of them?
How often should cloud vulnerability scans run?
Is CVSS still useful if I’m doing risk-based prioritization?
Conclusion
Cloud-native environments move too fast for a “patch every critical” approach to keep up. The teams that stay ahead are the ones treating vulnerability management as a continuous, risk-weighted loop across every surface, from Kubernetes to serverless to the infrastructure code that provisions all of it. Get the prioritization right, and the backlog stops feeling impossible. It starts feeling like a list you can actually work through.
