Service security

This section describes the instance Ctadel operates for you: what belongs to it, where it runs, who can reach it and what leaves it. What the service does not do is stated in the limits of each page, not left unsaid.

One instance per customer

Each customer receives a complete, isolated instance, deployed on a server reserved for them. The database, the security graph, the encryption keys and the TLS certificate belong to that instance; no application component is shared between two customers.

The instance comprises the web application, the inventory of the six clouds (Scaleway, OVHcloud, OUTSCALE, AWS, Azure, Google Cloud), the rule evaluation, the content scanners (disks, buckets, databases, Kubernetes, serverless functions, vulnerabilities, secret verification, Git repositories), the assistants and a dedicated component for SAML single sign-on. A single entry point is exposed on the Internet, over HTTPS; every other component communicates on a network internal to the server, unreachable from outside.

The instance secrets are generated when it is created, one set per customer: database passwords, the key that encrypts cloud credentials, the key that seals scan orders, internal tokens, the SAML component's secrets and the first administrator's password. They are kept on the server, readable by the server administrator only, and a copy is held by Ctadel in a space reserved for that customer.

Only one component is shared by all customers: the webhook.ctadel.eu webhook relay, operated by Ctadel, which forwards GitHub App events to the right instance. It is involved only if you connect GitHub repositories.

The entry point

Your instance answers on https://<customer>.ctadel.eu, with a Let's Encrypt certificate renewed automatically. The entry point tells three uses apart: GitHub and GitLab webhooks (signature verified before any processing), the exchanges needed for SAML single sign-on (only the endpoints the browser and your identity provider must reach are exposed), and the web application. The browser talks only to the web application; the application's internal calls stay on the server's network.

Every response carries these headers: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and a Permissions-Policy that denies camera, microphone and geolocation. The Server header is removed. Request bodies are capped at 200 MB (SBOM uploads).

Hosting

The instance is hosted on a dedicated physical server at Scaleway, in Paris (France), running Ubuntu LTS. Its domain name <customer>.ctadel.eu is managed in Ctadel's DNS zone, also at Scaleway.

Before anything is deployed, the server is prepared as follows:

• firewall: all inbound traffic is denied except HTTPS, HTTP (required to obtain the certificate) and Ctadel's administration access;
• administration access: by key only, password authentication is disabled;
• operating system security updates applied automatically;
• application directory readable by the server administrator only;
• daily backup at 03:00, described in Backups and recovery.

Technical subcontractors

Provider	Use
Scaleway SAS	Dedicated server in Paris, DNS zone, object storage for backups (Paris region)
Scaleway TEM	Transactional email (invitations, password reset, alerts)
Scaleway Generative APIs	Language models behind the assistants, served in Europe
Let's Encrypt	TLS certificates

Outbound calls to your cloud APIs and to vulnerability databases are described in Data and encryption.

Logs

The instance's components write structured technical logs, kept on the server with rotation: beyond a volume fixed per component, the oldest lines are overwritten. These logs stay on the server; no shipping to an external collector is configured.

The application audit log (who did what in the interface) is separate: it is kept in the instance's database and readable in the application, see Audit log.

Monitoring

Every component of the instance reports its presence at a regular interval. Ctadel aggregates these signals with the state of the databases. A component is considered healthy while its last signal is under 90 seconds old, late up to 5 minutes of silence, down beyond; the three minutes after a restart of the instance are a grace period.

Each transition to down raises an alert to the Ctadel operations team, by email and webhook, with your instance identifier. Recovery is notified the same way. Your administrators do not receive these alerts by default: one instance per customer, a component failure is handled on Ctadel's side. You can still receive them on your own channels by adding the system type to a notification rule, see Notifications.

In the application, the "System status" card ("Settings", "General" tab) shows these states, refreshed every 30 seconds. A badge appears in the header only when the instance is degraded or unavailable.

Updates

Ctadel updates your instance remotely. Only the components whose code changed are rebuilt and restarted; the instance's secrets and keys are not modified by an update. At the end, Ctadel checks that https://<customer>.ctadel.eu answers.

An updated component is unavailable while it restarts. There is no maintenance window mechanism and no zero-downtime deployment. Operating system updates are separate and automatic (see Hosting).

Deleting an instance

At the end of the contract, Ctadel deletes your instance after explicitly confirming the customer name, then, in order:

1. stops the instance and deletes all of its data (database, graph, certificate);
2. deletes the dedicated server, and its disk with it;
3. deletes the <customer>.ctadel.eu DNS record;
4. deletes the customer's backup storage and its content;
5. sets the customer's secrets aside at Ctadel.

If a step fails, the procedure stops, lists what still has to be removed by hand and keeps the information needed to retry.

Limits

• Disk encryption. The server's disk is not encrypted; the instance's data (database, graph) is written on it in clear. Only cloud credentials and scan orders are encrypted at the application level, see Data and encryption.
• Certification. Ctadel holds no certification for the service. Scaleway's attestations cover its data centres and products, not this application.
• A single server. The instance is not redundant. A server failure interrupts the service until a restore from backups on a new server.
• Internal traffic in clear. Between the instance's components, exchanges are not encrypted; they stay on the internal network of a single server.
• Ctadel's access. Ctadel reaches the server with administration rights, by key, and keeps a copy of the instance secrets. No technical mechanism lets you observe these accesses; only the application audit log records actions taken in the interface.
• Keys shared across customers. The access key to the NVD vulnerability database, the language model key, the email service credentials and the access key to the backup storage are the same for every instance. The latter therefore gives access to every customer's backups.
• Logs. Technical logs are neither exported nor kept beyond the rotation described above, and you have no access to them.
• Alerts. Failure alerts go to Ctadel; if no operations recipient is configured on an instance, the failure is only logged.