First inventory

A full scan refreshes the inventory of all your accounts, evaluates the rules on the graph, then starts the content analyses that read disks, buckets, databases and clusters. This page describes what happens between the registration of an account and the first findings.

What starts when you register an account

As soon as you register a cloud account, the application asks for its synchronization: the account enters the syncing state and the collector of that cloud reads its inventory. Resources appear in the Inventory page and in the graph. This is an inventory only: the rule evaluation and the content analyses wait for the next full scan.

A full scan starts in two ways:

• by hand, under "Settings", tab "General", block "Full scan", button "Scan now";
• automatically: "Automatic Scanning" is on by default and "Scan Frequency" is 24 hours by default. Ctadel starts a full scan as soon as the last one is older than that frequency.

The phases of a full scan

Only one full scan runs at a time, whether started by hand or scheduled. Each run is recorded with its source, its phase, its progress, its warning if any and its dates.

Phase	Label shown	What happens
Inventory	"inventory {done}/{total} accounts"	Every enabled account is synchronized again by its collector. Ctadel waits for them for 10 minutes at most.
Evaluation	"evaluating rules"	The active configuration rules are run on the graph.
Starting the analyses	"dispatching workers"	The content analyses start: volumes, buckets, databases, Kubernetes clusters, serverless functions and containers, as well as the log-based detection phases.
Done	"Scan finished"	The run is closed. Findings from the content analyses keep arriving for a few minutes.

What each analysis produces:

Analysis	Scanner	What comes out
Volumes	Disk copy	Installed packages (then matched against the NVD), secrets, sensitive data, host compliance (HCR) on the copy.
Buckets	Objects	Sensitive data and secrets in the objects.
Databases	Databases	Sensitive data in a temporary copy of the database.
Kubernetes	Kubernetes	Cluster configuration (KSPM) and pod images.
Serverless	Serverless	Secrets and dependencies of functions and containers.
Audit logs, Kubernetes runtime, flow logs	Audit	Event detection: in internal validation, not available to customers.

Your account credentials are handed to the scanners encrypted (AES-256-GCM), inside your instance; they never travel in clear text.

Following the progress

In the application header, a "Scan running" pill shows the phase and, during the inventory, the number of accounts synchronized. The application refreshes that state on its own. At the end, the pill switches to "Scan finished" or "Scan finished with warnings", and a "Full scan completed" message offers "View findings".

The "Full scan" block under "Settings", tab "General", repeats this information and lists, for each account, its resource count, the date of its last synchronization or "never synced", the "disabled" mention when relevant, and its last error. Until a scan has run, it shows "No full scan has run yet."

A warning does not stop the scan. It is kept with the run: for example "inventory timeout after 10min" followed by the number of accounts synchronized, when a collector did not finish in time; the scan then goes on with the current inventory.

Starting a scan on demand

The "Scan now" button asks for a full scan. The answer comes back at once and the scan runs in the background. When a full scan is already running, the application shows "A full scan is already running."; on any other failure, "Could not start the scan."

The completion email and notifications

At the end of each full scan, Ctadel emits an event of type scan, with low severity, titled "Full scan completed" followed by the source, to the notification channels whose rule accepts that type. It details the number of accounts synchronized and the warning if any.

The "Email when a full scan completes" setting, off by default, additionally sends an email to every global administrator, in their language: "[Ctadel] Full scan completed", with the number of accounts synchronized, the warning if any and a button to the findings.

What the disk copy writes in your account

To read a disk, the disk scanner creates ephemeral resources in your account, in this order, then releases them in reverse order, whether the read succeeded, failed or was interrupted:

1. a snapshot of the volume;
2. a scratch volume created from that snapshot;
3. on AWS, a dedicated security group ctadel-scanner-<suffix>;
4. a scanner virtual machine, named ctadel-scanner-ephemeral, with the scratch volume attached.

The volume is detached before the machine stops, then the machine, the volume, the snapshot and the security group are deleted. On the account's next scan, the disk scanner removes whatever an incident left behind for more than two hours; this sweep only happens during a scan, when it holds the account's credentials.

Cloud	Scanner machine
AWS	c5.large
Azure	Standard_D2s_v3
Google Cloud	e2-standard-2
Scaleway	PLAY2-MICRO
OVHcloud	d2-2
OUTSCALE	tinav5, 2 vCPU and 4 GiB by default

The machine receives through its user data a connection key and its own SSH host key, generated by the disk scanner for this scan; it refuses any other host key. By default it gets a public address, and the AWS security group only allows port 22 from the egress range of your Ctadel instance; when that range cannot be determined, the scan fails rather than opening the port. The "Disk scanner network (optional)" section of each account lets you pin a subnet, refuse the public address, or on AWS go through Systems Manager with no inbound rule at all.

Host compliance rules are evaluated on that copy, inside your account: your Ctadel instance never connects to your servers. Checks that need a running system are reported as skipped, with the reason.

The database scanner proceeds the same way: a temporary copy of the database is created, read, then deleted.

Limits

• The inventory wait is capped at 10 minutes; beyond that, the scan goes on with the current inventory and the run carries a warning.
• The run is closed as soon as the content analyses are started: the panel does not follow each content analysis, and a disk or a cluster that takes long to read delivers its findings after "Scan finished".
• Databases are only read on AWS, Google Cloud and Scaleway, for PostgreSQL engines other than Aurora. Azure SQL and OVHcloud databases are not read; only their posture is.
• A cluster connected with a kubeconfig only, with no cloud account behind it, is not picked up by the full scan; see Connect a Kubernetes cluster.
• The disk copy requires write permissions (creating and deleting snapshots, volumes, machines, key pairs and security groups); so does the database copy (snapshot, temporary instance, deletion). Access limited to reading keeps the inventory, the configuration and bucket reading, and gives up disk and database reading.
• The detection phases on audit logs, Kubernetes runtime and flow logs are in internal validation, not available to customers.
• A scanner machine without a public address assumes a private path between your instance and your network, or the Systems Manager transport on AWS.