AWS Inspector EU Alternative 2026: Vulnerability Scanning, GDPR Compliance, and CLOUD Act Risk

Post #716 in the sota.io EU Compliance Series

AWS Inspector is presented as a security control: it scans your workloads for vulnerabilities so you can fix them before attackers exploit them. That framing is accurate as far as it goes. What it omits is that Inspector, in performing those scans, generates a detailed record of your infrastructure — every software package, every open network path, every Lambda function's dependency tree — and stores that record in your AWS account under US jurisdiction, where it is subject to CLOUD Act compelled disclosure.

The irony is precise: you deploy Inspector to improve your security posture, and in doing so, you create a centralized intelligence file on your own infrastructure that a US government agency can compel AWS to disclose without informing you or your users.

For organizations operating under GDPR, this creates an obligation that goes beyond vulnerability patching. Inspector findings are data. That data must be processed lawfully, stored appropriately, and protected against unauthorized access — including access by extraterritorial surveillance law.

What AWS Inspector Scans and Stores

AWS Inspector v2 operates across three workload types: Amazon EC2 instances, container images in Amazon ECR, and AWS Lambda functions. For each, it performs two categories of assessment.

Software Vulnerability Assessment

For EC2 instances, Inspector deploys the SSM Agent to collect a complete software inventory: every installed package, its version, and its installation path. It then cross-references this inventory against the NVD (National Vulnerability Database), vendor advisories, and AWS's own threat intelligence feeds to identify CVEs that apply to your specific package versions.

The output is a finding record containing:

{
  "findingArn": "arn:aws:inspector2:eu-central-1:123456789:finding/...",
  "awsAccountId": "123456789",
  "type": "PACKAGE_VULNERABILITY",
  "severity": "CRITICAL",
  "status": "ACTIVE",
  "resources": [
    {
      "type": "AWS_EC2_INSTANCE",
      "id": "i-0a1b2c3d4e5f67890",
      "region": "eu-central-1",
      "details": {
        "awsEc2Instance": {
          "ipV4Addresses": ["10.0.1.45", "52.29.xxx.xxx"],
          "platform": "LINUX_INTEL_X86_64",
          "subnetId": "subnet-0123456789abcdef0"
        }
      }
    }
  ],
  "packageVulnerabilityDetails": {
    "cvss": [{"score": 9.8, "version": "3.1"}],
    "vulnerablePackages": [
      {
        "name": "openssl",
        "version": "1.1.1t-1",
        "filePath": "/usr/lib/x86_64-linux-gnu/libssl.so.1.1",
        "fixedInVersion": "1.1.1w-1"
      }
    ],
    "vulnerabilityId": "CVE-2024-XXXXX",
    "sourceUrl": "https://nvd.nist.gov/vuln/detail/CVE-2024-XXXXX"
  },
  "updatedAt": "2026-04-30T02:00:00.000Z"
}

This record contains your instance ID, private and public IP addresses, subnet topology, and a complete description of vulnerable software on that instance — stored in AWS Inspector's data plane in your selected region, but processed by a US-headquartered company under the CLOUD Act.

Network Reachability Assessment

Beyond software vulnerabilities, Inspector performs network reachability analysis — evaluating your VPC security groups, NACLs, route tables, and internet gateway configurations to determine which of your instances have open network paths to the internet.

Network reachability findings map your entire VPC topology: which ports are exposed, from which directions, through which security group chains. This is, in effect, an automatically generated network map of your infrastructure, stored in AWS Inspector and subject to the same jurisdiction considerations as your other AWS data.

For organizations processing EU personal data, this network map describes the access paths to the systems holding that data. The finding answers the question: "What are the network vectors by which your users' data could be accessed?" That answer, stored in a US-jurisdiction service, is information a sophisticated adversary — governmental or otherwise — would find extremely valuable.

Inspector Findings Are Personal Data Under GDPR

The GDPR classification question for Inspector is more nuanced than for services like CloudFront or Cognito that directly handle user data. Inspector findings primarily describe your infrastructure, not your users. The GDPR analysis requires asking: does this infrastructure data, in context, constitute personal data under Article 4(1)?

The answer is yes, for two independent reasons.

Reason 1: Infrastructure operators as data subjects. Your EC2 instances are managed by employees. An Inspector finding that identifies a specific instance (by ID, IP address, and operating environment) where a specific employee's credentials are stored, or where a specific user's data is processed, links infrastructure state to identifiable individuals. Under the broad GDPR definition — "any information relating to an identified or identifiable natural person" — this linkage is sufficient for classification as personal data.

