Patch & vulnerability posture
Patch and vulnerability posture is the discipline of finding, prioritizing, and closing known-vulnerable software across everything your cloud runs — virtual machines, container images, serverless runtimes, and the engine versions behind managed services. The cloud does not make patching disappear; the shared-responsibility model moves it, so the provider hardens the platform and control plane while you remain responsible for the guest OS, your container base images, your function runtimes, and choosing supported versions of managed databases and clusters. The vulnerabilities that matter most are the ones that are both known and reachable — a published CVE on an internet-facing workload is a very different problem from the same CVE buried on an isolated internal host. We assess whether a working process exists to discover these across the whole estate, how findings are prioritized, and how long fixes actually take from disclosure to deployment. The goal is not a zero-vulnerability score, which no live system reaches, but a measurable, defensible remediation rhythm for the exposure that can actually be exploited.
Overview
What this check looks like in practice
Cloud does not remove the need to patch — it moves it, and unpatched compute, stale images, and known-vulnerable managed-service versions remain a common path to compromise. We assess whether there is a working process to find and remediate known vulnerabilities across instances, containers, and images, and how long fixes actually take. The focus is on the exposure that is both known and reachable.
Why it matters
Known, unpatched vulnerabilities on reachable surfaces are the path of least resistance for an attacker: they need no zero-day and no phishing when a public workload is running software with a documented, weaponized CVE. Cloud makes this worse in a specific way — autoscaling and image reuse mean one stale base image can propagate the same vulnerability across many ephemeral instances faster than a manual patch cycle can chase them. Auditors and cyber-insurers probe this area directly because a documented scan cadence and a remediation SLA by severity are the clearest proof that vulnerability management is operated rather than assumed, and a missing or unenforced SLA is a common reason a renewal questionnaire stalls. End-of-life operating systems and unsupported managed-service engine versions are especially dangerous because they stop receiving security fixes entirely, turning every future disclosure into a permanent exposure until the platform is upgraded. Done well, this maps directly to the vulnerability and patch-management controls in PCI-DSS, NIST CSF, ISO 27001, SOC 2, and the CIS Benchmarks, so the same evidence serves multiple frameworks at once.
What we assess
What we look for
- A managed patch or update service (SSM Patch Manager, Azure Update Manager, GCP OS Config VM Manager) is in use across all compute with a measurable compliance percentage, rather than ad-hoc manual patching
- Continuous vulnerability scanning is enabled for instances, container images in registries, and serverless functions across every account, subscription, and project — not just one flagship account
- Container and machine images are scanned before deployment in CI and continuously in the registry, with a severity gate that can actually block a vulnerable image from being promoted
- Internet-reachable resources are cross-referenced against known-exploited vulnerabilities (for example the CISA KEV catalog) so reachable-plus-exploitable findings rise above raw CVSS counts
- End-of-life operating systems, language runtimes, and managed-service engine versions (RDS/Cloud SQL/Azure SQL engines, Lambda/Functions runtimes) are identified where they run past vendor support
- Golden or base images are rebuilt and redeployed on a defined cadence, so long-lived instances and containers do not drift away from a patched baseline
- Documented remediation SLAs exist by severity, with evidence that critical vulnerabilities are actually closed within them rather than logged and forgotten
- Patch and scan coverage extends to managed Kubernetes node pools and their node images (EKS/AKS/GKE), not only standalone VMs
Across your clouds
AWS, Azure & Google Cloud
AWS
Amazon Inspector provides continuous CVE scanning of EC2 instances, ECR container images, and Lambda functions; Systems Manager Patch Manager applies patch baselines, maintenance windows, and compliance reporting across managed instances; ECR enhanced scanning (backed by Inspector) covers registry images. We also review RDS/Aurora engine-version deprecation and the AMI currency of EKS managed node groups.
Azure
Microsoft Defender for Cloud vulnerability assessment (the Defender Vulnerability Management engine surfaced via the Defender for Endpoint integration) scans VMs and Azure Container Registry images; Azure Update Manager orchestrates OS patching and compliance reporting; AKS node-image and Kubernetes auto-upgrade posture keeps clusters current. We also track supported-version status for Azure SQL and other managed database engines.
Google Cloud
OS Config VM Manager handles patch deployment, OS inventory, and vulnerability reports on Compute Engine; Artifact Registry with Container Analysis performs automatic and on-demand image scanning; GKE node auto-upgrade and release-channel posture govern cluster currency; Security Command Center aggregates vulnerability findings. We also review Cloud SQL maintenance settings and engine-version deprecation exposure.
Example finding
Internet-facing autoscaled instances on an end-of-life OS with a known-exploited CVE and no patch baseline attached
Risk: The workload is reachable from the internet, is running software with a publicly documented and actively exploited vulnerability, and sits on an OS release that no longer receives security updates — so the exposure is permanent until the platform is upgraded, and autoscaling reproduces the same vulnerable image on every new node it launches.
Fix: Rebuild the workload on a supported, patched base image and roll it out through the deployment pipeline, attach a managed patch baseline with a maintenance window so the fleet stays current, and prioritize this class of finding — internet-reachable plus known-exploited plus unsupported — ahead of higher-CVSS but unreachable issues.
Remediation
How to close it
- 1 Build an authoritative inventory of what runs: compute instances, container images, serverless runtimes, and the engine versions behind managed databases and clusters, across every account, subscription, and project.
- 2 Turn on native vulnerability scanning everywhere it applies — Amazon Inspector, Defender for Cloud vulnerability assessment, and GCP Container Analysis / OS Config VM Manager — organization-wide rather than per-account.
- 3 Prioritize findings by reachability and known exploitation first: internet-exposed workloads carrying actively exploited CVEs before high-CVSS issues that nothing can reach.
- 4 Adopt a managed patch service (SSM Patch Manager, Azure Update Manager, OS Config) with patch baselines and maintenance windows, and define written remediation SLAs by severity.
- 5 Gate the pipeline: scan images in CI and continuously in the registry, and fail promotion for images that exceed the agreed severity threshold rather than fixing them in production.
- 6 Maintain an end-of-life calendar for operating systems, language runtimes, and managed-service engine versions, and schedule upgrades before vendor support ends so no workload runs unsupported.
Questions
Isn't patching automatic in the cloud?
Only partly. Under the shared-responsibility model the provider patches the underlying platform and the control plane of fully managed services, but you remain responsible for the guest OS on your instances, the packages in your container base images, your function runtimes, and choosing supported versions of managed databases and clusters. Automation helps, but it has to be configured and its coverage verified — which is exactly what this part of the assessment checks.
Do you run vulnerability scans against our systems?
No. The assessment is read-only and non-intrusive. We read the output and configuration of your existing native scanners — Amazon Inspector, Defender for Cloud, Container Analysis — and your patch-management state, rather than launching active or exploitative scans that could touch production. You get a prioritized picture of your known-vulnerability exposure without anything being changed or probed aggressively.
There are thousands of CVEs in our reports. How do you decide what matters?
We rank by reachability and real-world exploitation, not raw count or CVSS alone. A vulnerability that is internet-reachable and appears on a known-exploited-vulnerabilities list outranks a higher-scored issue on an isolated internal host that no attacker can reach. That turns an unmanageable flat list into a short, defensible order of what to fix first.
More in configuration & posture
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
