Assurer la protection des données de nos clients est la chose la plus importante que fait Cybernetics SAS. Nous mettons tout en œuvre pour que toutes les données envoyées à Cybernetics soient traitées en toute sécurité.

Nous souhaitons partager certains détails de ce que nous faisons pour protéger vos données et une partie du travail que nous effectuons pour améliorer continuellement la sécurité. Ce document est vivant : nous le compléterons de temps à autre.

À propos de votre sécurité

Cybernetics est une plateforme qui centralise l'inventaire de vos actifs numériques, le suivi de leur protection et la remédiation des écarts avec vos prestataires, le suivi de votre conformité, le support et la gestion automatisée des entrées et des sorties de vos utilisateurs et de vos équipements.

Nos employés ne peuvent pas connaître les mots de passe de nos utilisateurs : ils sont hachés avec Argon2id, jamais chiffrés ni stockés en clair. La politique de mot de passe suit les recommandations NIST SP 800-63B (16 à 128 caractères, refus des mots de passe compromis via Have I Been Pwned). La double authentification est obligatoire : application d'authentification (TOTP) avec codes de récupération, ou code par e-mail pour les comptes du rôle Admin Support uniquement. Cybernetics prend en charge les passkeys pour une connexion sans mot de passe, ainsi que le SSO Microsoft et Google.

Les sessions reposent sur des cookies HttpOnly inaccessibles au JavaScript, un verrouillage temporaire après échecs de connexion, une limitation de débit par adresse et par compte, et une alerte « nouvel appareil » avec lien « Ce n'est pas moi » qui révoque immédiatement toutes les sessions, l'appareil et le second facteur. Les cookies sont également en SameSite=Strict.

Chaque entreprise est cloisonnée : l'accès aux ressources est vérifié côté serveur par rapport à l'entreprise de l'utilisateur, et des tests automatisés couvrent une partie de cette frontière. Une revue récente a identifié des cas résiduels, en cours de correction (voir OWASP Secure Coding Practices).

Vos données sont chiffrées en transit et au repos : plus d'informations sur notre chiffrement.

Politique de mot de passe

Cybernetics applique les recommandations du NIST SP 800-63B (section 5.1.1.2) :

longueur minimale de 16 caractères et maximale de 128, tous caractères acceptés (espaces et Unicode compris) ;
aucune règle de composition (majuscule, chiffre, caractère spécial) : ces règles produisent des mots de passe prévisibles sans augmenter leur robustesse ;
vérification systématique des mots de passe auprès de Have I Been Pwned par k-anonymat, pour refuser ceux présents dans une fuite de données connue (seuls les 5 premiers caractères du hash SHA-1 sont transmis, jamais le mot de passe) ;
aucune expiration périodique imposée ; un changement est demandé en cas de compromission suspectée ;
verrouillage temporaire après plusieurs échecs, limitation de débit par adresse et par compte ;
double authentification obligatoire et prise en charge des passkeys.

Cette politique est appliquée à la première connexion, à la réinitialisation et à tout changement de mot de passe.

À propos de nos audits de sécurité

Deux entreprises externes différentes interviennent chaque année pour tenter de percer la sécurité de Cybernetics. À ce jour, aucune faille n'a été décelée dans notre programme ; des anomalies mineures, sans risque majeur ou critique, ont été corrigées.

À propos de notre programme de sécurité

Notre programme de sécurité est accessible aux chercheurs en sécurité informatique : https://app.cybernetics.fr/.well-known/security.txt.

Les règles du programme de récompense des vulnérabilités sont publiées sur : https://app.cybernetics.fr/cybernetics-vulnerability-reward-program-vrp-rules.

À propos de nos moyens déployés en sécurité

Le choix de nos fournisseurs assure une conformité maximale à nos clients :

OVHcloud : Conformité et certifications
Microsoft : Conformité et certifications
Cloudflare : Conformité et certifications
Datadog : Conformité et certifications
GitHub : Conformité et certifications
Mailjet : Conformité et certifications
Intercom : Conformité et certifications

Le choix de nos technologies assure une sécurité maximale à nos clients :

Langages : JavaScript, TypeScript
Orchestrateur : Kubernetes
Stockage : Block Storage
Base de données : PostgreSQL managé OVHcloud
Gestionnaire des secrets : OVHcloud OKMS, distribué par External Secrets Operator
Gestion de la surface d'attaque externe : EASM
Pare-feu d'application : WAF
Stockage d'objets : S3 compatible
Sécurisation du code : SAST
Sécurisation des bibliothèques : SCA
Sécurisation en cours d'exécution : IAST
Sécurité des charges cloud : CSM (CWS)
Gestion des informations et des événements de sécurité : SIEM
Gestion des performances de l'application : APM
Gestion des autorisations et des accès : Microsoft, Google
Sauvegarde des données : Veeam Kasten
Registre d'images : GitHub Container Registry (miroir signé)
Gouvernance et application des politiques Kubernetes : Kyverno
Documentation : Intercom

