Skip to content
Kloudle Logo
← All guides
Guide

Sovereign CSPM vs SaaS CSPM: Architecture Guide

A technical comparison of sovereign (self-hosted) and SaaS CSPM architectures — data flow, deployment, security properties, and when each model fits.

Akash Mahajan 10 min read

Two Architectures for the Same Problem

Both sovereign and SaaS CSPM solve the same problem: continuously check your cloud infrastructure for misconfigurations and compliance violations. The difference is where the analysis happens and who controls the data.

This guide compares both architectures technically — not commercially. We’ll cover data flow, trust boundaries, failure modes, and operational tradeoffs.

SaaS CSPM Architecture

┌─────────────────────────────────────────────────┐
│  Your Cloud Accounts (AWS, GCP, Azure, etc.)    │
│                                                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ IAM Role │  │ IAM Role │  │ IAM Role │     │
│  │ (read)   │  │ (read)   │  │ (read)   │     │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘     │
└───────┼──────────────┼──────────────┼───────────┘
        │              │              │
        ▼              ▼              ▼
┌─────────────────────────────────────────────────┐
│  Vendor's Infrastructure                        │
│                                                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ Scanner  │  │ Analysis │  │ Database │     │
│  │ Workers  │──│ Engine   │──│ (findings│     │
│  │          │  │          │  │  + config)│    │
│  └──────────┘  └──────────┘  └──────────┘     │
│                                                 │
│  ┌──────────────────────────────────────┐      │
│  │ Dashboard (multi-tenant)             │      │
│  └──────────────────────────────────────┘      │
└─────────────────────────────────────────────────┘

Data Flow

  1. You create a cross-account IAM role granting read-only access to your resources
  2. The vendor’s scanner workers assume that role and enumerate your cloud configuration
  3. Resource configurations are stored in the vendor’s database
  4. Analysis engine evaluates configurations against check library
  5. Findings are stored in the vendor’s database
  6. You access results through the vendor’s multi-tenant dashboard

What Leaves Your Network

  • Complete resource inventory (every EC2 instance, S3 bucket, IAM policy, security group, VPC, subnet)
  • IAM policy documents (who can do what)
  • Security group rules (what’s open to where)
  • Encryption configurations
  • Logging and monitoring settings
  • Network topology

This is effectively a blueprint of your infrastructure’s attack surface.

Sovereign CSPM Architecture

┌─────────────────────────────────────────────────┐
│  Your Infrastructure                            │
│                                                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ Cloud    │  │ Cloud    │  │ Cloud    │     │
│  │ Account 1│  │ Account 2│  │ Account 3│     │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘     │
│       │              │              │           │
│       ▼              ▼              ▼           │
│  ┌──────────────────────────────────────┐      │
│  │ CSPM Engine (your VM)               │      │
│  │ ┌────────┐ ┌────────┐ ┌────────┐   │      │
│  │ │Scanner │ │Analysis│ │  API   │   │      │
│  │ └────────┘ └────────┘ └────────┘   │      │
│  └──────────────────┬───────────────────┘      │
│                     │                           │
│                     ▼                           │
│  ┌──────────────────────────────────────┐      │
│  │ PostgreSQL (your database)           │      │
│  │ - Resource inventory                 │      │
│  │ - Security findings                  │      │
│  │ - Compliance reports                 │      │
│  └──────────────────────────────────────┘      │
│                                                 │
│  ┌──────────────────────────────────────┐      │
│  │ Dashboard (single-tenant, your host) │      │
│  └──────────────────────────────────────┘      │
└─────────────────────────────────────────────────┘

Data Flow

  1. You deploy the CSPM engine on a VM in your environment
  2. The engine uses IAM credentials (same as SaaS) to read your cloud configuration
  3. Scans execute from your VM — API calls originate from your network
  4. Results are written to your PostgreSQL instance
  5. Dashboard is served from your infrastructure
  6. Nothing leaves your network

What Leaves Your Network

Nothing. Zero egress. The CSPM vendor provides the software binary and updates — you provide the runtime.

Technical Comparison

Trust Boundaries

