Data and encryption
What your instance keeps, where, under what protection, for how long, and which outside services it calls.
Your Ctadel instance keeps a description of your cloud accounts and the findings derived from it, not your data. This page says what is stored, where, how credentials are protected, how long each thing is kept, and which calls leave the instance.
What is kept
| Data | Content | Where |
|---|---|---|
| Inventory | The resources of your accounts (identifiers, names, configuration, relationships) as the cloud APIs describe them | The security graph; the list of accounts in the database |
| Findings | Rule, resource, severity, status, dates, project, for each module | The database; mirrored in the graph, attached to the resource |
| Sensitive-data samples | For each data finding: the path or column, the number of matches and a masked sample, two characters visible on each side | The database |
| Detected secrets | The path, the line, the category, a fingerprint and a masked excerpt; the value itself is not stored and never enters the graph | The database and the graph |
| Package list | The installed packages read from each disk and each image, to match them against known vulnerabilities | The database |
| Audit log | Who did which action, when, from which address; never the content of requests | The database |
| Users | Email, name, role, language; the password as a bcrypt hash | The database |
For a secret with a long value, the excerpt keeps at most four characters on each side; a value under sixteen characters is masked entirely. The database and the graph run inside your instance and are shared with no other customer.
The credentials you entrust
Cloud account credentials (API keys, service principal secrets, service account keys, OVHcloud consumer keys) are encrypted with AES-256-GCM before being written to the database, with a 256-bit key specific to the instance, kept outside the database. Each encryption draws a random nonce. The interface cannot read the values back: when editing an account, secret fields left empty keep the stored value.
Protected the same way: the kubeconfigs of declared clusters, the client secrets of single sign-on providers, the configuration of ticketing integrations, GitLab OAuth tokens and Git webhook secrets.
Inside the instance, the scan orders that carry credentials to a scanner are sealed with a second instance-specific key, in AES-256-GCM; only the receiving scanner opens them. An order received without the key is refused rather than treated as empty.
The credentials' encryption key is not in the backups: restoring onto an instance that does not hold the same key leaves the credentials unreadable. See Backups and recovery.
Retention periods
| Data | Duration |
|---|---|
| Closed findings (resolved, fixed, false positives, revoked) | "Retention Period": 90 days by default, adjustable from 7 to 3650 days in "Settings", "Data Retention" card. An open finding is never purged |
| Audit log | 365 days, not adjustable |
| Scan orders in transit inside the instance | 24 hours at most |
| Inventory | Updated at each run; a resource that has disappeared is removed from the graph at the next run |
| Backups | 7 days on the instance, 30 days in object storage |
Outbound calls
The instance makes outbound calls for the uses below. No other third-party service is called.
| Destination | Use | What leaves |
|---|---|---|
| Your clouds' APIs | Inventory, disk and database copies, bucket reading, cluster APIs | Your credentials, the read requests and the creation of ephemeral resources |
NVD (services.nvd.nist.gov), CISA KEV, EPSS (epss.cyentia.com), Debian, Ubuntu and Alpine security trackers | Vulnerability database for package matching | No data from your instance: download of public feeds |
| GitHub and GitLab APIs | Scanning of connected repositories, pull request comments and statuses | The integration's token and the scan results of the repository concerned |
| The secret's issuer (a verification address specific to each rule) | If "Secret Validation" is enabled in "Settings": checking whether a detected secret is still active | The secret itself, in an authenticated request to the service that issued it; it travels encrypted inside the instance and is never stored |
| Language models served in Europe by Scaleway | The assistants | The question, a summary of the posture of the user's scope (finding counts by severity and category, most frequent rules, incident titles, coverage by framework), and the result of the reads the assistant performs during the conversation: resource names, findings, the configuration or code excerpts concerned. Never cloud credentials |
| Email service (Scaleway TEM) | Account emails and end-of-run summary | Recipient address and email content |
| Your own channels (webhooks, messaging tools, ticketing tools, SSO servers) | Notifications, tickets, authentication | What you configured |
| Ctadel operator (operations webhook and emails) | Alert when a component of the instance is down or a backup fails | The host name, the customer identifier, the component concerned; no finding, no inventory data |
The short-lived disk-reading machine, which runs in your account, installs its analysis tools from public repositories, updates its vulnerability database and checks Internet access; it sends nothing anywhere other than to your instance.
Limits
- Webhook addresses of notification channels and their signing secret are stored in the database without application-level encryption; they are protected by access control to the database and the server, not by the credentials' encryption key.
- Encryption of the instance's disks is not performed by Ctadel; this page does not claim it.
- The value of a detected secret travels to the issuing service when validation is enabled; disable "Secret Validation" if you want no call to those services.
- Inventory and findings are not encrypted at the application level, neither in the database nor in the graph: they are readable by anyone with access to the instance's server.
- Retention applies to closed findings only; the label "Findings older than N days are permanently deleted." on the "Data Retention" card does not state this restriction.
- What the language model provider does with the requests it receives is a matter of its terms; this documentation does not claim it. Without configured access to the models, the assistants answer that AI is not configured and nothing leaves.
- There is no data export and no selective erasure per resource from the interface.