Cloud Security Vulnerability Management: a practitioner’s guide for AWS environments
Cloud security vulnerability management is a continuous operational discipline, not a periodic hygiene exercise. Cloud infrastructure changes constantly as teams deploy new workloads, APIs, and services across multi-account and hybrid environments, and each change can introduce vulnerabilities, misconfigurations, or exposed attack paths that attackers can reach within minutes. For UK financial services firms under FCA oversight, or any organisation handling personal data under UK GDPR, the stakes are higher still: a single unmitigated CVE in a production workload is not just a technical failing, it is a potential regulatory event.
This guide is for cloud security architects and senior engineers building and running vulnerability management programmes on AWS. It covers the full cycle: asset visibility, scanning, risk-based prioritisation, remediation automation, and the pitfalls that undermine even well-intentioned programmes.
Why continuous VM is no longer optional
Any team still relying on quarterly scans is, bluntly, operating blind. NIST reported that in 2024 it received 32% more vulnerability submissions than the previous year, a trend it expects to continue throughout 2025. CVE registrations increased similarly, by 20% in 2024, and by the end of May 2025 there were more than 280,000 CVEs in the national database.
Volume is only part of the problem. Attackers now weaponise many flaws within hours of public disclosure. The median defender response window shrank from five days in 2023 to less than one day in 2024, according to Mandiant. That compression makes any scan cadence longer than a few days operationally irrelevant for the most critical findings.
The NCSC has been direct about where this is heading. Its CTO has written publicly about expecting a “forced correction” to address the technical debt that has accumulated across proprietary and open source software, driven partly by AI-assisted vulnerability discovery on both sides. The NCSC’s formal advisory on this makes the operational implication clear: organisations should make plans to deploy software security updates quickly, more frequently, and at scale, including across their supply chains.
The NCSC’s 14 Cloud Security Principles remain the authoritative UK cloud security framework. Updated for 2025, they help organisations assess whether cloud services meet their security requirements across data protection, personnel security, and operational resilience. Principle 5, operational security, explicitly names vulnerability management as a required control.
Building an asset inventory you can actually trust
You cannot scan what you cannot see. Incomplete asset visibility is the single most common reason cloud vulnerability management programmes fail, particularly in multi-account AWS organisations where teams provision infrastructure independently and rarely tell anyone about it.
Amazon Inspector is a vulnerability management service that continuously monitors your AWS workloads for software vulnerabilities and unintended network exposure. It automatically discovers and scans running EC2 instances, container images in Amazon ECR, and Lambda functions, without requiring you to configure scan targets manually.
For organisations using AWS Organizations, Inspector integrates natively. You delegate an administrator account for the organisation, and that account consolidates all findings and configures all member accounts from a single place. No per-account setup, no manual enrollment.
One architectural point worth making clearly: scanning cloud resources with network sweeps, as you would on-premises, does not translate well to cloud. Short-lived resources disappear before a scan completes, and multi-account VPC architecture means network-based scanners often cannot reach what they need to reach. Agent-based scanning is the right model here. Inspector also supports agentless scanning of EBS volumes in hybrid scan mode, which is useful for virtual appliances or instances where you cannot install the SSM Agent, but the agent-based approach gives you more timely results.
Risk-based prioritisation: why CVSS alone will let you down
Once your scanner is generating findings, the instinct is to sort by CVSS score and work down the list. Resist it. FIRST’s own research found that of all CVEs scored CVSS 7.0 or higher, only about 2.3% were actually observed in exploitation attempts over a given month. In Q1 2025, 28% of exploited vulnerabilities carried only medium CVSS base scores. If you are running a CVSS-first prioritisation model, you are systematically deprioritising more than a quarter of the vulnerabilities that attackers are actually using.
CVSS gives you a standard measure of severity, but it tells you nothing about exploitability in your specific environment. Combining it with real-world signals is what makes prioritisation meaningful.
The practical framework I use with clients combines three signals:
EPSS score. The Exploit Prediction Scoring System quantifies the probability that a CVE will be weaponised in the next 30 days. EPSS v4, released in March 2025, consumes more than 250,000 threat intelligence data points daily and can now score CVEs sitting in the NVD backlog, which matters when official analysis is delayed by weeks.
Network reachability. Is the affected workload internet-facing, behind a WAF, or in a private subnet with no egress route? Amazon Inspector correlates vulnerability data with environmental factors including external network accessibility to produce a contextualised risk score, rather than a generic severity label.
Business impact. Does the workload process payment card data, store PII, or sit in a regulated account? Frameworks like Stakeholder-Specific Vulnerability Categorisation (SSVC) fold business impact directly into decision trees, so a flaw on a production data-processing service automatically outranks the same flaw on a dormant test box.
Remediation automation: closing the loop at scale
Detection without remediation is theatre. The goal of vulnerability management is a short, measurable mean time to remediate (MTTR), and that requires automation at every layer of the stack.
For OS-level patching across EC2 fleets, AWS Systems Manager Patch Manager is the right tool. Using patch policies, you can configure recurring patching operations across all accounts and regions in your organisation, or scope them to specific account-region pairs. You can choose to scan only, producing a report of missing patches, or scan and automatically install.
Custom patch baselines let you define exactly what constitutes compliance: which patch classifications are in scope, which severity levels trigger auto-approval, and how long a patch must be available before it is automatically applied. Patch Manager integrates with both AWS Organizations and Security Hub.
Here is a minimal CloudFormation resource block to create a custom patch baseline for Amazon Linux 2 that auto-approves Critical and Important security patches after a 7-day delay. That delay is a sensible default for production workloads where you want a brief soak period before auto-deployment:
Resources:
AmazonLinux2PatchBaseline:
Type: AWS::SSM::PatchBaseline
Properties:
Name: "AmazonLinux2-Critical-Important-7DayDelay"
Description: "Auto-approves Critical and Important security patches after 7 days"
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: CLASSIFICATION
Values:
- Security
- Key: SEVERITY
Values:
- Critical
- Important
ApproveAfterDays: 7
EnableNonSecurity: false
Tags:
- Key: Environment
Value: Production
- Key: ManagedBy
Value: SecurityTeam
Deploy this via a CloudFormation StackSet targeting your entire AWS Organisation, then associate it with a Patch Group tag (Patch Group: production-linux) on your EC2 instances. Systems Manager handles the rest.
For container workloads, the remediation loop is different. You rebuild the container image with the patched base layer, you do not patch running containers, and you push it through your CI/CD pipeline. Inspector’s SBOM export capability helps here: centralising software bill of materials data for all monitored resources gives you a clear picture of what needs rebuilding and in what order.
Closing the configuration gap
Software CVEs are only half the picture. According to the 2025 Verizon Data Breach Investigations Report, around 30% of error-based data breaches involved misconfigurations. Attackers scan for misconfigured storage, leaked keys, and vulnerable APIs continuously, often faster than internal teams detect the drift.
Infrastructure as Code is your first line of defence here. When security configurations, such as encrypted S3 buckets and restricted security group rules, are defined in code and deployed consistently, the opportunity for manual misconfiguration shrinks significantly. AWS Config combined with Lambda-based remediation takes this further: if an S3 bucket is accidentally made public, a Lambda function can revert it automatically before anything exfiltrates.
AWS Config conformance packs aligned to the CIS AWS Foundations Benchmark give you a codified, auditable baseline. For FCA-regulated firms, mapping Config rules directly to your control framework, whether ISO 27001:2022 or NCSC Cyber Essentials Plus, produces the evidence trail that auditors and the regulator expect to see.
Common pitfalls in cloud vulnerability management programmes
These are the failure modes I see repeatedly in production environments. None of them are exotic.
1. Treating VM as a point-in-time activity
Cloud infrastructure, permissions, and workloads change continuously. Static reviews and point-in-time controls cannot keep pace with ephemeral workloads and configuration drift. If your VM cadence is monthly or quarterly, your scan results are stale before remediation even begins. In cloud environments, continuous scanning is the baseline expectation, not a premium capability.
2. Scanning without a remediation SLA
Findings with no owner, no SLA, and no escalation path accumulate until they become unmanageable. Define clear SLAs by severity. A reasonable starting point: Critical findings (CVSS 9.0 or higher with high EPSS) patched within 24 hours, High within 7 days, Medium within 30 days. Track MTTR as a metric reported to leadership, not just to the security team.
3. Ignoring container and Lambda attack surface
Unpatched EC2 instances are a well-understood attack vector, but container images and Lambda function layers get far less attention. Perfect network segmentation and tight IAM policies do not help you if a running container has a known CVE with a public exploit. Inspector covers all three compute types. Make sure all three are actually enrolled.
4. Over-relying on CVSS score alone
CVSS tells you a vulnerability is severe. It does not tell you whether that vulnerability is exploitable in your environment given your current controls. That second question is the only one that matters for operational prioritisation. Layer in EPSS and Inspector’s network reachability data before deciding where to spend remediation effort.
5. No visibility across the full AWS organisation
Inspector and Security Hub must be enabled in every account, in every region where you run workloads. A shadow account provisioned by a development team without centralised scanning is a blind spot. Most cloud security incidents trace back to customer-side issues: identity misuse, misconfigurations, and exposed workloads. Enforce Inspector enablement as an SCP-backed requirement so teams cannot opt out.
6. Conflating vulnerabilities and misconfigurations
These require different remediation workflows. A vulnerability is a flaw inside the software itself: a bug in the code, an outdated library, a zero-day. Log4Shell (CVE-2021-44228) is the obvious example. No configuration change fixes it; you have to patch the code. Misconfigurations are corrected by changing settings. Mixing the two in the same remediation workflow creates confusion about who owns what and which tooling applies.
Key takeaways
An effective vulnerability management process gives you a regular, validated picture of which vulnerabilities exist in your estate, where patching is failing, and how to reduce impact systematically. The NCSC recommends running assessments at minimum monthly; in cloud environments, continuous scanning is the standard.
Amazon Inspector is your baseline scanner for EC2, Lambda, and container images across an AWS organisation. Enable it via a delegated administrator account and feed findings into Security Hub for triage.
CVSS is a starting point, not a finishing point. Layer EPSS scores, network reachability data, and business context to build a prioritisation model that reflects actual exploitability in your environment, not theoretical severity.
Patch Manager combined with CloudFormation StackSets gives you a scalable, auditable path to OS-level patch compliance across multi-account organisations. Define custom patch baselines per OS family with appropriate auto-approval delays.
Misconfigurations and CVEs require separate remediation workflows. Use AWS Config conformance packs aligned to CIS benchmarks for configuration drift, and Inspector with SSM Patch Manager for software vulnerabilities.
Default to applying updates automatically where you can. For most production EC2 workloads in regulated UK environments, a 7-day auto-approval delay strikes the right balance between deployment speed and operational stability.