Reason 2: DPIA implications for systems processing user data. Article 35 GDPR requires a Data Protection Impact Assessment for processing that is "likely to result in a high risk." Inspector findings describe the security posture of systems that process your users' personal data. The findings are therefore directly relevant to your DPIA obligations — they describe the technical and organizational measures (or their absence) protecting personal data. An Inspector finding that your user database instance has an unpatched CVE with network exposure is information about the protection of your users' data. It belongs in your DPIA. And your DPIA, to be meaningful, must be based on accurate, current findings.

The practical implication: you cannot cleanly separate "infrastructure security data" from "personal data processing documentation" when your infrastructure is the processing environment for personal data.

The SBOM Export: Infrastructure Intelligence at Scale

AWS Inspector v2 introduced Software Bill of Materials (SBOM) export — the ability to generate a complete inventory of all software packages across your entire EC2, ECR, and Lambda environment in CycloneDX or SPDX format.

An SBOM export from a production AWS environment contains:

• Every container image in your ECR registry, with every package and version
• Every EC2 instance's complete software stack
• Every Lambda function's dependency tree
• The vulnerability status of every package
• Cross-referenced CVE identifiers for every known vulnerable dependency

This is a complete technical intelligence profile of your application stack. It tells a reader exactly which technologies you use, which versions, which are currently vulnerable, and how your software dependencies interconnect.

Inspector SBOM exports are stored in Amazon S3 by default. You configure the export target, but the generation process — the collection and aggregation of package inventories across your fleet — occurs in AWS's infrastructure, in your account's region, under AWS's data processing agreement with you. That agreement is subject to the CLOUD Act.

The threat model is straightforward: if a US government agency wanted to understand the technical composition of a European organization's software infrastructure — for competitive intelligence, regulatory leverage, or pre-attack reconnaissance — a compelled disclosure of Inspector SBOM exports would answer that question comprehensively.

Lambda Function Scanning: Code Analysis Under US Jurisdiction

Inspector's Lambda scanning capability extends beyond package vulnerabilities. It performs code scanning to identify hardcoded secrets, misconfigurations, and application-layer vulnerabilities in your Lambda function code. Code scanning requires Inspector to have read access to your function packages.

The GDPR and security implications are layered:

Package access: Inspector reads your Lambda deployment packages. In practice, Lambda deployment packages frequently contain environment variable templates, configuration files, database connection strings (sometimes hardcoded despite best practices), and application code that may reveal data structures including personal data schemas.

Code pattern analysis: Inspector's code scanning applies pattern matching to identify vulnerabilities. The pattern-matching engine processes your source code. Your source code may contain SQL queries against tables that store personal data, API call patterns to external services handling personal data, and business logic that reveals how personal data is processed.

Finding persistence: Code analysis findings are stored in Inspector's finding store with the same persistence characteristics as vulnerability findings — retained until you resolve or suppress them, exportable to S3, queryable via the Inspector API.

For GDPR purposes: when your Lambda functions contain application logic that processes personal data, the code analysis of those functions — and the storage of findings about that code — constitutes a form of processing that must be accounted for in your data inventory.

AWS Security Hub Integration: Findings Aggregated Across Accounts

Inspector integrates with AWS Security Hub to centralize findings across multiple accounts and regions. In AWS Organizations deployments, Inspector findings from every member account flow into the delegated administrator account.

This centralization has GDPR implications that compound the individual-account analysis:

Cross-account aggregation: Inspector findings from subsidiary companies, project-specific accounts, or customer-dedicated environments are aggregated under a single organization management account. If that management account is under different legal jurisdiction than the member accounts where data is processed, you have cross-border data flow obligations to document and justify.

Security Hub GDPR status: AWS Security Hub's GDPR implications are documented in the prior analysis in this series. Security Hub acts as a data processor for aggregated security findings under US jurisdiction — the same analysis applies to Inspector findings flowing through Security Hub.

Finding retention: Security Hub retains findings for 90 days by default. Inspector findings persist in the Inspector service indefinitely until resolved or archived. The intersection of these retention schedules means your infrastructure vulnerability history — what was vulnerable, when, for how long — is retained in multiple US-jurisdiction services with different deletion timelines.

EventBridge Integration: Findings as Event Data

