Entreprise
Le modèle de sécurité entreprise de Ciao
Charges de travail isolées, changements testés en continu et failles de sécurité confirmées sur l'application en production — documentés dans un dossier de sécurité que vos évaluateurs peuvent consulter sous accord de confidentialité (NDA).
Le modèle de sécurité entreprise de Ciao combine une infrastructure isolée par projet avec des tests de sécurité continus : analyse statique, vérification des dépendances, tests des contrôles d'accès et vulnérabilités confirmées sur l'application en production avant d'être signalées. Contrairement aux outils de développement IA qui s'arrêtent à la génération de code, Ciao intègre la sécurité dans la boucle de livraison — avec des rapports SOC 2 Type II disponibles sous NDA et un dossier de sécurité fourni sur demande.
Publié 2026-07-03 · Dernière mise à jour 2026-07-03
Pourquoi le modèle de sécurité compte davantage avec l'IA dans la boucle
Le développement assisté par IA change les questions auxquelles une revue de sécurité doit répondre. Le volume de code augmente, la fréquence des changements augmente, et un nouveau type de fournisseur — l'éditeur du modèle — entre dans votre schéma de flux de données. Une plateforme qui génère des logiciels de production doit clairement démontrer trois choses : où s'exécutent les charges de travail et comment elles sont isolées, comment les changements sont testés avant et après leur mise en ligne, et ce qu'il advient du code et des données qui transitent par le système.
La plupart des outils de cette catégorie répondent par une liste de fonctionnalités. Un RSSI a besoin de preuves : un audit indépendant, un ensemble de documents que l'équipe peut examiner sous NDA, et des contrôles observables en fonctionnement pendant une évaluation. Le modèle de sécurité de Ciao est conçu pour être inspecté, pas seulement décrit.
Cette page résume le modèle — isolation, chiffrement, tests continus et vérifications de sécurité en conditions réelles — et indique précisément comment vérifier chaque élément. Rien ici ne doit être pris pour argent comptant ; chaque affirmation renvoie à un document que vous pouvez demander ou à un contrôle que vous pouvez observer en fonctionnement.
Ce que fournit Ciao
Chaque élément ci-dessous renvoie à un contrôle vérifiable pendant votre évaluation.
- Infrastructure isolée — Les projets s'exécutent sur Kubernetes dans des pods isolés, avec mise en veille/réveil et support multi-région — une infrastructure conçue pour évoluer sans brouiller les frontières entre les charges de travail des clients ou des projets.
- Analyse statique et vérification des dépendances — L'ingénieur Sécurité de Ciao exécute une analyse statique et des vérifications de dépendances dans la boucle de livraison, afin que le code généré comme le code écrit par des humains soit contrôlé avant publication.
- Tests des contrôles d'accès — Les tests de sécurité examinent les règles d'accès sur l'application en fonctionnement plutôt que de simplement lire le code, en testant ce qu'un attaquant pourrait réellement atteindre.
- Résultats confirmés en conditions réelles — Les vulnérabilités sont confirmées sur l'application en production avant d'être signalées, afin que votre équipe examine une exposition réelle plutôt que du bruit d'analyseur.
- Visibilité « prêt à publier » — Un tableau de bord « prêt à publier » indique si un projet est prêt à être livré, alimenté par les analyses, les tests et les résultats confirmés.
- Identité et accès — SSO via SAML et OIDC, MFA optionnelle et contrôle d'accès basé sur les rôles entre espaces de travail et projets.
- Traçabilité — Une piste d'audit en ajout seul enregistre les prompts, les fusions, les déploiements et les actions d'administration.
- Traitement des données par les modèles — Le code client n'est pas utilisé pour entraîner les modèles, et l'inférence s'exécute sous des contrats de rétention zéro.
Comment les tests de sécurité se déroulent en pratique
1. Construire en isolation
Chaque projet se construit et s'exécute dans son propre pod isolé, si bien qu'un changement dans un projet ne peut pas atteindre l'environnement d'exécution d'un autre projet.
2. Analyser
Une analyse statique et des vérifications de dépendances s'exécutent sur le code, détectant les schémas de vulnérabilités connus et les paquets vulnérables avant leur mise en ligne.
3. Tester
Les tests de contrôle d'accès sollicitent l'application en fonctionnement — points d'accès, rôles, accès aux données — comme le ferait un tiers externe.
4. Confirmer
Les résultats sont confirmés sur l'application en production avant d'être signalés, ce qui garde la file d'attente courte et crédible pour les humains qui la trient.
5. Filtrer
Des tests QA de fumée s'exécutent avant publication, et Guardrails applique des politiques en langage clair avec revue humaine enregistrée pour les changements risqués.
6. Surveiller
Après publication, les vérifications de production QA continuent de tourner, et Doctor — un SRE IA en lecture seule — sonde l'application en production, le DNS et le CDN pour diagnostiquer les problèmes tôt.
Isolation et chiffrement
L'isolation des charges de travail est structurelle : Kubernetes avec des pods isolés par projet, et non un environnement d'exécution partagé avec une séparation logique ajoutée après coup. Le chiffrement en transit et au repos est une pratique standard sur la plateforme, et les détails qui comptent pour un évaluateur — protocoles, gestion des clés, périmètre — sont documentés dans le dossier de sécurité plutôt que condensés en une phrase marketing ici. Si votre revue nécessite ces détails, demandez le dossier et lisez la réponse réelle.
Les équipes qui ont besoin d'une frontière plus stricte peuvent déployer sur leur propre compte AWS, Azure ou GCP, ou dans un VPC privé ; l'hébergement sur site est disponible selon des conditions distinctes. Dans ces configurations, l'application et ses données s'exécutent au sein d'une infrastructure que vous contrôlez et surveillez déjà.
Vérification : comment contrôler chaque affirmation de cette page
Les rapports SOC 2 Type II sont disponibles sous NDA — le compte rendu indépendant et audité du fonctionnement de ces contrôles dans le temps. Le dossier de sécurité, disponible sur demande via la page de contact, couvre l'architecture, l'isolation, le chiffrement et le traitement des données avec un niveau de détail adapté aux évaluateurs. Et comme les contrôles de sécurité font partie du produit, vous pouvez les observer fonctionner : demandez une démonstration en direct de l'analyse, des tests de contrôle d'accès et de la vue « prêt à publier » pendant votre évaluation. Les programmes de production sérieux démarrent à 10 000 USD par an ; le périmètre et la configuration sont convenus avec l'équipe entreprise.
Contrôle par contrôle : ce que fournit Ciao et comment le vérifier
| Contrôle | Ce que fournit Ciao | Comment vérifier |
|---|---|---|
| Isolation des charges de travail | Kubernetes avec pods isolés par projet | Détail d'architecture dans le dossier de sécurité |
| Détection des vulnérabilités | Analyse statique, vérification des dépendances, tests des contrôles d'accès | Démonstration en direct du tableau de bord Sécurité |
| Qualité des résultats | Vulnérabilités confirmées sur l'application en production avant signalement | Examen d'un résultat de bout en bout lors d'une démonstration |
| Identité et accès | SSO via SAML et OIDC, MFA optionnelle, RBAC | Démonstration de configuration avec votre fournisseur d'identité |
| Traitement des données par les modèles | Pas d'entraînement sur le code client ; contrats de rétention zéro | Conditions contractuelles lors de l'achat |
| Audit indépendant | SOC 2 Type II | Rapport sous NDA, demandé via /contact |
Questions fréquentes
Effectuez-vous des tests d'intrusion ?
Les détails du programme de tests relèvent du dossier de sécurité, disponible sur demande sous NDA plutôt que résumés dans une plaquette marketing. Indépendamment de tout exercice ponctuel, la plateforme analyse en continu le code et les dépendances, et teste les contrôles d'accès sur l'application en production.
Notre code ou nos données sont-ils utilisés pour entraîner des modèles ?
Non. Le code client n'est pas utilisé pour entraîner des modèles, et l'inférence s'exécute sous des contrats de rétention zéro. Le langage contractuel fait partie des documents que votre équipe juridique examine lors de l'achat.
Pouvons-nous exécuter Ciao au sein de notre propre périmètre de sécurité ?
Oui. Vous pouvez déployer sur votre propre compte AWS, Azure ou GCP, ou dans un VPC privé, et l'hébergement sur site est disponible selon des conditions distinctes. Parlez-en à l'équipe entreprise pour déterminer la configuration adaptée à votre revue.
Comment empêchez-vous les changements générés par l'IA d'introduire des vulnérabilités ?
Chaque changement suit la même boucle : analyse statique, vérification des dépendances et tests de contrôle d'accès, avec des résultats confirmés sur l'application en production avant d'être signalés. Guardrails applique des politiques en langage clair et enregistre la revue humaine, si bien que les changements risqués sont examinés par des personnes et que la piste d'audit indique qui a approuvé quoi.
Quelle est votre dépendance envers un seul éditeur de modèle ?
Ciao exploite une échelle de modèles multi-fournisseurs avec repli, ce qui réduit la dépendance envers un éditeur de modèle unique. Les conditions des éditeurs de modèles, y compris la rétention zéro, font partie de la revue contractuelle lors de l'achat.