AWS Inspector vulnerability management: the definitive practitioner’s guide

If your organisation is running workloads on AWS in 2025 and not actively managing vulnerabilities through Inspector, you are almost certainly carrying unquantified risk into production. The NCSC has warned organisations to prepare for a “patch wave” as exploitation timelines compress and AI tooling lowers the barrier for attackers. Against that backdrop, continuous automated vulnerability scanning is not optional for any organisation subject to FCA operational resilience requirements or NCSC CAF obligations.

This guide covers Amazon Inspector v2 end-to-end: what it scans, how it scores findings, how to deploy it across a multi-account AWS Organisation, how to build automation on top of it, and where teams consistently go wrong. I have written it for practitioners who need to implement and operate this, not for a sales deck.

What Amazon Inspector v2 actually is (and what v1 was not)

Before getting into implementation, it is worth being explicit about the architectural shift between Inspector Classic and v2, because teams still carry misconceptions from the old service.

Inspector v1 ran point-in-time assessments. You scheduled a run, waited for results, reviewed them, and repeated. Inspector v2 scans continuously. That is a fundamental operational difference. The other significant change is that it is entirely agentless for EC2. Instead of deploying and maintaining the Inspector agent, Inspector v2 uses the AWS Systems Manager (SSM) agent, which is already present on most modern EC2 instances.

Amazon Inspector is an automated vulnerability management service that continually scans AWS workloads for software vulnerabilities and unintended network exposure. Today it covers four primary scan surfaces:

• Amazon EC2: package vulnerability scanning and network reachability analysis
• Amazon ECR container images: scanning images at rest in your registry and within CI/CD pipelines
• AWS Lambda functions: scanning function code and layer packages
• Code repositories: SAST, SCA, and IaC scanning via native GitHub and GitLab integration (GA since June 2025)

The continuous model is the real operational benefit. When the NVD publishes a new CVE, Inspector automatically re-evaluates your entire inventory against it. You do not need to remember to re-run a scan. A base image you pushed six months ago may generate a new Critical finding today when a new CVE lands. That is expected behaviour, not a bug.

Enabling Inspector at scale: multi-account organisation deployment

For any organisation of meaningful size, you should be deploying Inspector through AWS Organizations with a dedicated Delegated Administrator account. Running Inspector account-by-account, or from the management account itself, is an anti-pattern.

Designating the delegated administrator

The delegated administrator manages Amazon Inspector for the organisation and can enable or disable scans for member accounts, view aggregated finding data, and create and manage suppression rules across the estate.

My strong recommendation is to use your dedicated Security Tooling account as the Delegated Administrator. The blast radius is limited to the services delegated to that account, rather than the entire organisation. This is the core reason not to use the management account directly.

One regional caveat worth flagging: Inspector is a Regional service. You must designate a delegated administrator in each region where you want organisation-wide coverage. If you operate across eu-west-2 (London) and eu-west-1 (Ireland), you need to configure the administrator in both.

Enable Inspector across your organisation from the Delegated Admin account:

# Step 1: From the management account — enable trusted access
aws organizations enable-aws-service-access \
  --service-principal inspector2.amazonaws.com

# Step 2: Designate your Security Tooling account as Delegated Admin
aws inspector2 delegate-admin-account \
  --delegated-admin-account-id 123456789012 \
  --region eu-west-2

# Step 3: From the Delegated Admin account — enable all scan types
# for all member accounts across the Organisation
aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA \
  --region eu-west-2

# Step 4: Check coverage status across member accounts
aws inspector2 batch-get-account-status \
  --account-ids 111111111111 222222222222 333333333333 \
  --region eu-west-2

Organisation policies enforce which scan types are enabled and take precedence over individual account settings, which means you can push a consistent configuration across the estate without relying on account owners to do the right thing.

Preventing members from disabling Inspector

