Cloud security vulnerability management has never been harder to get right. With 131 new CVEs disclosed every day and the median time to exploit now under five days, the question for security teams in 2026 is no longer whether vulnerabilities will be targeted, but whether the right ones are being fixed fast enough. If you are responsible for an AWS estate serving UK financial services or government workloads, that statistic should be sitting uncomfortably with you right now. This guide covers how to build a programme that actually keeps pace with the threat, not one that produces dashboards nobody acts on.

Why the traditional patching model is structurally broken

For years, vulnerability management meant: run a scan, export a CSV, hand it to the ops team, wait 30 days. That model is dead.

Mandiant’s M-Trends 2026 puts the mean time to exploit at negative seven days. Exploitation is routinely occurring before a patch is released. You are already behind before a CVE is even published.

CrowdStrike’s 2026 Global Threat Report documents a 42 percent increase in zero-day vulnerabilities exploited before public disclosure. The backlog is compounding too: in 2025, the public CVE programme published 48,185 new vulnerabilities, a 20.6 percent jump on top of the record 38 percent surge in 2024.

The consequence for cloud teams is straightforward. A reactive, scan-and-patch cycle built around monthly Patch Tuesdays cannot close that gap. You need continuous detection, context-aware prioritisation, and automation from discovery through to remediation.

A recent example makes this concrete. A zero-day called RoguePlanet dropped on 10 June 2026, hours after Microsoft rolled out its largest-ever Patch Tuesday update. The proof-of-concept targets a race condition in Microsoft Defender and grants SYSTEM-level shell access on fully patched Windows 10 and Windows 11 machines. Microsoft has acknowledged CVE-2026-50656 and confirmed a fix is in development, but as of 18 June 2026 has not announced a release timeline. This is a Windows endpoint vulnerability rather than a cloud-native one, but the escalation path matters for hybrid AWS environments where developer workstations and EC2 instances share the same credential plane.

CISA’s Known Exploited Vulnerabilities catalogue also recently gained a maximum-severity entry for CVE-2026-48907 (CVSS 10.0), an improper access control flaw in Widget Factory Joomla Content Editor that enables arbitrary code execution. Working exploit code is public, attacks are automated, and a site with no public registration is not safe. Joomla instances turn up on AWS more than most people expect: spun up by a marketing team on an EC2 instance, forgotten, and never patched. That is a real attack surface.

The attack surface reality in 2026

Before you can manage vulnerabilities, you need to know what you have. Most organisations dramatically underestimate their internet-facing footprint.

Intruder’s 2026 Attack Surface Management Index found that 60 percent of organisations had at least one HTTP panel exposed, 49 percent exposed a risky port or service, 42 percent had an exposed database, and 30 percent had files or information publicly accessible that should not have been.

Most teams treat patching as the priority. But for a lot of what appears on that list, databases, admin panels, legacy services, the better question is why they are reachable at all. A CVE in a database that has no business being internet-facing is not primarily a patching problem. It is an architecture problem. Cloud security vulnerability management must be paired with continuous asset discovery and exposure reduction, not just patch velocity.

Remediation speed varies significantly by organisation size. Small organisations remove exposures fastest, averaging 14 to 18 days. Remediation slows as companies grow into the midmarket, peaking at 56 days for organisations with 5,000 to 10,000 employees, before improving again at enterprise scale. Midmarket organisations have large attack surfaces but lack the headcount, budget, and tooling maturity of enterprise security teams. That is a predictable gap, and it is worth being honest about.

For UK organisations, the FCA’s operational resilience rules and the NCSC’s Cyber Assessment Framework both expect demonstrable visibility over your asset inventory. You cannot make a credible argument for proportionate risk management if you do not know what is internet-facing.

Amazon Inspector: your cloud-native scanning foundation

For AWS environments, Amazon Inspector is the baseline. It automatically discovers workloads including EC2 instances, container images, Lambda functions, and code repositories, then scans them for software vulnerabilities and unintended network exposure.

The operational advantages over third-party scanners are continuous re-scanning and native integration with AWS Organisations. All resources are rescanned when new CVEs are published or when changes occur, such as new software being installed on an EC2 instance or updates to a code repository. You are not dependent on a scheduled scan window. A new finding triggers assessment automatically.

Inspector also removes the operational overhead of deploying and configuring a standalone vulnerability management solution. You can deploy it across all accounts in a single step via a Delegated Administrator account, and it produces a contextualised risk score for each finding rather than raw CVSS. That score correlates CVE information with factors including network access and exploitability, which is what makes it useful for prioritisation rather than just reporting.

