Cloud configuration (CSPM)

The cloud configuration module compares the configuration of your resources with a catalogue of rules and raises one finding per non-compliant resource. It reads nothing from the provider itself: it works on the graph filled by the inventory.

How a rule is evaluated

1. The inventory of each cloud records the configuration of the account's resources and writes it into the graph.
2. At the end of the inventory, Ctadel evaluates the enabled rules on the graph.
3. Each rule describes a condition on the graph and reads nothing else. It returns the resources that break the condition; each returned resource becomes a finding, identified by the rule and the resource.
4. Findings are recorded and shown in the "CSPM" page. A finding whose resource no longer comes up at the next inventory is closed.

The evaluation is bounded in time. A rule that did not finish is not read as "no violation": its existing findings are kept as they are. A single resource can also be re-evaluated on its own, for instance after a fix.

Each rule carries a severity (CRITICAL, HIGH, MEDIUM, LOW), a category, one or more clouds, an impact text, an attack scenario and remediation steps; for some rules these texts are generic rather than specific to the service.

Resource families collected per cloud

The table gives what the inventory reads for each cloud. A family missing from this list is not collected, and no rule can apply to it.

Cloud	Families collected
AWS	Account and credential report; IAM (users, groups, roles, policies, service credentials); EC2 (instances, volumes, snapshots, security groups, elastic IPs, auto scaling groups); VPC and peerings; S3; RDS and database clusters; DynamoDB; ElastiCache; EFS; EKS (node groups, access entries); ECS; ECR; Lambda and layers; API Gateway; CloudFront; ELB; Route 53; ACM; KMS; Secrets Manager; CloudTrail; CloudWatch; Config; GuardDuty; Security Hub; WAF; Shield; Backup; Cognito; SNS and SQS; EventBridge; Glue; Athena; EMR; OpenSearch; CodeBuild; Amplify; Lightsail; Bedrock; SageMaker
Azure	Tenant and subscription; Entra (users, service principals, role assignments); virtual machines and disks; storage accounts; Key Vault and Managed HSM; SQL; PostgreSQL flexible server; Cosmos DB; Redis; AKS; container registry; App Service; Functions; Logic Apps; API Management; Application Gateway; Front Door; Azure Firewall; networking (virtual networks, NSGs, interfaces); private endpoints; DNS; Event Hubs; Service Bus; Data Factory; Synapse; HDInsight; Recovery Services; Defender; Monitor and activity log; App Configuration; Cognitive Services, including Azure OpenAI; AI Search
Google Cloud	Organization and project metadata; IAM and IAM policies; Compute Engine; networking, firewall and load balancers; Cloud Armor; Cloud Storage; Cloud SQL; BigQuery; Memorystore; GKE; Cloud Functions; Artifact Registry; Cloud Build; Pub/Sub; Dataproc; Dataflow; Composer; Cloud DNS; KMS; Logging; Monitoring; Security Command Center; Vertex AI Workbench
Scaleway	IAM and policies; instances; Elastic Metal; volumes and snapshots; Object Storage (buckets and ACLs); databases; Kapsule; registry; serverless containers and functions; Key Manager; Secret Manager; load balancers; VPC and gateways; security groups; flexible IPs; domains
OVHcloud	IAM; instances; dedicated servers; volumes and snapshots; buckets; databases; MKS; registry; serverless; KMS and keys; networking; DNS
OUTSCALE	EIM; virtual machines; OMI images; BSU volumes; OOS buckets; LBU load balancers; networking and security groups; OKS; VPN and DirectLink

Rules also apply to the Kubernetes objects present in the graph (workloads, namespaces, service accounts, RBAC, services). Those objects are written by the Kubernetes module; without a connected cluster, these rules return nothing. Some of them read the findings of the Kubernetes module rather than the resource itself.

Categories

Each rule belongs to a category, used by the "Category" filter of the page. The catalogue's categories are: Network, Database, Compute, Storage, Audit, Data, AI, Kubernetes, Web, IAM, Logging, Identity, Monitoring, Encryption, Backup, Container, Messaging, Serverless, Secrets, DNS, Security and KMS.

The CSPM page

The "CSPM" page lists open and closed findings with the columns "Severity", "Status", "Rule", "Category", "Source" and "Resource". Filters apply to "Severity", "Status", "Category", "Source" and "Resource Type"; grouping to "Severity", "Category", "Resource type" or "Rule". The "Export CSV" button exports the filtered list. Clicking a row opens the finding's detail panel, described in Reading a finding.

Drift between code and cloud

When a Git repository is connected, a CSPM rule can be paired with a Terraform rule of the Infrastructure as code module that checks the same setting, with the same polarity, on the same resource. The pairing is fixed by Ctadel, rule by rule; a rule without a pair has no drift status. The "Source" column then takes one of these values:

Value	Meaning
"Cloud only"	No code declares the resource, or the rule has no pair.
"Code & Cloud"	An open IaC finding exists for the paired rule, on the same resource: the defect is in the code and it is deployed.
"DRIFT"	The resource is managed by code (it is linked to an IaC resource through a resolved ctadel:id tag) and no IaC finding matches: the cloud diverged from its code.

A Terraform resource and a cloud resource are matched by name: the Terraform resource name must be the last segment of the cloud identifier, after a / or a :. For instance the resource data_bucket matches arn:aws:s3:::data_bucket. Without a connected Git repository, the column stays at "Cloud only" for every finding.

AI-SPM

The "AI-SPM" page (titled "AI Security Posture") shows the CSPM findings whose rule applies to an AI service. These rules carry the AI category; the "CSPM" page shows every other category. The table and the detail panel are the same.

Service	Objects collected
Amazon Bedrock	Agents, guardrails, custom and imported models, knowledge bases
Amazon SageMaker	Notebook instances, endpoint configurations, models, domains, data quality job definitions, flow definitions
Vertex AI	Workbench instances only
Azure OpenAI	Cognitive Services accounts (including OpenAI), their deployments and their responsible AI policies
Azure AI Search	AI Search services

Disabled rules

Part of the catalogue ships disabled, with the reason written into the rule's description after Disabled:. The "Policies" page shows these rules with their state; enabling one of them produces no finding.

Limits

• The module only sees what the inventory records. A service or a setting the inventory does not read cannot produce a finding even if a rule names it; such a rule ships disabled.
• An evaluation interrupted before its end leaves the remaining rules unevaluated: their findings are neither created nor closed until the next inventory.
• The drift status only exists for rules paired with a Terraform rule. A resource whose Terraform name does not end the cloud identifier is not matched. The "DRIFT" status requires a ctadel:id tag set by the repository and resolved in the graph.
• Rules on Kubernetes objects only apply to clusters connected to the Kubernetes module.
• For Vertex AI, only Workbench instances are collected; Bedrock model import jobs are not modelled.
• The impact and remediation texts of some rules are generic rather than specific to the service.
• Disabled rules appear in the catalogue but produce nothing.