One governance gap I see repeatedly: member accounts can disable Inspector for themselves, silently breaking your coverage. Lock this down with an SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventInspectorDisable",
      "Effect": "Deny",
      "Action": [
        "inspector2:Disable",
        "inspector2:DisassociateMember",
        "inspector2:DeleteFilter"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalAccount": [
            "123456789012"
          ]
        }
      }
    }
  ]
}

Replace 123456789012 with your Delegated Admin account ID. Apply this SCP to the root of your Organisation or to the OU containing all workload accounts. Without it, a single inspector2:Disable call from a member account creates a blind spot you may not notice for weeks.

EC2 scanning: agent-based vs. agentless

In hybrid scan mode, Inspector uses the SSM Agent for application inventory collection and falls back to agentless scanning for instances where SSM is not installed or configured. Hybrid mode is on by default for new customers enabling EC2 scanning, and it is the right default.

During agentless scanning, Inspector generates an EBS snapshot for each volume attached to the instance. These snapshots are ephemeral and never leave your account, but they do add a small cost in snapshot API calls. For UK financial services clients running large EC2 fleets, I budget roughly £1 to £1.50 per instance per month for Inspector EC2 scanning in hybrid mode at scale.

Network reachability findings are also worth reviewing. Inspector compares instance metadata against security advisories to detect both package vulnerabilities and network exposure, with reachability scans running every 24 hours. For organisations working towards NCSC Cloud Security Principle 9 compliance, these findings are directly relevant evidence.

Understanding the Inspector score vs. raw CVSS

This is where practitioners most often miscalibrate their remediation priorities.

Inspector findings include both the CVSS score and the Inspector score. The CVSS score is the industry-standard severity rating assigned to the CVE itself: the theoretical worst-case impact in isolation, on a scale of 0 to 10. A CVSS 9.8 is critical in every environment regardless of context.

The Inspector score is more useful for prioritisation. It is generated for each finding by correlating CVE information with network reachability results, exploitability data, and EPSS probability. A concrete example: if a new CVE can only be exploited remotely and Inspector’s network reachability scan shows the affected instance has no internet path, the Inspector score is adjusted downward to reflect that the vulnerability is materially less likely to be exploited in that specific environment.

Beyond CVSS, Inspector enriches findings with threat intelligence: names of known malware kits, MITRE ATT&CK mapping, the date CISA added the CVE to the Known Exploited Vulnerabilities Catalogue (KVCV), the EPSS score, and evidence of public exploitation events. This data comes from internal Amazon research, CISA, and Recorded Future.

My recommended prioritisation model for UK enterprise clients:

1. Inspector Score 9.0 or above AND Exploit Available = YES: fix within 24 hours
2. Inspector Score 7.0 or above OR CISA KEV listed: fix within 7 days
3. Inspector Score 4.0 to 6.9: fix within your standard patch cycle (typically 30 days for FCA-regulated firms)
4. Inspector Score below 4.0: schedule into the next maintenance window

This maps broadly to the NCSC’s vulnerability management guidance on prioritising by actual exploitability rather than theoretical severity.

Container and Lambda scanning

ECR image scanning

For ECR, Inspector performs continuous scanning. Images are re-evaluated when new CVEs are published, not just when you push a new image. A base image you pushed six months ago may generate a new Critical finding today. That is expected behaviour.

For teams using CI/CD pipelines, Inspector integrates directly via purpose-built plugins for Jenkins, AWS CodePipeline, GitHub Actions, and TeamCity. My recommendation is to enforce a build gate: any Critical or High finding with fixAvailable = YES should fail the pipeline. There is no justification for knowingly deploying a patchable Critical vulnerability to production.

Lambda function scanning

Lambda scanning covers both the function code and attached layers. Inspector monitors and assesses only the $LATEST version continuously. If you are pinning production invocations to published versions (which you should be), check findings against $LATEST and apply the same fix before publishing your next version. Leaving stale published versions in circulation while only patching $LATEST is a common oversight.

Code repository scanning (new in June 2025)