Inspector sends findings to Amazon EventBridge as events, enabling automated remediation workflows. The EventBridge integration means Inspector findings are transmitted through EventBridge's event bus infrastructure — another US-jurisdiction service in the AWS data processing chain.

EventBridge events can be routed to Lambda functions, Step Functions, SNS, SQS, or third-party targets (via API destinations). Each routing step is another service in the chain. An Inspector finding that triggers an EventBridge rule that invokes a Lambda function that sends a Slack notification creates a data processing chain across Inspector, EventBridge, Lambda, and an external service — each requiring its own GDPR assessment.

The AWS EventBridge EU Alternative analysis covers the EventBridge data processing considerations. For Inspector specifically: the finding content (instance IDs, CVE details, network exposure data) transmitted as EventBridge payloads must be assessed as a separate data flow in your GDPR documentation.

EU-Sovereign Vulnerability Scanning Alternatives

The vulnerability management function AWS Inspector provides — CVE scanning, SBOM generation, network reachability analysis — can be performed entirely on EU-sovereign infrastructure using open-source and EU-headquartered tooling.

Trivy (EU-Deployable, Open Source)

Trivy (developed by Aqua Security) is a comprehensive vulnerability scanner that runs entirely within your own infrastructure. It supports:

• Container image scanning (equivalent to Inspector's ECR scanning)
• Filesystem scanning (equivalent to Inspector's EC2 package inventory)
• SBOM generation in CycloneDX and SPDX formats
• Kubernetes cluster scanning
• IaC scanning (Terraform, Helm, CloudFormation)

Trivy pulls vulnerability data from public CVE databases — NVD, OSV, GitHub Advisory Database — and performs all analysis locally. No scan data leaves your infrastructure. You can run Trivy on sota.io inside your EU-sovereign deployment environment, with findings stored in your own database.

# Container image scan
trivy image --format cyclonedx --output sbom.json your-app:latest

# Filesystem scan (EC2 equivalent)
trivy fs --format json --output findings.json /

# Kubernetes cluster scan
trivy k8s --report summary cluster

For CI/CD integration, Trivy runs as a container in your pipeline — no separate SaaS dependency, no data leaving your environment, no GDPR data processor agreement with a US-headquartered company required.

Grype (EU-Deployable, Open Source)

Grype (developed by Anchore) provides container and filesystem vulnerability scanning with a focus on accuracy and false positive reduction:

# Scan a container image
grype your-app:latest --output json > findings.json

# Scan SBOM from Syft
syft your-app:latest -o cyclonedx-json | grype

Grype pairs with Syft for SBOM generation. Both tools operate entirely locally — the vulnerability database is downloaded to your infrastructure and updated on your schedule. No scan telemetry, no cloud dependency, no US-jurisdiction data processing.

OpenVAS / Greenbone Community Edition (EU-Origin)

Greenbone Networks GmbH is a German company providing the Greenbone Community Edition — an open-source vulnerability management platform that includes OpenVAS (Open Vulnerability Assessment Scanner). For network reachability and host-level scanning equivalent to Inspector's network assessment:

• GCE runs entirely on your infrastructure (VM or container deployment)
• Vulnerability feed updates from Greenbone's EU-hosted services
• Network topology scanning stays within your environment
• Findings stored in your own PostgreSQL database

Greenbone is EU-headquartered (Osnabrück, Germany), making their commercial offering (Greenbone Enterprise) a genuinely EU-sovereign option for organizations requiring vendor-backed support.

Wazuh (EU-Deployable, Open Source)

Wazuh combines intrusion detection, vulnerability detection, and compliance monitoring in a single platform deployable on your own infrastructure. Its vulnerability detection module performs the same CVE correlation as Inspector against installed packages:

<!-- wazuh.conf vulnerability detection -->
<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>12h</interval>
  <min_full_scan_interval>6h</min_full_scan_interval>
  <run_on_start>yes</run_on_start>
  <provider name="nvd">
    <enabled>yes</enabled>
    <url start="0">https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-</url>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>

Wazuh runs on sota.io with a standard Docker Compose deployment — the agent (installed on each monitored host) reports to your Wazuh manager, findings are stored in your Elasticsearch/OpenSearch instance, and all data stays within your EU infrastructure.

Docker Scout (EU-Deployable for Registry Scanning)

For container registry scanning specifically, Docker Scout supports both cloud-connected and air-gapped scanning. Running Scout in your own registry infrastructure (Harbor on sota.io, for example) keeps container vulnerability assessments entirely within your environment.

KICS (Keeping Infrastructure as Code Secure)

For IaC scanning — Terraform, CloudFormation, Ansible, Kubernetes manifests — KICS (by Checkmarx) runs entirely locally and covers the static analysis component of Inspector's IaC scanning capability.

Migration Architecture: Inspector to EU-Sovereign Stack

Replacing Inspector for a production environment requires mapping each Inspector capability to an EU-sovereign equivalent:

The key architectural shift is from a managed SaaS service (Inspector) to pipeline-embedded scanning with findings centralized in your own EU-hosted management plane (DefectDojo, Wazuh, or Elasticsearch/OpenSearch).

For organizations running on sota.io, this stack deploys as containerized services with persistent storage — Wazuh manager, OpenSearch for finding storage, DefectDojo for vulnerability management workflow — all within the EU infrastructure boundary.

GDPR Documentation Requirements

For organizations currently using Inspector, the transition from AWS Inspector to EU-sovereign vulnerability scanning requires updates to your GDPR documentation:

Article 30 Records of Processing: Remove AWS Inspector as a data processor (or sub-processor in the chain). Add your EU-sovereign scanning tooling and its data flows (scanner to finding store, finding store to ticketing system).

Data Processor Agreement: If you use AWS Inspector, your AWS DPA covers Inspector as part of the AWS service bundle. Replacing Inspector means this DPA coverage is no longer relevant for vulnerability scanning — verify that your remaining AWS services (EC2, ECR, Lambda) DPA coverage is adequate for the workloads you continue to run on AWS.

DPIA: If your DPIA references Inspector as a security control, update it to reference the EU-sovereign equivalent. The security posture improvement argument remains the same — you are still performing vulnerability scanning — but the data flows and jurisdiction change.

Retention policy: Inspector findings persist until resolved or archived. Your EU-sovereign finding store has its own retention configuration — set an explicit retention policy and document it in your records of processing.

The CLOUD Act Risk Profile for Inspector Data

To make the risk concrete: what could a CLOUD Act order targeting your Inspector data reveal?

A comprehensive Inspector CLOUD Act disclosure would provide:

1. Complete software inventory of every EC2 instance you operate — package names, versions, installation paths, and known vulnerabilities at time of disclosure
2. Container image composition of every image in your ECR repositories — full dependency trees including transitive dependencies
3. Lambda function dependencies — the complete dependency graph of your serverless functions
4. Network exposure map — which instances are exposed to the internet, on which ports, through which security group configurations
5. Vulnerability history — findings that have been resolved (and when), findings that were suppressed (and why), the trajectory of your security posture over time
6. SBOM exports — if you have configured SBOM generation, the complete software bill of materials for your entire application portfolio

For a commercial organization, this is a comprehensive competitive intelligence file. For a government-adjacent or critical infrastructure organization, it is a detailed technical profile suitable for planning a targeted attack. For any organization processing EU personal data, it is information about the technical measures protecting that data — information that, under Article 32 GDPR, you are obligated to protect.

EU-sovereign vulnerability scanning eliminates this CLOUD Act surface entirely. The scanning happens within your infrastructure. The findings are stored in your infrastructure. The SBOM is generated and retained within your control. No US government subpoena can compel a service provider to produce data it does not hold.

Conclusion

AWS Inspector solves a real problem — automated vulnerability detection at scale — but it solves it in a way that creates a secondary problem: a centralized, US-jurisdiction record of your infrastructure's security state.

The EU-sovereign alternative is not a degraded fallback. Trivy, Grype, Wazuh, and Greenbone collectively cover Inspector's functionality. The operational difference is pipeline integration (for Trivy/Grype) and infrastructure deployment (for Wazuh/Greenbone) — both of which you control entirely and which can run on sota.io within your existing EU-sovereign infrastructure.

The choice is not between security and compliance. It is between a security posture that creates a US-jurisdiction data liability and one that does not.

For organizations that have already deployed the AWS security stack — CloudTrail, KMS, GuardDuty, Config, Security Hub, WAF, Amplify, and Inspector — this post completes the AWS Security Services EU Alternative series. Each service in the stack has an EU-sovereign equivalent. The migration path exists. The tooling is mature.

The question is whether your current GDPR documentation accurately reflects the data processing that Inspector and its sibling services perform on your behalf — and whether your risk assessment accounts for the CLOUD Act exposure those services create.