Enabling Inspector across an AWS organisation

Enable Inspector from your Security Tooling (or Audit) account, delegated as administrator via AWS Organisations. Here is the CLI approach to enable scanning for EC2, ECR, and Lambda across all member accounts:

# Enable Amazon Inspector for EC2 and ECR in the delegated admin account
# Run from the Security Tooling account with appropriate IAM permissions

aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA \
  --region eu-west-2

# Verify organisational coverage
aws inspector2 list-coverage-statistics \
  --filter-criteria '{
    "scanStatusCode": [{"comparison": "EQUALS", "value": "ACTIVE"}]
  }' \
  --group-by RESOURCE_TYPE \
  --region eu-west-2

# Gate CI/CD pipeline: block deployment on CRITICAL findings
check_ecr_image_before_deploy() {
  IMAGE_DIGEST=$1
  REPO_NAME=$2

  CRITICAL_COUNT=$(aws inspector2 list-findings \
    --filter-criteria "{
      \"ecrImageHash\": [{\"comparison\": \"EQUALS\", \"value\": \"${IMAGE_DIGEST}\"}],
      \"severity\": [{\"comparison\": \"EQUALS\", \"value\": \"CRITICAL\"}]
    }" \
    --query 'length(findings)' \
    --output text \
    --region eu-west-2)

  if [ "${CRITICAL_COUNT}" -gt 0 ]; then
    echo "DEPLOY BLOCKED: ${CRITICAL_COUNT} CRITICAL vulnerabilities in ${REPO_NAME}"
    echo "Review findings in the Inspector console or Security Hub before proceeding."
    exit 1
  fi

  echo "No CRITICAL findings. Proceeding with deployment."
}

# Usage: check_ecr_image_before_deploy "sha256:abc123..." "my-api-service"

Inspector integrates with AWS Security Hub and Amazon EventBridge, which means you can pipe findings directly into your ITSM (ServiceNow, Jira) and set SLA clocks running automatically. For FCA-regulated environments, that audit trail of discovery-to-remediation timestamps is not optional.

What Inspector does not cover

Inspector does not scan everything. It will not catch IAM misconfigurations, overly permissive Security Group rules, or S3 bucket policies. That is the remit of AWS Config, Security Hub, and tools like Prowler mapped to the CIS AWS Foundations Benchmark. Treat Inspector as the CVE and network-exposure layer, and Config as the compliance and misconfiguration layer. You need both.

Risk-based prioritisation: moving beyond CVSS

With 131 new CVEs every day, manual triage is not viable. Teams that rely on raw CVSS scores are working from delayed, incomplete risk signals. Prioritisation that factors in exploitability, network exposure, and asset criticality is the minimum viable approach in 2026.

The CISA KEV catalogue is your highest-signal input. Binding Operational Directive 26-04 requires US federal agencies to prioritise rapid remediation of KEV-listed vulnerabilities on publicly exposed assets that grant total control post-exploitation. The UK public sector should treat that framing as directly applicable. The NCSC’s own vulnerability management guidance aligns with this risk-based, exploitation-evidence approach.

CISA also encourages all organisations, not just federal agencies, to adopt risk-based vulnerability management and prioritise KEV catalogue entries. In practice, a KEV entry should trigger an emergency change window, not sit in the queue until the next Patch Tuesday.

A workable prioritisation structure looks like this:

These SLAs should be codified in your vulnerability management policy, reviewed annually, and tested by your internal audit function. Under GDPR and NIS2 (as transposed into UK law post-Brexit), a systematic, documented response process is part of your accountability obligation, not a nice-to-have.

AWS Continuum: where cloud vulnerability management is heading

AWS announced AWS Continuum on 17 June 2026. It discovers, prioritises, validates, and remediates security risks at machine speed within guardrails you define. Frontier models have made finding software vulnerabilities faster and cheaper, but the harder work comes after: deciding which vulnerabilities matter to your business, proving which are exploitable, and fixing them without days of cross-team coordination.

Continuum operates in four continuous phases for code vulnerabilities. It starts by ingesting your existing backlog and performing its own scan, building a more complete view of vulnerabilities and associated attack paths. It then uses environmental context to evaluate every finding: is the affected component deployed, is it reachable, is it in a production path, and what is the business impact if exploited? Before surfacing a finding to your team, it validates it to filter false positives, constructing working exploit examples in a sandboxed environment with concrete, reproducible evidence of the issue. Remediation recommendations arrive with the reasoning behind them.