PropertySaaS CSPMSovereign CSPM
Who holds your cloud inventory?VendorYou
Who holds your security findings?VendorYou
Who can read your IAM policies?Vendor employees (with access controls)Your team only
Blast radius of vendor breachYour data exposedSoftware update is the attack vector (smaller surface)
Audit trail ownershipVendor provides, you trustYou own and control

Operational Tradeoffs

PropertySaaS CSPMSovereign CSPM
Setup timeMinutes (connect IAM role)Hours (deploy VM + DB)
MaintenanceVendor handlesYou handle updates
AvailabilityVendor’s SLAYour infrastructure SLA
ScalingAutomaticYou manage capacity
Network requirementsOutbound to vendor APIInternal only
Air-gap compatibleNoYes

Security Properties

SaaS attack surface:

  • Vendor’s multi-tenant database (cross-tenant access bugs)
  • Vendor’s employee access (insider threat)
  • Vendor’s supply chain (compromised dependencies)
  • Network path between your cloud and vendor’s infrastructure
  • Vendor’s authentication system (credential stuffing, session hijacking)

Sovereign attack surface:

  • Your VM’s security (OS patches, SSH access)
  • Your PostgreSQL security (credentials, network access)
  • Software update channel (compromised binary)
  • Your team’s access to the dashboard

The sovereign attack surface is smaller and entirely under your control.

When to Choose SaaS

SaaS CSPM is the right choice when:

  • Speed matters more than control — You need to be scanning within 10 minutes, not tomorrow
  • You lack ops capacity — No one to manage a VM and database
  • Multi-tenancy isn’t a concern — You’re comfortable with the vendor’s isolation guarantees
  • Compliance doesn’t restrict data location — No regulatory requirement to keep infrastructure data in-house
  • Budget is per-team — SaaS often starts cheaper for small deployments

When to Choose Sovereign

Sovereign CSPM is the right choice when:

  • Regulations restrict data location — GDPR, NIS2, DORA, FedRAMP, sector-specific requirements
  • You don’t trust multi-tenant SaaS with infrastructure blueprints — Reasonable position post-SolarWinds
  • Air-gapped or restricted networks — Government, defense, critical infrastructure
  • Audit requires full evidence chain control — ISO 27001, SOC 2 where auditor needs to see your logging, not the vendor’s
  • You have ops capacity — Managing a VM and PostgreSQL instance is within your team’s capability
  • Long-term cost matters — Sovereign with fixed pricing avoids per-resource scaling

Deployment Considerations

Compute Requirements (Sovereign)

A sovereign CSPM engine scanning 5,000 resources across multiple cloud accounts typically needs:

  • 2-4 vCPU
  • 4-8 GB RAM
  • 50 GB disk (for the engine; database needs more for historical data)
  • Network access to cloud provider APIs (outbound HTTPS)

This is a small VM by any standard — $50-100/month in cloud compute costs.

Database Sizing

  • 1,000 resources, 30 days retention: ~5 GB
  • 5,000 resources, 90 days retention: ~25 GB
  • 10,000 resources, 1 year retention: ~100 GB

Standard PostgreSQL. No specialized database required.

Update Strategy

Sovereign doesn’t mean frozen. You still need security updates and new check definitions. The update channel is the primary trust relationship with the vendor.

Options:

  • Pull updates — Engine checks for updates on a schedule, you approve
  • Push updates — Vendor pushes, you verify signatures before applying
  • Air-gap — Manual binary transfer on a schedule (monthly/quarterly)

Hybrid Approaches

Some teams use both:

  1. SaaS for dev/staging — fast setup, less sensitive data
  2. Sovereign for production — full control over production infrastructure data

This gives speed where control matters less and sovereignty where it matters most.

Kloudle’s Approach

Kloudle offers both SaaS and sovereign deployment from the same product. Same check library (1,890 checks), same UI, same API. The deployment model is a configuration choice, not a product fork.

Sovereign deployment: one VM + one PostgreSQL instance. Docker-based install. Updates via signed container images.

Learn More → | See Architecture Details →

Sovereign CSPM

Own Your Cloud Security Posture

Run scans on your infrastructure, store results in your database, generate compliance evidence from your systems.