Code Security was announced at general availability on 17 June 2025. It extends vulnerability detection into source code repositories by integrating directly with GitHub and GitLab. It provides three capabilities: SAST for analysing application source code, SCA for evaluating third-party dependencies, and IaC scanning for CloudFormation and Terraform templates.

Findings are surfaced in the Inspector console for an aggregated view across the organisation and within your SCM platform as direct feedback for developers. The integration can automatically suggest fixes as pull request or merge request comments for Critical and High findings, which means developers see the issue in context without having to context-switch into a separate console.

Code Security is available in eu-west-2 (London), eu-central-1 (Frankfurt), eu-west-1 (Ireland), and eu-north-1 (Stockholm), so UK-based teams with London as their primary region are fully covered.

Integrating Inspector with Security Hub and EventBridge

Inspector findings in isolation are necessary but not sufficient. The operational value comes from integrating them into your wider security operations workflow.

Security Hub integration

When both Inspector and Security Hub are enabled, findings flow automatically with no additional configuration required. Security Hub correlates findings across GuardDuty, Inspector, CSPM, and Macie, organising them by threats, exposures, resources, and security coverage, and calculates exposures in near real-time.

This correlation is genuinely useful in incident response. A GuardDuty finding indicating unusual outbound traffic from an EC2 instance, combined with Inspector findings showing that instance has three unpatched Criticals, is a far stronger signal than either finding in isolation.

EventBridge automation

EventBridge rules can identify findings based on criteria you specify and route them to Lambda functions or Systems Manager Automation runbooks for processing and remediation. This is how you get from “visibility” to “action” without manual intervention.

Here is a working EventBridge rule pattern that triggers on any new Critical Inspector finding with a known exploit and routes it to an SNS topic:

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"],
  "detail": {
    "severity": ["CRITICAL"],
    "status": ["ACTIVE"],
    "exploitAvailable": ["YES"]
  }
}

For a more complete automation pipeline, pair this with an SSM Automation runbook that opens a Jira ticket, tags the affected resource with inspector:remediation-required, and notifies the resource owner via SNS. Inspector findings without downstream automation are just an alert backlog. Wire Inspector into Security Hub, then EventBridge, then Lambda or SSM Runbook to get automated ticket creation, resource tagging, and MTTR tracking that satisfies FCA and NCSC audit expectations.

Software bill of materials (SBOM) export

SBOM generation has become increasingly relevant for both supply chain security and regulatory compliance. Under GDPR’s accountability principle and emerging UK product security legislation, being able to rapidly enumerate every software package across your fleet is a reasonable audit expectation.

Security teams can export a consolidated SBOM to Amazon S3 for an entire organisation from the Inspector console. Inspector supports CycloneDX 1.4 and SPDX 2.3 formats, exported as JSON files to an S3 bucket of your choice. SBOM exports are free.

The CLI command to trigger an SBOM export to a KMS-encrypted S3 bucket:

aws inspector2 create-sbom-export \
  --report-format CYCLONEDX_1_4 \
  --s3-destination \
    bucketName=my-inspector-sbom-exports,\
    keyPrefix=sboms/2025-07/,\
    kmsKeyArn=arn:aws:kms:eu-west-2:123456789012:key/mrk-abc123def456 \
  --region eu-west-2

Inspector requires a customer-managed, symmetric KMS key to encrypt the report, and the key must be in the same region as the S3 bucket. For UK financial services clients, this also satisfies the FCA’s expectation around data confidentiality for internal security artefacts.

A scheduled SBOM export via EventBridge Scheduler, with Athena queries against the output, gives you a defensible audit trail of your software supply chain posture without significant additional investment.

Managing findings at scale: suppression rules

At enterprise scale, Inspector will generate thousands of findings across hundreds of accounts. Without a disciplined suppression strategy, you will drown in noise and lose sight of what genuinely matters.

Suppression rules permanently move matching findings to SUPPRESSED status, removing them from your active findings count. Use them for documented false positives, accepted risks recorded in your risk register, or findings in non-production environments tracked separately.