À propos de nos mesures de sécurité

Infrastructure

Notre infrastructure de production tourne sur un cluster Kubernetes managé OVHcloud MKS de deux nœuds, avec autoscaling jusqu'à trois. Le nœud 1 héberge les workloads applicatifs, Kyverno, l'infrastructure et Datadog. Le nœud 2 est réservé à Kasten K10 et à cloudflared : une policy Kyverno (mutate-kasten-nodeaffinity) impose à ces pods une nodeAffinity sur le label kasten-node=true, sans taint. Les DaemonSets système OVHcloud et l'agent Datadog tournent sur les deux nœuds. Nos frontends (application, site web, page fondateur) disposent d'un HPA. La supervision est assurée par Datadog. Les déploiements sont gérés via Helm avec des valeurs versionnées dans Git, l'infrastructure cloud est décrite en Terraform, et les images applicatives sont publiées par GitHub Actions vers GitHub Container Registry.

Réseau

Le trafic public passe obligatoirement par Cloudflare (WAF, protection DDoS) avant d'atteindre notre point d'entrée unique, qui n'accepte que les connexions provenant de Cloudflare et authentifiées par certificat client (Authenticated Origin Pulls, mTLS) et impose TLS 1.2 minimum avec SNI strict. Les certificats sont émis par Let's Encrypt via cert-manager (challenge DNS-01). L'environnement de staging et les consoles d'administration (Kubernetes, sauvegardes, reverse proxy) ne sont accessibles qu'au travers de Cloudflare Access avec authentification Microsoft Entra ID. Dans le cluster, les NetworkPolicies sont en refus par défaut : chaque namespace n'autorise que les flux nécessaires, et les sorties vers Internet sont limitées à une liste explicite de destinations (API des connecteurs, fournisseurs).

Chaîne d'approvisionnement des images

Aucune image publique n'est utilisée telle quelle. Chaque image tierce est copiée dans notre registre GitHub par un pipeline qui la scanne, la signe (Cosign, signature keyless par OIDC GitHub Actions), vérifie la signature et produit une attestation de provenance SLSA, vérifiable hors cluster. Les manifestes Kubernetes référencent les images par digest SHA-256 et Kyverno vérifie la signature à l'admission, à l'exception d'un composant éditeur référencé par tag, qui reste signé et scanné. Les images applicatives sont construites sur des bases durcies (Docker Hardened Images).

Sauvegardes

Kasten K10 sauvegarde chaque jour les namespaces Kubernetes (production et staging) et chaque heure la base PostgreSQL par pg_dump. Rétention : 24 sauvegardes horaires (base de données), 7 quotidiennes, 4 hebdomadaires, 12 mensuelles, 1 annuelle. Les sauvegardes sont exportées vers un bucket S3 OVHcloud à Strasbourg, versionné et protégé par Object Lock (8 jours d'immuabilité, mode gouvernance, sans droit de contournement pour l'outil de sauvegarde), avec des identifiants fournis par OKMS.

Maintenance des nœuds

Les nœuds appliquent leurs mises à jour de sécurité et redémarrent automatiquement (Kured), avec drainage préalable des pods. Un chart de durcissement des nœuds complète la configuration OVHcloud.

Supervision et détection

Datadog collecte les journaux de tous les conteneurs, les traces applicatives (APM) et les métriques réseau. Les fonctions de sécurité activées en production :

Application Security (détection des attaques, IAST, analyse de composition SCA) ;
Cloud Workload Security (détection des menaces au runtime et contrôle de conformité des hôtes) et génération de SBOM des images et des hôtes.

Contrôle continu

À chaque push et pull request sur les branches principales, Kubescape analyse les templates Helm rendus. Un pack de preuves de conformité est généré chaque semaine par la CI. Le code applicatif est contrôlé par CodeQL, SAST et SCA Datadog, revue de dépendances et Dependabot ; des hooks Gitleaks, versionnés dans chaque dépôt, bloquent les secrets avant chaque commit et chaque push, et Gitleaks est aussi exécuté dans la CI.

Alignement sur l'OWASP Kubernetes Security Cheat Sheet

Sécurité des conteneurs