Continuum starts in learn mode with a human reviewing its work. Customers can move it to enforce mode, where remediation becomes increasingly automated according to categories and risk profiles they define.

This is currently in gated preview. I would caution against treating it as a replacement for the foundational stack: Inspector, Security Hub, Config, and EventBridge remain your production-grade continuous scanning layer. Continuum’s value is in closing the triage-to-fix loop at scale. Evaluate it on a non-production workload first and validate its remediation recommendations against your change management process before allowing it to operate in enforce mode.

Common pitfalls in cloud security vulnerability management

These are the patterns I see repeatedly in assessments and red-team engagements.

1. Treating Inspector coverage as automatic

Inspector is not enabled by default. If you have added new accounts to your AWS Organisation without explicitly delegating and enabling Inspector, those accounts are dark. Inspector provides a coverage dashboard showing which accounts and resources are actively scanned, and highlights those that are not. Check it weekly. Dark accounts are the most common coverage gap I find.

2. Ignoring CMS and third-party software running on EC2

Inspector scans OS packages and Lambda runtimes well. It does not scan PHP application code, WordPress plugins, or Joomla extensions running on your web servers. A 2025 study found that over 40 percent of Joomla sites run at least one extension with a known vulnerability, and only 30 percent of those were patched within 30 days of disclosure. Application-layer scanning via AWS WAF, Burp Suite Enterprise, or equivalent is a separate requirement alongside Inspector.

3. CVSS score theatre

A CVSS 10.0 finding on an instance with no network path to it is lower priority than a CVSS 7.8 on a public-facing API endpoint. A high severity score can overstate risk for an unreachable component. A medium score can understate it for a bug that is actively weaponised against exposed systems. Build network reachability context into your triage process from day one, not as an afterthought.

4. Closing tickets without verifying remediation

Inspector automatically closes a finding when it detects a patch has been applied, but only if the SSM Agent is functioning and inventory collection is working. That automatic closure depends on accurate inventory. Verify SSM Agent health as part of your operational runbook, not just when something breaks.

5. No compensating controls for unpatched zero-days

When a patch does not exist, as with RoguePlanet (CVE-2026-50656) right now, you need a documented compensating control, not a deferred ticket. The current guidance for that specific CVE includes monitoring Windows Event Logs for unexpected SYSTEM-level process creation, deploying EDR detections for rapid file-substitution activity, enforcing least-privilege access controls, restricting unnecessary development tools, enabling Attack Surface Reduction rules in block mode, and applying Microsoft’s fix as soon as it is available. The same principle applies to any unpatched vulnerability affecting your cloud-adjacent endpoints: compensate, detect, document.

6. Leaving NVD as your sole intelligence source

As of April 2026, NVD operates effectively as a triage queue. Approximately 29,000 legacy CVEs are marked “Not Scheduled” and only an estimated 15 to 20 percent of new CVEs are receiving full enrichment. Vulnerability programmes that rely on NVD CPE matching alone are blind to a substantial portion of the population. Supplement NVD with CISA KEV, vendor advisories, and a commercial threat intelligence feed.

Key takeaways

Assume you are already behind. Mandiant’s M-Trends 2026 puts estimated mean time to exploit at negative seven days. Your programme must assume exploitation can precede patch availability, and invest accordingly in detection and compensating controls.

Enable Amazon Inspector across your entire AWS Organisation from a delegated admin account. Gate container deployments on CRITICAL findings, automate findings into Security Hub, and set SLA clocks via EventBridge. Verify coverage weekly. Dark accounts are a persistent failure mode.

Prioritise by exploitation evidence, not CVSS alone. CISA KEV entries on internet-facing assets should trigger emergency change windows within 24 hours. CVSS without network reachability context is noise.

Inspector does not cover everything. It scans OS packages, Lambda runtimes, and ECR images. Application-layer vulnerabilities in CMS plugins, custom code, and IAM misconfigurations require additional tooling: AWS WAF, Prowler or Config Rules, and application security testing in CI/CD.

Document compensating controls for unpatched vulnerabilities. When no patch exists, a scenario that is now routine, you need a recorded interim control, not an open ticket. This is a UK GDPR Article 32 obligation as much as a security one.

Watch AWS Continuum. Evaluate it on non-production workloads now so you understand its behaviour before it reaches enforce mode in production. The gap between vulnerability discovery and remediation is where most organisations lose time, and that is exactly where Continuum is designed to operate.