Treat suppression rules as formal security exceptions. Every rule must have a documented business justification, an owner, and a review date. This is directly relevant to the NCSC CAF requirement to demonstrate that accepted risks are explicitly and knowingly accepted rather than overlooked. Suppression rules without documented rationale are a potential GDPR Article 32 and FCA operational resilience compliance gap. I have seen audit findings raised against organisations specifically because they had hundreds of suppression rules with no documented justification.

Example: suppressing a specific CVE on non-internet-facing dev instances where you have assessed it as non-exploitable:

# Create a suppression rule for a specific CVE on dev-tagged instances
aws inspector2 create-filter \
  --name "suppress-cve-2024-1234-dev-nonexploitable" \
  --description "CVE-2024-1234 — assessed non-exploitable on dev; local access only. \
Ticket: SEC-789. Reviewed by: s.harrison@example.com. Review date: 2026-01-15." \
  --action SUPPRESS \
  --filter-criteria '{
    "vulnerabilityId": [{"comparison": "EQUALS", "value": "CVE-2024-1234"}],
    "resourceTags": [{"comparison": "EQUALS", "key": "Environment", "value": "dev"}]
  }' \
  --region eu-west-2

# List all active suppression rules for audit purposes
aws inspector2 list-filters \
  --action SUPPRESS \
  --region eu-west-2

Consider restricting inspector2:CreateFilter in member account SCPs, requiring all suppression rules to be created via your security operations workflow from the Delegated Admin account. This keeps suppression management centralised and auditable, while still allowing self-service for teams where you have established the right governance around it.

Common pitfalls in AWS Inspector vulnerability management

These are the mistakes I see most frequently when reviewing Inspector deployments for enterprise clients.

1. Treating CVSS score as the sole priority signal

The most common and most damaging error. A CVSS 9.8 on an isolated internal service with no network path to the internet is categorically different from a CVSS 7.2 on a publicly accessible API server with a known exploit in Metasploit. Use the Inspector score, EPSS score, and exploitAvailable field to drive priority. Raw CVSS is a starting point, not a final answer.

2. Not accounting for Inspector’s regional architecture

Inspector is a Regional service. You must repeat the setup procedure in every AWS Region where you plan to use it. I have reviewed deployments where the team had enabled Inspector thoroughly in eu-west-2 but had EC2 instances running in us-east-1 for legacy reasons. Those instances were completely dark. Run inspector2 list-coverage across every region you operate in.

3. Missing the SSM Agent prerequisite

Agent-based scanning requires the SSM Agent to be running and the EC2 IAM role to have the AmazonSSMManagedInstanceCore policy attached. Without this, instances silently fall through to agentless scanning or, in some configurations, fall out of coverage entirely. Check your coverage percentage in the Inspector dashboard. Anything below 95% needs investigation.

4. Forgetting Lambda version pinning implications

Inspector only scans $LATEST. If your production invocations use published versions, you must ensure your patching workflow updates and republishes the function, not just patches $LATEST and leaves stale published versions in circulation.

5. Over-suppressing without governance

Build suppression rule creation into your security exception process from day one. Undocumented suppressions are a compliance liability under both NCSC CAF and FCA PS21/3.

6. Not locking Inspector down via SCP

Without the SCP shown earlier in this guide, application teams can disable Inspector for their accounts or create wildcard suppression rules that hollow out your coverage. One inspector2:Disable call from a member account creates a blind spot you may not notice for weeks.

7. Treating ECR basic scanning and enhanced scanning as equivalent

AWS ECR offers two scanning modes: basic scanning (legacy, powered by Clair) and enhanced scanning (powered by Inspector v2). Enhanced scanning provides continuous re-scanning against new CVEs, Lambda function scanning, and organisation-level management. If your ECR repositories are still on basic scanning, you are missing continuous CVE re-evaluation. Migrate to enhanced scanning and set it as the organisation default.

8. Conflating Code Security scanning with runtime scanning