Recommandation OWASP	Statut	Mécanisme (enforce)
`runAsNonRoot: true`	✅	`require-nonroot-user`
`allowPrivilegeEscalation: false`	✅	`disallow-privilege-escalation`
`readOnlyRootFilesystem: true`	✅	`require-readonly-rootfs`
`capabilities.drop: [ALL]`	✅	`require-drop-all-capabilities`
Capabilities dangereuses bloquées	✅	`audit-dangerous-capabilities`
`privileged: false`	✅	`disallow-privileged-containers`
Pas de `hostPID` / `hostIPC` / `hostNetwork`	✅	`disallow-host-namespaces`
Pas de volumes `hostPath`	✅	`disallow-hostpath-volumes`
Seccomp `RuntimeDefault`	✅	`require-seccomp-profile`
Resource limits (anti-DoS)	✅	`require-resource-limits`
Profil AppArmor	✅	`require-apparmor-profile`
Pas de workload dans le namespace default	✅	`disallow-default-namespace`

Quelques composants système (maintenance des nœuds, composants éditeurs) bénéficient de dérogations documentées, justifiées et revues périodiquement.

Images et chaîne d'approvisionnement

Recommandation OWASP	Statut	Mécanisme (enforce)
Images depuis un registry de confiance	✅	`restrict-image-registry`
Immutabilité des images (digest SHA-256)	✅	`require-image-digest`
Scan des dépendances	✅	Dependabot et Datadog
Secrets scanning (CI/CD)	✅	Gitleaks
Signature des images (Cosign)	✅	verify-image-signatures : signature keyless par GitHub Actions (OIDC), vérification Kyverno en Enforce

Réseau

Recommandation OWASP	Statut	Mécanisme (enforce)
NetworkPolicy deny-all par défaut	✅	`generate-default-deny-netpol`
Vérifier l'existence de NetworkPolicies	✅	`require-network-policy`
Pas de NodePort / LoadBalancer (hors point d'entrée unique, restreint aux adresses Cloudflare)	✅	`disallow-nodeport-loadbalancer`
TLS obligatoire sur les Ingress	✅	`require-ingress-tls`
WAF / exposition contrôlée	✅	Cloudflare Zero Trust Tunnel + WAF
Reverse proxy unique	✅	Traefik
mTLS Cloudflare vers l'origine sur tout Ingress public	✅	`require-cloudflare-origin-pull`

Secrets et identifiants

Recommandation OWASP	Statut	Mécanisme (enforce)
Gestionnaire de secrets externe	✅	ESO, OKMS OVHcloud
Pas de Secrets K8s manuels	✅	`disallow-secret-without-eso`
Pas de secrets dans les ConfigMaps	✅	`detect-configmap-sensitive-data`
`automountServiceAccountToken: false`	✅	`require-automount-false`
Un namespace ne lit que ses propres clés OKMS	✅	`restrict-eso-keys`
Chiffrement au repos (etcd)	❌	OVHcloud MKS avec chiffrement etcd (à planifier)

RBAC et authentification

Recommandation OWASP	Statut	Mécanisme (enforce)
Pas de `cluster-admin` pour les workloads	✅	`disallow-cluster-admin-binding`
Pas de permissions wildcard (`*`)	✅	`disallow-wildcard-roles`
Pas d'accès anonyme	✅	`disallow-anonymous-access`
Moindre privilège (RBAC granulaire)	✅	Policies RBAC et ServiceAccounts dédiés par namespace
Pas de verbe proxy (pods, services, nodes)	✅	`disallow-proxy-verb`
Pas d'exec / attach / port-forward par RBAC	✅	`disallow-interactive-pod-access-rbac`
CI/CD limitée à ses propres ressources	✅	`restrict-ci-cd-web-scope`
Dérogations tracées (propriétaire, date de revue)	✅	`require-policy-exception-review`

Pod Security Admission et namespaces

Recommandation OWASP	Statut	Mécanisme
Labels PSA `restricted` sur les namespaces	✅	`mutate-namespace-labels` (Mutate)
PSS niveau restricted sur les namespaces applicatifs et d'infrastructure	✅	Labels PSA injectés automatiquement
StorageClass restreinte	✅	`restrict-pvc-storageclass`

Observabilité et exécution

Recommandation OWASP	Statut	Mécanisme
Runtime threat detection	✅	Datadog ASM (threats + IAST + SCA) + CWS
Audit logs kube-apiserver	❌	Non activé à ce jour : les journaux d'audit du plan de contrôle sont gérés par OVHcloud MKS et leur transfert n'est pas encore configuré
Container sandboxing	❌	Non implémenté : les nœuds MKS standard utilisent containerd sans runtime d'isolation renforcée

Application

Nos applications sont développées conformément aux OWASP Secure Coding Practices, et évaluées au regard de l'OWASP ASVS 5.0 niveau 2.

Articles liés

Une question ? Nous contacter.