Cloud Vulnerability Management: Risk-Ranked Patching for Workloads
Cloud vulnerability management is the continuous process of finding software flaws in cloud VMs, container images and serverless functions, ranking them by real-world risk and getting them patched within agreed timeframes. NTSPL deploys native scanners, adds exploit likelihood and exposure context, and sets owner-based patch SLAs so Indian engineering teams fix the few hundred CVEs that matter instead of drowning in thousands.
Delivered on
In scope
Thousands of CVEs, a Few Hundred That Matter
A typical 400-VM cloud estate with a container platform reports 20,000-60,000 open CVE instances once scanning is switched on. CVSS alone marks thousands of them critical, so teams either give up or patch in arbitrary order. Meanwhile golden images go stale for months, container base images carry vulnerable libraries into every build, and a handful of internet-facing servers running an actively exploited flaw sit in the same queue as an unreachable test box. Auditors then ask for patch compliance and receive a percentage nobody trusts.
NTSPL rebuilds the programme around risk, not volume. Native scanners cover VMs, registries and functions agentlessly where possible. Each finding is enriched with EPSS exploit probability, presence in the CISA Known Exploited Vulnerabilities catalogue, internet exposure and data sensitivity, producing four priority bands with fixed SLAs. Fixes happen mostly by rebuilding images and redeploying, with in-place patching windows reserved for long-lived servers that cannot be rebuilt.
When Your Patch Backlog Has Stopped Telling You Anything
Signals you need Vulnerability Management
- Open CVE counts exceed 10,000 and the team cannot say which 100 to fix first
- Golden images or container base images are more than 60 days old
- Internet-facing servers have carried a CISA KEV-listed vulnerability for more than 14 days
- Patch compliance reported to auditors differs by tool, team or week
- Out-of-support operating systems, such as Windows Server 2012, still run production workloads
When to choose something else
- Your findings are misconfigurations, such as public buckets or open ports, rather than software flaws: see Cloud Security Posture Management.
- You need vulnerabilities caught in code and dependencies before build; that is DevSecOps, which feeds this programme.
Scanner Coverage, Prioritisation and Patch Pipelines We Build
Scanner coverage
Enable agentless and agent-based scanning for VMs, container registries, running Kubernetes images and serverless functions, and measure coverage per account.
Risk enrichment
Add EPSS scores, CISA KEV membership, internet reachability and data classification to every finding to compute a priority band.
Patch and rebuild pipelines
Automate golden image rebuilds monthly and on KEV disclosure, and rebuild container base images weekly with pipeline triggers to redeploy.
In-place patching
Configure Patch Manager, Azure Update Manager or VM Manager maintenance windows for long-lived servers, with pre- and post-patch checks.
Exceptions and end-of-life
Register exceptions with compensating controls and expiry, and plan upgrades or isolation for out-of-support operating systems.
Scan, Enrich, Rank, Rebuild: The Vulnerability Workflow
Risk-Ranked Vulnerability Scanning and Image Rebuild Workflow
Native scanners report CVEs from VMs, registries and functions into a central findings store, where exploit likelihood, KEV status and exposure produce a priority band. High-priority findings trigger image rebuilds or patch windows, and dashboards track exposure windows per team.
Select any component
Risk-Ranked Vulnerability Scanning and Image Rebuild Workflow: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Inspector, Defender Vulnerability Management and Artifact Analysis Compared
Inspector covers EC2, ECR images and Lambda functions, and supports agentless EC2 scanning for instances without the SSM agent.
Defender for Servers Plan 2 adds agentless scanning and premium vulnerability management; Arc extends the same scanning and patching to on-prem servers.
Artifact Analysis scans Artifact Registry images and keeps results updated as new CVEs appear; VM Manager handles OS patch jobs with rollouts by zone.
Priority Bands, Rebuild Versus Patch and Exception Handling
Defining priority bands
Use four bands. P1: KEV-listed or EPSS above 0.5 on internet-reachable or restricted-data assets, 7 days. P2: CVSS 9 or higher with EPSS above 0.1, or any KEV-listed internal asset, 30 days. P3: remaining high and critical, 90 days. P4: everything else, fixed at the next rebuild. Typically under 3% of instances land in P1.
Rebuild or patch in place
Stateless VMs in auto scaling groups or scale sets and all containers should be rebuilt from patched images and redeployed, never patched in place. Patch in place only long-lived stateful servers such as ERP application or database hosts. If more than 40% of your fleet needs in-place patching, plan a modernisation track; patch windows will not scale.
Agent or agentless scanning
Agentless snapshot scanning gives fast coverage with no deployment effort but runs daily rather than in near real time and may miss some application packages. Agents give continuous results and patch orchestration. Use agentless for coverage, agents for production servers patched in place, and accept slightly different counts between the two.
Handling end-of-life systems
Windows Server 2012 extended security updates ended on 13 October 2026, so any such server is now permanently unpatchable. Upgrade it, or move it into an isolated segment with no internet egress, strict inbound rules, application allowlisting and enhanced monitoring, with an exception reviewed every 90 days. Never leave it in a general application zone.
Standing Up Risk-Based Patching in Ten Weeks
Scanner rollout and coverage check
Enable scanners across all accounts and registries and list every asset without coverage.
Enrichment and priority bands
Build EPSS, KEV and exposure enrichment and agree bands and SLAs with engineering leads.
Image rebuild pipelines
Automate monthly and emergency golden image and base image rebuilds with redeploy triggers.
Patch windows for long-lived servers
Configure rolling maintenance windows with health checks and rollback.
Reporting, exceptions and EOL plan
Launch team dashboards, the exception register and the end-of-life remediation plan.
What you receive
Exposure Window and SLA Compliance Measures
| KPI | Typical target |
|---|---|
| Assets covered by vulnerability scanning | 98% or higher |
| P1 findings fixed within 7 days | 95% |
| Median golden and base image age | Under 30 days |
| Mean exposure window for KEV-listed CVEs | Under 10 days |
Scanner Gaps, Broken Patches and Exception Creep
| Risk | How NTSPL prevents it |
|---|---|
| A patch breaks a critical application in production | Patches deploy first to a canary group and staging, with automated health checks before each subsequent batch. |
| Scanners miss assets launched outside standard tooling | Weekly coverage reconciliation against the cloud inventory flags any unscanned instance. |
| Exceptions become permanent | Exceptions expire after 90 days at most and are reported to the CISO when renewed. |
Native cloud vulnerability scanners or Qualys, Tenable or Rapid7?
For cloud-only estates, native scanners now cover most needs: Amazon Inspector, Defender Vulnerability Management and Artifact Analysis scan VMs, images and functions, integrate with patch tools, and cost less. A commercial scanner remains the better choice when a large share of servers sits on-premises or in colocation, when the security team already runs a mature Qualys or Tenable programme with years of reporting, or when you need authenticated network scanning of appliances and databases. Many Indian enterprises run both: the commercial tool for on-prem and network scanning, native tools for cloud workloads, with findings combined in one priority model.
Key facts: Vulnerability Management
Vulnerability Management in Practice
2 Vulnerability Management scenarios, from Fintech (alternative credit scoring) and Defence manufacturing (MSME supplier), plus related platform case studies.
Credit-scoring startup cuts KEV exposure on internet-facing hosts from 38 days to 5
Defence MSME isolates 14 Windows Server 2012 hosts and reaches 96% patch SLA
Telecom VAS provider cuts daily pages from 2,300 alerts to 9 actionable incidents
IT services firm brings 43 Azure subscriptions under one policy hierarchy
Vulnerability Management: Frequently Asked Questions
What does a cloud vulnerability management programme cost?
NTSPL's ten-week setup typically costs INR 8-16 lakh depending on account count and image pipelines. Scanner charges are per instance, image or function scanned; for a 300-500 VM estate with a container platform, native scanning usually costs INR 60,000-2.5 lakh a month.
Why not just patch everything rated critical?
Because CVSS critical often covers thousands of instances, many never exploited in the wild or sitting on unreachable systems. Adding EPSS probability, CISA KEV status and exposure focuses effort on the 2-5% that attackers actually use, and gets those fixed within days rather than months.
How should we handle Windows Server 2012 after ESUs ended?
Extended security updates for Windows Server 2012 and 2012 R2 ended on 13 October 2026, so new flaws will not be fixed. Upgrade in place or rebuild on a supported release; until then, isolate the server, remove internet egress and monitor it closely under a time-limited exception.
Do RBI or SEBI rules specify patch timelines?
Regulators expect a documented, risk-based patch management process with timelines and evidence, rather than one fixed number for every system. Our priority bands, SLA reports and exception register give auditors that evidence, and CERT-In advisories are added as a trigger for out-of-cycle P1 patching.
Can container images be patched?
Containers should not be patched in place. The fix is to update the base image or dependency, rebuild, rescan and redeploy. We automate weekly base image rebuilds and trigger application rebuilds when a P1 or P2 CVE affects a base layer they use.
How do you measure success?
The key measure is exposure window: how many days a high-priority vulnerability remains open on a reachable asset. We also track scanner coverage, SLA compliance by band, image age and exception counts, published weekly by team so owners see their own numbers.