Inspector Code Security (SAST, SCA, IaC) and Inspector runtime scanning (EC2, ECR, Lambda) are complementary, not interchangeable. Code Security catches issues at commit time, before code is deployed. Runtime scanning catches what slipped through, or what became vulnerable after deployment due to a new CVE. You need both. Teams that enable one and consider the job done are carrying a gap.

Regulatory and compliance alignment

NCSC CAF and Cloud Security Principles

The NCSC Cloud Security Principle on secure operation requires that a service be operated and managed securely in order to prevent, detect, or limit attacks. This covers vulnerability management, protective monitoring, incident management, and configuration management.

A well-deployed Inspector implementation directly evidences compliance with several CAF contributing outcomes under Objective B (Protecting Against Cyber Attack), specifically around vulnerability management and patching. The NCSC recommends applying software updates as soon as possible and ideally automatically. Inspector’s integration with Systems Manager Patch Manager supports this directly.

FCA operational resilience and PS21/3

FCA-regulated firms need to demonstrate that they can identify and remediate vulnerabilities within defined timeframes. Inspector’s structured finding exports (CSV, JSON) and its Security Hub integration allow you to produce audit-quality evidence of your vulnerability detection, prioritisation, and remediation timeline. The Inspector risk score directly supports MTTR reduction, which is the metric auditors will ask for.

CIS AWS Foundations Benchmark

The CIS AWS Foundations Benchmark v3 includes controls around ensuring vulnerability scanning is enabled for EC2 and ECR. A fully configured Inspector deployment covering all resource types, with delegated admin set up and findings feeding Security Hub, satisfies these controls directly. If you are running Security Hub with the CIS Benchmark standard enabled, Inspector findings feed automatically into your compliance posture score.

Pricing: what to budget

Vulnerability management is not free, and procurement teams will ask. Current Inspector pricing at time of writing:

• EC2 instance scanning: $1.258 per instance per month for the first 250 instances, decreasing at higher volumes
• ECR container image scanning: $0.09 per image for initial scan, $0.01 for re-scans
• Lambda function scanning: $0.30 per function per month
• Code Security scanning: $0.15 per repository per scan type per scan (SAST, SCA, and IaC counted separately)

For a 300-instance estate with 500 ECR images and 100 Lambda functions, you are looking at roughly $450 to $600 per month in Inspector costs. That is a negligible fraction of the cost of a single undetected Critical exploitation incident.

All accounts new to Inspector are eligible for a 15-day free trial during which all eligible EC2 instances, Lambda functions, and ECR images are scanned at no cost.

Key takeaways

• Deploy via AWS Organizations with a Delegated Admin account, never account-by-account. Use an SCP to prevent member accounts from disabling Inspector or creating unsupervised suppression rules. Configure the Delegated Admin in every region you operate.

• Prioritise by Inspector score, not raw CVSS. The Inspector score accounts for network reachability, EPSS probability, and CISA KEV status. A CVSS 9.8 on an air-gapped internal service is less urgent than a CVSS 7.2 with a public exploit on an internet-facing workload.

• Enable all four scan surfaces: EC2 (hybrid mode), ECR (enhanced scanning), Lambda, and Code Security for GitHub and GitLab repositories. Code Security closes the gap between commit-time vulnerability introduction and runtime detection.

• Wire Inspector into Security Hub, then EventBridge, then Lambda or SSM Runbook. Findings without downstream automation are just an alert backlog. Automated ticket creation, resource tagging, and MTTR tracking are what satisfy FCA and NCSC audit expectations.

• Govern suppression rules as formal security exceptions. Every rule needs a documented justification, an owner, a ticket reference, and a review date. Undocumented suppressions are a compliance liability under both NCSC CAF and FCA PS21/3.

• Export SBOMs regularly and store them in KMS-encrypted S3. Exports are free and provide a defensible audit trail of your software supply chain posture. Automate regular exports via EventBridge Scheduler and query them with Athena for compliance reporting.