Modules
What each module reads, where its findings appear, and what is still under internal validation.
A module is a family of checks that reads one part of your environment and produces findings. This section describes, module by module, what is read, how, and what is not.
One inventory, several readings
Ctadel records the configuration of your resources through each cloud's API and writes it into a graph. The modules then work on that graph, on the content of your buckets read in place, or on a temporary copy created in your account (a disk copy, a database copy). They all deliver their findings to the same place.
Access is through APIs, with no agent. Inventory and configuration checks need read permissions. Content analyses additionally need limited write permissions in your account: creating and deleting a snapshot, a volume and an ephemeral scanner instance to read disks (Hosts, Vulnerabilities, Secrets and Data modules), creating and deleting a snapshot and a database copy to read databases (Data module), and on EKS creating a cluster access entry (Kubernetes module). These permissions are separated in the onboarding templates and can be declined, at the cost of the corresponding analyses. The per-cloud detail is in Permissions requested.
The modules
| Module | What it reads | Application page |
|---|---|---|
| Cloud configuration | The resource configuration recorded through each cloud's API, evaluated in the graph | "CSPM" and "AI-SPM" |
| Identities | Identities, service accounts, roles and policies; effective permissions computed per cloud | "Identity" |
| Data | The content of buckets, of a copy of PostgreSQL databases, of disk copies and of serverless function code, by sample | "Data Security" |
| Kubernetes | Workloads, RBAC, network, images and nodes of the clusters | "KSPM" and "Kubernetes" |
| Hosts | A disk copy of each virtual machine, checked offline | "HCR" |
| Vulnerabilities | Packages installed on disks, container images, repository dependencies, matched against published advisories | "Vulnerabilities" |
| Secrets | Git repositories, buckets, disks and serverless function code | "Secrets" |
| Infrastructure as code | Terraform files, Kubernetes manifests and Dockerfiles in connected repositories | "IaC" |
| Attack paths | The whole graph, looking for combinations of findings and relationships | "Toxic Combinations" |
| Inventory and explorer | The graph, browsed resource by resource or visually | "Inventory" and "Explorer" |
| Assistants | The findings and the graph of your instance, read-only | "Ask the Warden" button, present on every page |
Page names are those of the application's left-hand menu. Finding pages are grouped under "Findings", inventory pages under "Inventory".
One list of findings
Whatever its module, a finding appears in the "Findings" page with the same columns: "Severity", "Type", "Finding", "Resource", "Status". The "Type" column identifies the module (CSPM, AI-SPM, Vulnerability, Secret, KSPM, HCR, DSPM, IaC).
The severity scale is shared by every module: CRITICAL, HIGH, MEDIUM, LOW. So are the statuses: "Open", "Investigating", "Resolved", "Fixed", "Ignored", "Accepted". The page Reading a finding explains each column.
Each module page in this section ends with a "Limits" section stating what the module does not read.
Under internal validation
Two items exist in the product but are only visible to accounts of the Ctadel team (addresses ending in @ctadel.eu):
- detection on audit logs (CDR) and its "Runtime" page;
- the "Compliance" page and the CDR type filter of the "Findings" page.
They are under internal validation and are not available to customers. This documentation does not describe them.
Pages in this section
- Cloud configuration (CSPM)
The configuration checks evaluated on the graph, the resource families collected per cloud, drift between code and cloud, the AI-SPM page and disabled rules.
- Identities (CIEM)
The identities collected, the effective permissions computed in the graph for each cloud, unused permissions, cross-cloud correlation and the Identity page.
- Sensitive data (DSPM)
The identifiers searched for in buckets, PostgreSQL databases, disk copies and function code, the formats read, sampling, what Ctadel keeps and the “Data Security” page.
- Kubernetes (KSPM)
What Ctadel reads in your clusters, how it gets access for each distribution, the rule families, and the “Kubernetes Security” and “Kubernetes” pages.
- Hosts (HCR)
The Linux and Windows hardening checks evaluated on a disk copy, the benchmarks followed, what a disk copy lets Ctadel read, what is marked SKIPPED and why, and the “Host Configuration Review” page.
- Vulnerabilities
The packages recorded on disk copies, container images, serverless functions and Git repositories, their matching against NVD, KEV, EPSS and distribution advisories, the risk score and the “Vulnerabilities” page.
- Secrets
Where Ctadel looks for exposed credentials (buckets, disks, functions, repositories, images), how it masks them, how it checks whether they are still valid, and the Secrets page.
- Infrastructure as code
Scanning Terraform files, Kubernetes manifests and Dockerfiles on every push and pull request, the PR comment and status, drift between code and cloud, and linking a cloud resource to its Terraform line.
- Attack paths
The Toxic Combinations page, catalogue chains and computed paths, the score, the detail panel, how to break a chain, and the Sapper's proposals.
- Inventory and explorer
The Inventory page (families, filters, search), the graph explorer (Find, That, Where queries, templates, graph and table views, limit, saving as a policy, query assistant) and the Schema page.
- Assistants
The Warden, the Mason and the Sapper, what they do and do not do, the Constable in internal validation, the models used, and the guards against hijacking.