Réponses point par point de Cybernetics aux OWASP Secure Coding Practices : validation des entrées, encodage des sorties, authentification, sessions, contrôle d'accès, chiffrement, journalisation.

Couverture par thématique

Couverture = (points « Oui » + ½ × points « Partiellement ») ÷ points applicables (hors « Sans objet »). Les points « Non revendiqué » comptent comme « Non ». Calculée au 27/09/2026 à partir des statuts indiqués sur cette page ; elle sera mise à jour à chaque évolution.

​

La sécurisation du code est un aspect crucial du développement de logiciels et chez Cybernetics nous prenons cela très au sérieux. Cybernetics respecte une sécurité dès conception (security by design).

​

Les différentes entrées renseignées par les utilisateurs sont contrôlées par Cybernetics.

Réponse de Cybernetics : Oui. Les données sont validées côté serveur, sur notre API dédiée (api.cybernetics.fr), système de confiance.

Réponse de Cybernetics : Partiellement. Les sources sont classées : saisies des utilisateurs, données de l'agent Cybernetics et réponses des services tiers sont toutes traitées comme non fiables ; la base de données est un stockage maîtrisé dont les valeurs ne sont pas réputées sûres. Les saisies et les données de l'agent sont validées par schéma ; la validation par schéma des réponses des services tiers est en cours.

La base de données n'est pas considérée comme une source de valeurs sûres. Ce qui est maîtrisé, c'est l'intégrité du canal (connexion TLS vérifiée) et l'accès (comptes dédiés) ; une valeur stockée peut en revanche provenir d'un utilisateur, d'un connecteur, d'une ancienne version, d'une migration ou d'une intervention administrative. Elle est donc encodée selon son contexte de sortie (échappement Vue et Edge, paramètres liés en SQL), et doit être contrôlée à nouveau avant toute utilisation dans une URL ou une commande ; ce contrôle n'est pas encore systématique (voir 2.4 et 2.7).

Réponse de Cybernetics : Partiellement. Les saisies des utilisateurs et les données de l'agent sont validées par des schémas avant tout traitement ; quelques champs de l'agent doivent encore être bornés. Les réponses des services tiers sont considérées comme non fiables mais ne sont pas encore validées par schéma : cette validation est planifiée en priorité. En sortie, ces données bénéficient des mêmes protections que les autres (requêtes SQL paramétrées, échappement à l'affichage).

Réponse de Cybernetics : Oui. Chaque route de l'API valide ses entrées avec un schéma déclaré dans un validateur dédié, qui fixe le nom, le type, le format et les limites de chaque champ ; les entrées non déclarées sont ignorées, à l'exception de quelques objets d'attributs de champs personnalisés, stockés tels quels.

Réponse de Cybernetics : Oui. L'API décode tous les corps de requête en UTF-8 (JSON et formulaires). Il s'agit d'un choix de jeu de caractères, qui garantit une interprétation unique des octets reçus ; ce n'est pas en soi une protection contre les injections, assurée par la validation et l'encodage de sortie décrits dans cette page.

Réponse de Cybernetics : Oui. Les requêtes sont décodées en UTF-8 par l'API avant la validation : les règles VineJS s'appliquent donc sur les caractères décodés, et non sur leur représentation encodée.

Réponse de Cybernetics : Oui. Lorsque la validation échoue, une réponse en erreur est systématiquement retournée au client (Erreur 422 : Unprocessable Entity).

Réponse de Cybernetics : Oui. Node.js décode l'UTF-8 avant tout traitement, puis la validation s'applique sur la chaîne décodée. Une séquence d'octets invalide ne peut pas contourner la validation, puisque celle-ci porte sur le texte décodé.

Réponse de Cybernetics : Partiellement. Corps de la requête, paramètres d'URL, query string et données envoyées par l'agent sont validés par des schémas (types, formats, longueurs) ; les réponses des services tiers ne sont pas encore validées par schéma (voir 1.3).

Réponse de Cybernetics : Partiellement. Node.js refuse d'émettre une valeur d'en-tête contenant des caractères de contrôle (retour chariot, saut de ligne, caractère nul), ce qui empêche l'injection d'en-têtes HTTP, et les en-têtes reçus sont analysés en mode strict. Les caractères latin-1 restent techniquement admis : la restriction n'est pas limitée à l'ASCII.

Réponse de Cybernetics : Partiellement. L'API n'effectue aucune redirection HTTP, et les redirections de connexion Google ou Microsoft sont construites côté serveur à partir de la configuration, avec une liste fermée de fournisseurs. Côté interface, les liens reçus par e-mail (réinitialisation, invitation, décommissionnement, alerte de nouvel appareil) sont épinglés sur leur route d'API exacte avant tout appel ; un dernier type de lien signé n'est pas encore épinglé, sans exposition des données de l'utilisateur, et sa correction est planifiée.

Réponse de Cybernetics : Oui. Les validateurs VineJS décrivent ce qui est autorisé plutôt que ce qui est interdit : types attendus, listes fermées de valeurs (enum), formats (e-mail, URL, UUID) et expressions régulières. Toute valeur hors de ce cadre est rejetée.

Réponse de Cybernetics : Partiellement. Les bornes numériques, les dates et les listes de valeurs possibles sont contrôlées dans les schémas de validation sur la plupart des champs ; certaines valeurs numériques n'ont pas encore de maximum, et leur ajout est planifié.

Réponse de Cybernetics : Partiellement. La plupart des champs texte ont une longueur maximale alignée sur les colonnes en base, et la taille totale des requêtes est plafonnée (1 Mo en JSON) ; quelques champs libres ne sont bornés que par cette limite globale, et leur alignement est planifié.

Réponse de Cybernetics : Partiellement. Cybernetics n'accepte pas de HTML dans les saisies : les textes libres sont traités comme du texte brut et échappés à l'affichage. Aucune bibliothèque d'assainissement HTML n'est utilisée, car aucun sous-ensemble de HTML n'est volontairement accepté. Un texte libre de champ personnalisé est encore inséré sans échappement dans un modèle d'e-mail ; sa correction est planifiée.

Réponse de Cybernetics : Oui. Lorsqu'une règle dépend du contexte (appartenance à l'entreprise, état d'une ressource, cohérence entre plusieurs champs), le contrôle complémentaire est fait dans le contrôleur ou dans une politique d'autorisation, après la validation du schéma.

Réponse de Cybernetics : Partiellement. Des normalisations ciblées sont appliquées : suppression des espaces en début et fin (trim) sur les champs texte, mise en minuscules et normalisation des adresses e-mail lors des invitations, normalisation Unicode (NFD, sans accents) pour la recherche et le rapprochement des noms. Il n'existe pas encore de canonisation Unicode systématique de toutes les entrées avant validation.

Cybernetics distingue cinq mécanismes, chacun adapté à un risque :

L'UTF-8 n'est qu'un encodage de caractères : il garantit une interprétation unique des données, mais ne protège pas à lui seul contre les injections (XSS, SQL, URL, commande, en-tête HTTP, journal).

Réponse de Cybernetics : Oui. L'encodage est fait côté serveur pour les réponses de l'API et les e-mails, et par le moteur de rendu Vue dans le navigateur pour l'affichage : aucun encodage ne dépend d'un code ajouté par l'utilisateur.

Réponse de Cybernetics : Oui. Cybernetics s'appuie sur les routines standard de chaque contexte : sérialisation JSON d'AdonisJS pour l'API, échappement automatique de Vue pour l'interface, échappement automatique d'Edge pour les e-mails, requêtes paramétrées de Lucid pour SQL, journaux JSON structurés (pino) pour la journalisation.

Réponse de Cybernetics : Oui. Les réponses JSON et texte de l'API sont envoyées avec « charset=utf-8 » dans l'en-tête Content-Type, et l'interface déclare l'UTF-8.

Réponse de Cybernetics : Partiellement. Dans l'interface, Vue échappe automatiquement toutes les données affichées, et aucun rendu HTML brut (v-html, innerHTML) n'est utilisé. Dans les e-mails, Edge échappe les valeurs par défaut ; un seul modèle insère encore une valeur sans échappement, et sa correction est planifiée. Dans les URL, les paramètres sont en partie encodés (URLSearchParams) ; quelques liens internes sont encore construits par concaténation et seront alignés.

Réponse de Cybernetics : Oui pour les contextes principaux : HTML (échappement Vue et Edge), JSON (sérialisation de l'API), SQL (requêtes paramétrées), journaux (JSON structuré : un retour à la ligne dans une valeur ne peut pas créer une fausse entrée de journal), en-têtes HTTP (caractères de contrôle refusés par Node.js). Les exceptions connues sont décrites en 2.4 et 2.7.

Réponse de Cybernetics : Oui. SQL : Cybernetics utilise des requêtes paramétrées (ORM et query builder Lucid) qui séparent les données de l'instruction SQL ; les valeurs ne sont pas « nettoyées » mais transmises comme paramètres liés. Les rares fragments SQL bruts utilisent aussi des paramètres liés, et les seules valeurs insérées directement sont des constantes internes ou des valeurs issues d'une liste fermée. XML et LDAP : sans objet, l'application n'en émet pas.

Réponse de Cybernetics : Partiellement. Aucune donnée saisie par un utilisateur ou un client n'est transmise à une commande système. Une exception subsiste : le connecteur interne Keeper Security, actif uniquement pour l'entreprise Cybernetics elle-même, appelle un outil externe en ligne de commande avec un identifiant qui n'est pas encore validé strictement ; son remplacement par un appel direct, sans interpréteur, est planifié en priorité. L'agent lance ses outils système avec des arguments séparés ; les valeurs insérées dans ses scripts PowerShell sont échappées, et cet échappement est en cours de renforcement.

La gestion de l'authentification est contrôlée par Cybernetics.

Réponse de Cybernetics : Oui. Toutes les pages et ressources exigent une authentification, hormis les pages du mécanisme d'authentification (connexion, inscription, réinitialisation) et quelques liens signés reçus par e-mail, à durée et à portée limitées.

Réponse de Cybernetics : Oui. Toutes les vérifications d'authentification sont faites côté serveur, sur notre API dédiée (api.cybernetics.fr).

Réponse de Cybernetics : Oui. Plusieurs voies d'authentification standard sont proposées : mot de passe avec double authentification obligatoire, passkeys (WebAuthn), et connexion Google ou Microsoft via OpenID Connect, sur des bibliothèques éprouvées du framework.

Réponse de Cybernetics : Oui. Le système d'authentification classique est défini dans un contrôleur dédié. Le système d'authentification via OAuth est centralisé grâce à l'implémentation fournie par Cybernetics.

Réponse de Cybernetics : Oui. La logique d'authentification est séparée de toute ressource. Si l'accès à une ressource requérant l'authentification est demandé, l'utilisateur est notifié de l'interdiction et redirigé vers la page de connexion.

Réponse de Cybernetics : Oui. L'algorithme pour l'authentification suit le principe de moindre privilège et n'autorise l'utilisateur que s'il répond à toutes les conditions requises.

Réponse de Cybernetics : Partiellement. Les fonctions d'administration et de gestion des comptes sont soumises aux mêmes politiques d'autorisation que le reste de l'application. Elles n'exigent pas encore toutes une réauthentification (voir 3.33).

Réponse de Cybernetics : Oui. Les mots de passe sont hachés grâce à une fonction de dérivation forte et recommandée avant d'être stockés en base de données.

Réponse de Cybernetics : Oui. Le mot de passe est haché côté serveur, sur notre API dédiée (api.cybernetics.fr), avec Argon2id.

Réponse de Cybernetics : Oui. Les données d'authentification sont vérifiées uniquement lorsque toutes les informations sont saisies.

Réponse de Cybernetics : Oui. Lorsque l'authentification échoue, l'exception BadCredentials est levée et un message générique est renvoyé : il ne précise pas la raison de l'échec.

Réponse de Cybernetics : Oui. L'utilisateur doit obligatoirement être connecté avant la transmission d'informations relatives à ses données d'identification à des services externes.

Réponse de Cybernetics : Oui. Pour l'accès aux services externes, les identifiants de connexion sont chiffrés avant d'être stockés dans la base de données dédiée à l'application.

Réponse de Cybernetics : Oui. Les identifiants sont toujours transmis dans le corps de requêtes POST ou PUT, jamais dans l'URL.

Réponse de Cybernetics : Partiellement. Toutes les communications sont chiffrées en TLS, et aucun mot de passe définitif n'est envoyé par e-mail. En revanche, certains parcours (création de compte, invitation, réinitialisation par un administrateur) envoient encore un mot de passe temporaire par e-mail, à changer obligatoirement à la première connexion. Leur remplacement par un lien d'activation à usage unique est planifié, ainsi que la correction d'un e-mail de réinitialisation qui ne contient pas le bon élément.

Réponse de Cybernetics : Oui. Le mot de passe doit contenir au moins 16 caractères (128 au maximum). Il est refusé s'il figure dans une base de mots de passe compromis (vérification en ligne par k-anonymat ; un repli local est planifié), conformément aux recommandations du NIST et de l'ANSSI qui privilégient la longueur à la complexité imposée.

Réponse de Cybernetics : Oui. Le mot de passe doit être composé d'au moins 16 caractères.

Réponse de Cybernetics : Oui. La saisie du mot de passe est masquée sur l'interface.

Réponse de Cybernetics : Oui. Le compte est verrouillé pendant 5 minutes après 5 tentatives infructueuses en 5 minutes, ainsi qu'après 10 échecs sur 24 heures.

Réponse de Cybernetics : Partiellement. Le changement de mot de passe et d'adresse e-mail exige une réauthentification récente, obtenue aujourd'hui avec un seul facteur. Tous les chemins de modification ou de création de mot de passe n'appliquent pas encore ce même niveau de contrôle, et le changement d'e-mail ne demande pas encore de confirmation de la nouvelle adresse ; leur alignement est en cours.

Réponse de Cybernetics : Sans objet. Nous n'utilisons pas de tel système pour la réinitialisation du mot de passe.

Réponse de Cybernetics : Oui. Nous utilisons des réinitialisations de mot de passe par e-mail. L'e-mail contient un lien avec un jeton de réinitialisation à usage unique, à forte entropie ; seule son empreinte est conservée côté serveur.

Réponse de Cybernetics : Partiellement. Le lien de réinitialisation de mot de passe est valable 10 minutes et un seul jeton est actif à la fois. Les mots de passe temporaires envoyés à la création de compte n'ont pas encore de durée de validité propre ; ils seront remplacés par des liens d'activation à durée courte.

Réponse de Cybernetics : Oui. L'utilisateur doit changer son mot de passe temporaire à la première connexion : tant que ce n'est pas fait, l'accès aux ressources lui est refusé.

Réponse de Cybernetics : Oui. Un e-mail est envoyé à l'utilisateur dès qu'il y a une modification de son mot de passe.

Réponse de Cybernetics : Oui. Une restriction lors de la phase du changement de mot de passe permet de s'assurer que l'utilisateur ne peut pas définir le mot de passe utilisé actuellement comme nouveau mot de passe.

Réponse de Cybernetics : Non. Cybernetics n'impose pas de durée minimale avant un nouveau changement de mot de passe. La réutilisation du mot de passe actuel est interdite et les mots de passe compromis sont refusés.

Réponse de Cybernetics : Partiellement. Cybernetics impose le changement du mot de passe initial à la première connexion. La réinitialisation passe par un jeton à usage unique, valable 10 minutes, dont seule l'empreinte SHA-256 est stockée, et les demandes sont limitées en fréquence par e-mail et par adresse IP. En revanche, Cybernetics n'impose pas encore de délai minimum entre deux changements de mot de passe, et ce délai n'est pas réglable par un administrateur.

Réponse de Cybernetics : Oui. Cybernetics ne propose pas de connexion persistante (« se souvenir de moi »). Les garanties côté serveur sont : expiration de la session après 15 minutes d'inactivité, expiration absolue 8 heures après la connexion, et révocation immédiate à la déconnexion. Les comptes d'assistance (Admin Support) ont une session de durée fixe, 24 heures au plus. Le cookie de session n'a pas de durée de conservation propre, mais certains navigateurs peuvent le restaurer après redémarrage : la sécurité repose sur les expirations côté serveur.

Réponse de Cybernetics : Partiellement. L'historique des connexions (réussies ou non, avec horodatage, adresse IP, statut et type) est consultable dans le profil, et un e-mail signale tout nouvel appareil ; la dernière utilisation n'est pas encore affichée au moment de la connexion.

Réponse de Cybernetics : Partiellement. Chaque compte est verrouillé après des échecs répétés, avec une alerte par e-mail, et le nombre de tentatives par adresse IP est limité sur l'ensemble des comptes ; il n'existe pas encore de détection dédiée d'un même mot de passe tenté sur plusieurs comptes.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas concerné puisqu'il gère les mots de passe de bout en bout.

Réponse de Cybernetics : Partiellement. Une réauthentification récente est exigée pour les opérations critiques du compte : changement de mot de passe ou d'e-mail, suppression du compte, ajout ou révocation de passkey, codes de récupération, génération de clés d'API, modification ou suppression de secrets de connecteurs. Elle ne couvre pas encore toutes les actions d'administration (invitations, réinitialisations faites par un administrateur, changements de rôle ou de méthode de double authentification, création de secrets), et elle accepte aujourd'hui un seul facteur. Son extension et l'exigence du second facteur sont planifiées.

Réponse de Cybernetics : Partiellement. La double authentification est obligatoire pour tous les comptes, à l'exception des comptes d'assistance (Admin Support) pour lesquels un administrateur peut la désactiver ; la suppression de cette exception est planifiée.

Réponse de Cybernetics : Oui. La connexion Google et Microsoft passe par le module d'authentification d'AdonisJS (Ally), épinglé par fichier de verrouillage et surveillé comme les autres dépendances (Dependabot, analyse SCA Datadog, CodeQL). Cybernetics le complète par un pilote durci : paramètre state conservé dans un cookie chiffré, PKCE, cookies de flux HttpOnly et Secure valables 10 minutes, et URL de retour fixées par la configuration du serveur. Pour Microsoft Entra ID, le jeton d'identité est vérifié (signature via les clés publiées par Microsoft, audience, émetteur et nonce). Pour Google, le profil est obtenu auprès de l'API Google avec le jeton d'accès.

La gestion des sessions est contrôlée par Cybernetics.

Réponse de Cybernetics : Oui. Nous utilisons le système de session mis en place par le framework. Il établit le contrôle via l'identifiant de la session.

Réponse de Cybernetics : Oui. La vérification est faite côté serveur, sur notre API dédiée (api.cybernetics.fr).

Réponse de Cybernetics : Oui. Le jeton de session est généré par AdonisJS avec le générateur aléatoire cryptographique de Node.js (crypto.randomBytes) : 40 caractères aléatoires, soit environ 240 bits d'entropie, suivis d'une somme de contrôle. Seule son empreinte SHA-256 est stockée côté serveur, et chaque jeton est unique et révocable.

Réponse de Cybernetics : Partiellement. Le cookie de session lu par l'API est HttpOnly, Secure et SameSite=Strict, avec le chemin / et sans attribut Domain : il est limité à l'hôte de l'API. Il ne porte pas encore le préfixe __Host- ni de durée de vie propre (sa validité est bornée côté serveur). L'application pose aussi une copie au préfixe __Host- ; l'alignement entre les deux cookies est en cours.

Réponse de Cybernetics : Oui. La session se termine complètement suite à la procédure dédiée à la déconnexion.

Réponse de Cybernetics : Oui. Les pages protégées par autorisation ont toutes la fonctionnalité de déconnexion.

Réponse de Cybernetics : Partiellement. La session expire après 15 minutes d'inactivité ; les comptes d'assistance (Admin Support) ont une session de durée fixe de 24 heures, sans délai d'inactivité, en cours d'alignement.

Réponse de Cybernetics : Partiellement. Toute session est fermée au plus tard 8 heures après la connexion, même si elle est active, et une nouvelle authentification est alors exigée ; les comptes d'assistance ont une session fixe de 24 heures, en cours d'alignement.

Réponse de Cybernetics : Oui. En cas de session établie, Cybernetics propose de fermer la session et en propose une nouvelle à l'utilisateur connecté.

Réponse de Cybernetics : Partiellement. Un nouveau jeton de session est créé à chaque connexion, y compris après une reprise de session. La réauthentification demandée pour les opérations sensibles délivre un ticket distinct, sans renouveler le jeton de session.

Réponse de Cybernetics : Oui. Cybernetics n'autorise pas les connexions simultanées avec le même ID utilisateur.

Réponse de Cybernetics : Oui. Le jeton de session est opaque et n'apparaît ni dans les URL ni dans les messages d'erreur ; il est masqué dans les journaux, et seule son empreinte est conservée côté serveur. Il est transmis dans un cookie HttpOnly ; il transite également une fois dans la réponse de connexion, avant d'être placé en cookie.

Réponse de Cybernetics : Oui. Cybernetics assure le contrôle d'accès avec la conteneurisation et protège les sessions côté serveur contre tout accès non autorisé d'autres utilisateurs du serveur.

Réponse de Cybernetics : Partiellement. Chaque jeton de session expire côté serveur après 15 minutes d'inactivité et au plus tard 8 heures après la connexion (24 heures fixes pour les comptes d'assistance) ; un nouveau jeton est alors exigé. Les jetons expirés ne sont pas encore purgés automatiquement de la base.

Réponse de Cybernetics : Oui. Cybernetics transmet directement l'identifiant de session en HTTPS, sans bascule HTTP.

Réponse de Cybernetics : Oui. Cybernetics utilise systématiquement le protocole HTTPS.

Réponse de Cybernetics : Partiellement. Les opérations sensibles sur les comptes s'appuient sur des jetons aléatoires à usage unique (réauthentification, réinitialisation, invitation) en plus de la session. Les actions d'administration sur les comptes d'autres utilisateurs (réinitialisations, changements de rôle) sont contrôlées par autorisation, limitation de débit et notification, mais n'exigent pas encore de réauthentification.

Réponse de Cybernetics : Partiellement. Un ticket de réauthentification par requête est exigé pour les opérations les plus sensibles : il est opaque, stocké sous forme d'empreinte, lié à l'utilisateur, à usage unique et valable 60 secondes. Il n'est pas encore lié à une action précise, n'est pas exigé sur toutes les opérations critiques, et peut aujourd'hui être obtenu avec un seul facteur. Ces trois points sont en cours de correction.

Réponse de Cybernetics : Oui. Les cookies d'authentification sont émis avec l'attribut Secure en production.

Réponse de Cybernetics : Oui. Les cookies d'authentification sont HttpOnly. Seules des préférences d'affichage sans effet sur la sécurité sont lisibles par les scripts.

Réponse de Cybernetics : Oui. Les jetons de session sont stockés côté serveur sous forme d'empreinte. Leur accès est contrôlé et des règles d'autorisation vérifient les droits sur chaque ressource.

Réponse de Cybernetics : Oui. Cybernetics valide les autorisations d'accès côté serveur. L'identification de l'utilisateur repose sur un jeton de session opaque transmis dans un cookie HttpOnly, Secure et SameSite=Strict.

Réponse de Cybernetics : Oui. Cybernetics utilise le paquet fourni par son framework pour le contrôle d'accès, qui vérifie également l'authentification.

Réponse de Cybernetics : Oui. Lorsque l'accès n'est pas permis, une exception est levée. Le retour client est de type 403, Forbidden.

Réponse de Cybernetics : Oui. Cybernetics valide toutes ses variables de configuration au démarrage de l'API AdonisJS avec un schéma typé : si une variable obligatoire (clés de chiffrement, base de données, fournisseurs d'authentification…) est absente ou invalide, l'application refuse de démarrer.

Réponse de Cybernetics : Partiellement. Les contrôles d'autorisation sont centralisés dans des politiques côté serveur, appliquées aux requêtes de l'API, et couvrent la majorité des ressources ; des tests automatisés vérifient la frontière entre entreprises sur une partie des routes. Une revue de sécurité récente a toutefois identifié des cas résiduels d'autorisation entre entreprises et de contrôle des références d'objet (objets liés transmis dans une requête, éléments partagés, flux de sortie d'actifs, changement d'abonnement). Leur correction et leur couverture par des tests négatifs sont en cours.

Réponse de Cybernetics : Oui. Cybernetics applique une logique d'autorisation isolée dans un répertoire dédié (politiques). Les opérations critiques requièrent en plus notre middleware pour une couche supplémentaire de vérification.

Réponse de Cybernetics : Partiellement. Aucun fichier d'utilisateur n'est stocké ; les seuls fichiers distribués (installateurs de l'agent) sont servis par des liens signés temporaires, et la restriction de ces liens aux seuls fichiers attendus est en cours.

Réponse de Cybernetics : Oui. L'application Cybernetics bénéficie d'URL protégées.

Réponse de Cybernetics : Partiellement. L'accès aux fonctions protégées est vérifié côté serveur par des politiques d'autorisation ; les cas résiduels décrits en 5.5 sont en cours de correction.

Réponse de Cybernetics : Partiellement. Les contrôles d'autorisation sont centralisés dans des politiques côté serveur, appliquées aux requêtes de l'API, et couvrent la majorité des ressources ; des tests automatisés vérifient la frontière entre entreprises sur une partie des routes. Une revue de sécurité récente a toutefois identifié des cas résiduels d'autorisation entre entreprises et de contrôle des références d'objet (objets liés transmis dans une requête, éléments partagés, flux de sortie d'actifs, changement d'abonnement). Leur correction et leur couverture par des tests négatifs sont en cours.

Réponse de Cybernetics : Partiellement. L'accès aux services est réservé aux utilisateurs autorisés par des politiques côté serveur ; les cas résiduels décrits en 5.5 sont en cours de correction.

Réponse de Cybernetics : Partiellement. Les contrôles d'autorisation sont centralisés dans des politiques côté serveur, appliquées aux requêtes de l'API, et couvrent la majorité des ressources ; des tests automatisés vérifient la frontière entre entreprises sur une partie des routes. Une revue de sécurité récente a toutefois identifié des cas résiduels d'autorisation entre entreprises et de contrôle des références d'objet (objets liés transmis dans une requête, éléments partagés, flux de sortie d'actifs, changement d'abonnement). Leur correction et leur couverture par des tests négatifs sont en cours.

Réponse de Cybernetics : Partiellement. L'accès aux attributs des utilisateurs, aux données et aux informations de politique est restreint par les politiques côté serveur ; les cas résiduels décrits en 5.5 sont en cours de correction.

Réponse de Cybernetics : Oui. L'application Cybernetics restreint l'accès aux informations de configuration relatives à la sécurité aux seuls utilisateurs autorisés.

Réponse de Cybernetics : Partiellement. Les permissions sont chargées depuis le serveur et propagées à l'interface, qui masque les actions non autorisées ; le serveur reste la seule source de décision. Les écarts d'autorisation résiduels décrits en 5.5 sont en cours de correction, et une incohérence de définition du rôle Éditeur (droits de modification non appliqués) est en cours d'analyse.

Réponse de Cybernetics : Oui. Le serveur ne fait confiance à aucun état stocké côté client. Côté navigateur ne sont conservés que : le jeton de session opaque (cookie HttpOnly), les étapes de double authentification et du flux OAuth (cookies chiffrés et signés par le serveur, HttpOnly, à durée limitée), et des préférences d'affichage sans effet sur la sécurité (masquage des identités, vue choisie, mode d'édition), dans des cookies ou le stockage local. Les droits sont chargés depuis le serveur et revérifiés à chaque requête : modifier une préférence ou un cookie ne donne accès à rien.

Réponse de Cybernetics : Oui. Cybernetics, avec son middleware, applique systématiquement toutes les règles métier avant tout accès à une ressource : validité du plan (dates de début et de fin), changement de mot de passe initial obligatoire, acceptation des CGU et de la politique de confidentialité, vérification RGPD, confirmation du compte. Tout manquement bloque l'accès avec une exception spécifique.

Réponse de Cybernetics : Oui. Cybernetics applique une limitation de débit complète avec des profils granulaires adaptés à chaque type d'opération : lecture, mise à jour, suppression, authentification, réinitialisation de mot de passe… Les limites s'appliquent par adresse IP ou par adresse e-mail selon l'opération.

Réponse de Cybernetics : Oui. Cybernetics n'utilise pas l'en-tête « referer » comme mécanisme d'autorisation. Le contrôle d'accès repose exclusivement sur les jetons d'authentification opaques et les politiques côté serveur. La configuration CORS restreint les origines autorisées via une liste d'autorisation explicite.

Réponse de Cybernetics : Partiellement. Les permissions sont rechargées depuis le serveur à chaque requête, et la durée de session est bornée (15 minutes d'inactivité, 8 heures au maximum, 24 heures fixes pour les comptes d'assistance). Les écarts d'autorisation décrits en 5.5 restent à corriger.

Réponse de Cybernetics : Non. Il n'existe pas encore de désactivation automatique des comptes inactifs ni de revue périodique outillée des comptes : un compte reste actif tant qu'il n'est pas supprimé ou détaché de son entreprise. Seules les données inactives depuis 3 ans sont purgées automatiquement.

Réponse de Cybernetics : Partiellement. Lorsqu'un compte perd son rattachement à l'entreprise ou n'est plus confirmé, ses jetons de session sont révoqués à sa requête suivante ; un défaut de révocation au retrait d'un membre d'assistance est en cours de correction.

Réponse de Cybernetics : Partiellement. Les comptes de service Kubernetes ont des droits RBAC dédiés par namespace, sans jeton monté par défaut, et chaque base de données a son propre compte. Le compte applicatif de la base sert encore aux migrations de schéma, et un même certificat d'accès au KMS est utilisé pour toutes les entreprises ; leur séparation est planifiée.

Réponse de Cybernetics : Partiellement. Les règles d'accès sont définies dans le code (rôles, permissions par plan, politiques d'autorisation) et versionnées. Il n'existe pas encore de document de politique de contrôle d'accès distinct, relu et approuvé, et les écarts décrits en 5.5 montrent que la couverture doit être complétée.

Réponse de Cybernetics : Partiellement. Les permissions sont chargées depuis le serveur et propagées à l'interface, qui masque les actions non autorisées ; le serveur reste la seule source de décision. Les écarts résiduels décrits en 5.5 sont en cours de correction.

La gestion des pratiques cryptographiques est contrôlée par Cybernetics.

Réponse de Cybernetics : Oui. Toutes les opérations cryptographiques sont effectuées côté serveur, sur notre API dédiée (api.cybernetics.fr).

Réponse de Cybernetics : Partiellement. Les secrets de la plateforme sont stockés dans OVHcloud OKMS et injectés par External Secrets Operator ; une politique Kyverno bloque les secrets Kubernetes créés hors de ce mécanisme, et les accès sont restreints par RBAC. Certaines clés applicatives sont encore partagées entre plusieurs usages, et des secrets de construction et de distribution doivent être retirés des pipelines et des binaires ; leur rotation et leur séparation sont en cours.

Réponse de Cybernetics : Partiellement. En cas d'indisponibilité du KMS, un chiffrement de secours géré par la plateforme est appliqué et tracé, puis remplacé par le chiffrement KMS lors des écritures suivantes ou d'un rechiffrement : ce mode de secours ne bénéficie pas de l'isolation par entreprise. Les échecs de déchiffrement sont journalisés. La procédure de désactivation d'une clé est en cours de fiabilisation.

Réponse de Cybernetics : Oui. Les GUID/UUID sont bien aléatoires et gérés par notre technologie backend.

Réponse de Cybernetics : Non revendiqué. Cybernetics n'active pas le mode FIPS de Node.js et ne revendique pas de conformité FIPS 140-2 ou 140-3. Les algorithmes utilisés (AES-256-GCM, HKDF-SHA256, SHA-256, et AES-256-CBC avec HMAC-SHA256 pour certaines données hors KMS) figurent parmi ceux recommandés par le NIST, mais cela ne vaut pas validation FIPS d'un module cryptographique. Argon2id, utilisé pour les mots de passe, n'est pas un algorithme approuvé FIPS.

Réponse de Cybernetics : Partiellement. Chaque entreprise dispose de sa propre clé de service dans OVHcloud KMS, créée à son inscription. Cette clé génère des clés de données (chiffrement par enveloppe) : chaque valeur chiffrée est stockée avec sa clé de données chiffrée par le KMS, et la version en clair de cette clé n'est gardée en mémoire que pour une durée limitée (cache d'une minute). Chaque valeur est chiffrée en AES-256-GCM avec une sous-clé dérivée par HKDF-SHA256 à partir de la clé de données, d'un sel aléatoire et du contexte (entreprise, table, colonne). La compromission d'une clé de service isolée n'expose donc que les données de cette entreprise chiffrées par le KMS. D'autres données (secrets de connecteurs, certains champs d'entreprise et d'utilisateur, chiffrement de secours) sont protégées par des clés applicatives gérées par la plateforme et communes à toutes les entreprises ; un même certificat d'accès au KMS sert à toutes les entreprises. La liaison du chiffré à l'enregistrement hôte, la séparation des clés par usage et la vérification TLS du KMS sont en cours de renforcement. Les mots de passe sont hachés avec Argon2id.

La gestion des erreurs et sa journalisation sont contrôlées par Cybernetics.

Réponse de Cybernetics : Partiellement. Les erreurs attendues (authentification, autorisation, validation) renvoient des messages génériques ou des erreurs de champ, sans détail système. Certaines erreurs internes inattendues peuvent encore renvoyer leur message technique au client ; le passage systématique à un message générique, avec des tests dédiés, est en cours.

Réponse de Cybernetics : Partiellement. En production, aucune trace de pile n'est renvoyée au client. Certaines erreurs internes peuvent encore exposer leur message technique (voir 7.1) ; leur correction est en cours.

Réponse de Cybernetics : Partiellement. L'API renvoie des erreurs JSON génériques pour les erreurs attendues, et l'interface affiche une page d'erreur générique. Certaines erreurs internes peuvent encore renvoyer leur message technique (voir 7.1).

Réponse de Cybernetics : Oui. L'application Cybernetics gère les erreurs et ne relaie pas la gestion de la configuration du serveur.

Réponse de Cybernetics : Oui. Cybernetics utilise des runtimes qui libèrent automatiquement la mémoire allouée à la fin de chaque requête, y compris en cas d'erreur.

Réponse de Cybernetics : Partiellement. Les politiques d'autorisation et les middlewares refusent l'accès par défaut (401 et 403). Les erreurs internes inattendues renvoient une erreur 500, mais pas toujours avec un message générique (voir 7.1).

Réponse de Cybernetics : Oui. Cybernetics écrit ses journaux applicatifs côté serveur uniquement. Le journal d'audit est stocké dans une base PostgreSQL dédiée, séparée de la base principale, avec ses propres identifiants et une connexion TLS vérifiée ; les journaux techniques sont centralisés dans Datadog.

Réponse de Cybernetics : Oui. Cybernetics enregistre explicitement les événements de succès et d'échec pour chaque tentative d'authentification. Nous récoltons également via Datadog des journaux complémentaires liés aux événements de sécurité spécifiés.

Réponse de Cybernetics : Partiellement. Les journaux applicatifs contiennent l'horodatage, le niveau et des identifiants de trace, et le journal d'audit enregistre la ressource, l'action et les valeurs modifiées ; il n'enregistre pas encore l'auteur, la requête ni la source de chaque modification, et leur ajout est planifié.

Réponse de Cybernetics : Oui. Les journaux sont structurés en JSON et stockés en PostgreSQL. Aucune interpolation de chaîne non échappée n'est effectuée. Datadog affiche les journaux en texte brut, sans interpréter leur contenu.

Réponse de Cybernetics : Oui. Cybernetics restreint l'accès aux journaux (infrastructure, applicatifs) via RBAC et par des politiques.

Réponse de Cybernetics : Oui. Cybernetics applique une routine centrale pour toutes les opérations de journalisation, visible par l'utilisateur dans l'interface du produit.

Réponse de Cybernetics : Partiellement. Les mots de passe, jetons, cookies, en-têtes d'authentification, secrets et adresses e-mail sont masqués automatiquement dans les journaux du serveur, selon le nom des champs. Sur les postes, un journal local de l'agent peut contenir un secret après une requête en échec ; sa correction est planifiée. Une valeur incluse dans un message d'erreur n'est pas masquée. Les copies d'e-mails conservées pour une nouvelle tentative d'envoi sont chiffrées et supprimées après l'envoi, mais deux types d'e-mails contenant un mot de passe temporaire ne sont pas encore exclus de cette conservation.

Réponse de Cybernetics : Oui. Cybernetics permet à l'utilisateur d'analyser ses journaux depuis l'interface du produit. Côté exploitation, Datadog (région EU) analyse les journaux en temps réel, détecte les anomalies, et des tableaux de bord surveillent les événements de sécurité.

Réponse de Cybernetics : Partiellement. Les échecs de validation renvoient une erreur 422 et sont visibles dans les traces HTTP de Datadog (route et code de statut), mais ne font pas l'objet d'une entrée dédiée dans les journaux applicatifs. Les échecs d'authentification sont, eux, enregistrés explicitement dans notre base de journalisation.

Réponse de Cybernetics : Partiellement. Les tentatives de connexion par mot de passe et par Google ou Microsoft, réussies ou échouées, sont enregistrées et consultables dans Journaux > Connexion ; les vérifications de double authentification dans Journaux > MFA. Les connexions par passkey figurent dans l'historique du profil de l'utilisateur, mais pas encore dans les journaux de l'entreprise.

Réponse de Cybernetics : Partiellement. Les refus d'autorisation levés par les politiques sont visibles dans les journaux techniques ; une entrée dédiée et systématique, avec l'identité de l'utilisateur, est planifiée.

Réponse de Cybernetics : Partiellement. Les liens signés invalides ou falsifiés et les jetons expirés sont refusés et visibles dans les traces HTTP de Datadog. Il n'existe pas encore de détection dédiée des modifications inattendues des données d'état (voir 7.24).

Réponse de Cybernetics : Partiellement. Une requête avec un jeton de session invalide ou expiré est refusée (401) et visible dans les traces HTTP de Datadog ; elle ne fait pas l'objet d'une entrée dédiée dans les journaux applicatifs.

Réponse de Cybernetics : Oui. Les erreurs serveur (5xx) sont journalisées avec l'erreur complète et l'identifiant de trace ; les autres erreurs client (4xx) le sont avec leur seul message, à l'exception des erreurs attendues d'authentification et de validation (401, 422, 400), non journalisées en détail. Les champs sensibles sont masqués (voir 7.13), et Datadog capture en plus les exceptions non gérées.

Réponse de Cybernetics : Partiellement. Cybernetics trace automatiquement dans un journal d'audit les créations, modifications et suppressions des entités sensibles : utilisateurs (rôle, double authentification, mot de passe masqué), secrets de connecteurs, méthodes d'authentification, passkeys, appareils, comptes et agents. Ce journal est consultable et exportable dans l'application, mais il n'enregistre pas encore l'auteur de chaque modification. Certains paramètres d'administration, comme les permissions de l'entreprise et des utilisateurs ou les réglages de l'agent, ne sont pas encore couverts.

Réponse de Cybernetics : Partiellement. La connexion à la base de données exige TLS avec vérification du certificat : un échec empêche la connexion et apparaît dans les journaux d'erreurs de l'application. Il n'existe pas de journalisation dédiée des échecs TLS vers les autres systèmes.

Réponse de Cybernetics : Oui. Cybernetics consigne les opérations cryptographiques (chiffrement, hachage) et lève des exceptions en cas d'échec. Ces exceptions sont tracées par Datadog.
L'utilisateur peut constater par lui-même les échecs de chiffrement dans l'interface.

Réponse de Cybernetics : Non. Aucune fonction de hachage cryptographique ne protège aujourd'hui l'intégrité des entrées de journal. Le journal d'audit est stocké dans une base PostgreSQL dédiée, avec ses propres identifiants : cela garantit la cohérence des écritures, mais ne permet pas de détecter la modification ou la suppression d'un ancien événement par un compte disposant de droits d'écriture. Un chaînage cryptographique des événements et une copie vers un stockage immuable sont planifiés.

La protection des données est contrôlée et mise en place par Cybernetics.

Réponse de Cybernetics : Partiellement. Cybernetics applique le moindre privilège avec des rôles (Lecteur, Éditeur, Administrateur, Admin Support) et l'intersection avec les permissions du plan. Les contrôles d'autorisation sont centralisés dans des politiques côté serveur, appliquées aux requêtes de l'API, et couvrent la majorité des ressources ; des tests automatisés vérifient la frontière entre entreprises sur une partie des routes. Une revue de sécurité récente a toutefois identifié des cas résiduels d'autorisation entre entreprises et de contrôle des références d'objet (objets liés transmis dans une requête, éléments partagés, flux de sortie d'actifs, changement d'abonnement). Leur correction et leur couverture par des tests négatifs sont en cours.

Réponse de Cybernetics : Partiellement. Cybernetics conserve les clés de chiffrement déchiffrées dans un cache mémoire limité à une minute et efface les tampons de clés après usage ; les copies sous forme de chaînes ne peuvent pas être effacées dans un runtime JavaScript, et l'effacement en cas d'erreur est en cours de correction. Les conteneurs tournent avec un système de fichiers racine en lecture seule et l'API ne traite aucun fichier envoyé : aucun fichier temporaire sensible n'est écrit sur disque.

Réponse de Cybernetics : Oui. Cybernetics hache les mots de passe et les codes de récupération avec Argon2id. Les secrets de double authentification (TOTP) et les identifiants de connecteurs sont chiffrés en base, et les jetons de réinitialisation de mot de passe ne sont stockés que sous forme d'empreinte SHA-256.

Réponse de Cybernetics : Oui. Aucun code serveur n'est accessible publiquement : l'API s'exécute dans des conteneurs durcis non root, et seules les ressources client nécessaires (JavaScript produit par le build Nuxt, CSS, images) sont distribuées au navigateur. Le serveur de fichiers statiques de l'API ne sert que des images publiques, et Traefik bloque l'accès aux chemins sensibles (package.json, .env, .git, node_modules, fichiers de configuration, source maps).

Réponse de Cybernetics : Oui. Aucun mot de passe ni jeton d'accès n'est stocké dans le localStorage ou le sessionStorage : le jeton de session est conservé dans des cookies HttpOnly. Il transite une seule fois dans la réponse de connexion avant d'être placé en cookie. Pendant la double authentification, le stockage de session ne contient que l'adresse e-mail et la méthode, effacées une fois l'authentification terminée.

Réponse de Cybernetics : Oui. Le build Nuxt minifie le JavaScript livré au navigateur (renommage des variables) et en retire les commentaires ainsi que les appels console et debugger ; les source maps sont bloquées par Traefik en production. La minification n'est pas une frontière de sécurité : les contrôles d'autorisation sont faits côté serveur, et la configuration publique livrée au navigateur ne contient aucun secret.

Réponse de Cybernetics : Oui. Cybernetics n'expose pas de documentation d'API (Swagger/OpenAPI) en production : les spécifications sont générées hors ligne et ne sont pas incluses dans l'image déployée, et les routes de test internes ne sont chargées qu'en environnement de test.

Réponse de Cybernetics : Partiellement. Cybernetics transmet les mots de passe, codes de double authentification et jetons de session dans le corps des requêtes POST ou dans des en-têtes, jamais dans l'URL ; le jeton de réinitialisation de mot de passe voyage dans le fragment d'URL, qui n'est pas envoyé au serveur. En revanche, l'adresse e-mail apparaît encore dans l'URL de certaines requêtes (demande de réinitialisation, renvoi du code), et le lien d'invitation porte un jeton signé en paramètre.

Réponse de Cybernetics : Partiellement. Cybernetics désactive l'autocomplétion sur le champ du code de double authentification et utilise l'attribut « new-password » sur les formulaires de création et de réinitialisation de mot de passe. Le formulaire de connexion autorise volontairement les gestionnaires de mots de passe (« username », « current-password »), comme le recommandent les pratiques actuelles.

Réponse de Cybernetics : Partiellement. Cybernetics interdit la mise en cache (Cache-Control: no-store) des réponses qui contiennent des liens d'accès temporaires, et le jeton de session n'est jamais présent dans une page mise en cache. En revanche, un en-tête anti-cache n'est pas encore appliqué à toutes les réponses de l'API et à toutes les pages sensibles.

Réponse de Cybernetics : Partiellement. Une tâche planifiée supprime automatiquement les données qui ne sont plus nécessaires : les événements de sécurité et les e-mails collectés au bout de 7 jours, les données inactives depuis 3 ans, et les entreprises dont l'abonnement a expiré depuis plus de 2 jours, avec leurs journaux. Les jetons de réinitialisation sont à usage unique et expirent après 10 minutes. Deux limites : la clé de service KMS d'une entreprise supprimée n'est pas encore désactivée automatiquement, et les données restent dans les sauvegardes jusqu'à la fin de leur durée de conservation. La politique de suppression (délai, préavis, sauvegardes, clés) est en cours de formalisation.

Réponse de Cybernetics : Partiellement. Cybernetics isole les données de chaque entreprise : les accès sont vérifiés par une politique d'autorisation qui compare l'entreprise de l'utilisateur à celle de la ressource. Les identités des comptes et des appareils sont chiffrées avec la clé de service propre à chaque entreprise dans OVHcloud KMS, et chaque valeur avec une sous-clé dérivée selon l'entreprise, la table et la colonne ; les autres données chiffrées le sont avec des clés applicatives de la plateforme (voir 6.6). Les écarts de cloisonnement décrits en 5.5 sont en cours de correction.

Réponse de Cybernetics : Oui. Cybernetics chiffre toutes les communications externes en TLS sur chaque segment : du navigateur à Cloudflare, puis de Cloudflare à l'origine ; Cloudflare termine la première connexion TLS et en ouvre une seconde vers l'origine (mode SSL « Full (strict) » et Authenticated Origin Pulls). Les connexions de l'application à la base PostgreSQL sont elles aussi chiffrées. Les données sensibles sont en plus chiffrées au niveau applicatif, avec des clés gérées dans OVHcloud KMS.

Réponse de Cybernetics : Oui. Cybernetics obtient ses certificats d'origine auprès de Let's Encrypt via cert-manager (défi DNS-01), un certificat par domaine, renouvelé automatiquement 30 jours avant expiration. Des enregistrements CAA limitent les autorités autorisées à émettre, et Cloudflare valide ces certificats en mode « Full (strict) ».

Réponse de Cybernetics : Oui. Cybernetics redirige systématiquement HTTP vers HTTPS chez Cloudflare (« Always Use HTTPS ») et envoie HSTS pour un an, sous-domaines inclus, via Cloudflare, Traefik et l'application. Le domaine cybernetics.fr est effectivement inscrit dans la liste de préchargement HSTS des navigateurs (statut vérifié sur hstspreload.org). Les routes publiques ne sont exposées qu'en TLS, sans repli vers une connexion non chiffrée.

Réponse de Cybernetics : Oui. Cybernetics sert l'ensemble de l'application, de l'API et des pages authentifiées uniquement en HTTPS. Une politique Kyverno bloque le déploiement de tout Ingress sans TLS.

Réponse de Cybernetics : Partiellement. Cybernetics chiffre en TLS les connexions vers ses systèmes externes. La base PostgreSQL est jointe en TLS avec vérification du certificat par l'autorité du fournisseur, et les URL de connecteurs saisies par les clients doivent obligatoirement être en HTTPS. Le durcissement de la validation des certificats serveur est en cours de généralisation à l'ensemble des connecteurs.

Réponse de Cybernetics : Oui. Cybernetics s'appuie sur des implémentations TLS standard : Cloudflare en périphérie et Traefik à l'origine. Les deux imposent TLS 1.2 au minimum (TLS 1.3 activé chez Cloudflare). Côté Traefik, seules des suites ECDHE avec AES-GCM ou ChaCha20-Poly1305 sont acceptées, avec vérification stricte du nom de serveur (SNI).

Réponse de Cybernetics : Oui. Cybernetics échange ses données en UTF-8 : l'API décode les requêtes en UTF-8 et renvoie ses réponses JSON et texte avec « charset=utf-8 » dans l'en-tête Content-Type.

Réponse de Cybernetics : Oui. La politique de référent effectivement envoyée par le proxy (Traefik) est « strict-origin-when-cross-origin » : vers un site externe, seule l'origine est transmise, jamais le chemin ni les paramètres de l'URL.

Réponse de Cybernetics : Oui. Cybernetics fonctionne sur des versions récentes et maintenues : Node.js 24 (Docker Hardened Images), AdonisJS 7, Nuxt 4 et Traefik 3.7. Les versions sont épinglées et mises à jour via Dependabot.

Réponse de Cybernetics : Partiellement. Dependabot vérifie chaque semaine les dépendances npm, les actions GitHub et les images Docker ; les images tierces sont réanalysées chaque semaine (Grype) et les nœuds redémarrent automatiquement pour appliquer les correctifs système. Les contrôles de sécurité de l'intégration continue ne sont pas encore bloquants sur tous les dépôts, et une partie des actions GitHub n'est pas épinglée par empreinte ; leur généralisation est en cours.

Réponse de Cybernetics : Oui. Cybernetics ne propose aucun listing de répertoires : les fichiers statiques sont servis sans index automatique, les fichiers cachés sont ignorés, et l'accès aux chemins sensibles (.git, node_modules, fichiers de configuration, source maps) est bloqué par Traefik.

Réponse de Cybernetics : Partiellement. Les conteneurs applicatifs tournent avec un utilisateur non root, sans élévation de privilèges, avec toutes les capabilities Linux retirées, un système de fichiers racine en lecture seule et un profil seccomp, imposés par des politiques Kyverno bloquantes ; l'agent installé sur les postes tourne encore avec des privilèges élevés (voir 14.7).

Réponse de Cybernetics : Partiellement. Une session invalide est refusée et son cookie effacé, et les appels vers les services externes échouent rapidement au lieu de contourner les contrôles. Certaines erreurs internes renvoient encore leur message technique (voir 7.1).

Réponse de Cybernetics : Oui. Cybernetics construit ses images en plusieurs étapes : seuls le résultat compilé et les dépendances de production sont copiés dans une image finale minimale (Docker Hardened Image, sans shell ni gestionnaire de paquets). Les fichiers de build sensibles sont supprimés de l'image de l'interface.

Réponse de Cybernetics : Partiellement. Cybernetics exclut les dépendances de développement et de test de ses images de production, et l'image de l'interface ne contient que le résultat du build. Les fichiers de test sources ne sont pas encore systématiquement exclus de l'image de l'API ; ils ne sont pas exposés publiquement.

Réponse de Cybernetics : Oui. Cybernetics interdit par défaut l'indexation de l'application (« Disallow: / ») et n'autorise nommément que quelques pages publiques : aucun chemin interne ou d'administration n'y figure. L'API et l'application envoient en plus un en-tête « X-Robots-Tag: noindex ».

Réponse de Cybernetics : Oui. Cybernetics déclare explicitement chaque route de l'API avec sa méthode HTTP (GET, POST, PUT, PATCH, DELETE). La substitution de méthode est désactivée et la politique CORS liste les méthodes autorisées.

Réponse de Cybernetics : Partiellement. Cybernetics bloque les méthodes TRACE et CONNECT sur l'API au niveau du WAF Cloudflare, et l'API ne répond qu'aux méthodes explicitement déclarées. Ce blocage explicite n'est pas encore étendu à tous les domaines.

Réponse de Cybernetics : Partiellement. Cybernetics applique ses règles de sécurité (TLS, en-têtes, filtrage) au niveau de Cloudflare et de Traefik, quelle que soit la version du protocole utilisée par le client. HTTP/3 est volontairement désactivé à l'origine. Les versions HTTP proposées par Cloudflare ne sont pas encore déclarées explicitement dans notre configuration Terraform.

Réponse de Cybernetics : Oui. Les en-têtes qui révèlent la technologie utilisée ne sont pas exposés : l'en-tête Server est vidé par Traefik et X-Powered-By n'est pas émis.

Réponse de Cybernetics : Oui. Cybernetics versionne toute sa configuration de sécurité dans Git, sous forme lisible : valeurs Helm, politiques Kyverno, règles Cloudflare et infrastructure Terraform. Toute modification faite hors code apparaît comme un écart au plan Terraform. Un dossier de preuves de conformité (JSON, Markdown, PDF) est généré automatiquement chaque semaine pour les audits.

Réponse de Cybernetics : Oui. Cybernetics recense ses composants dans le code : l'infrastructure est décrite en Terraform, les images tierces sont inventoriées dans un registre miroir signé (Cosign) avec attestation de provenance, et un inventaire logiciel (SBOM) des images en fonctionnement est produit en continu par Datadog.

Réponse de Cybernetics : Partiellement. Cybernetics sépare la préproduction de la production : namespaces Kubernetes, bases de données, comptes et clés de chiffrement dédiés, et accès à la préproduction réservé aux collaborateurs authentifiés par SSO via Cloudflare Access. Les deux environnements partagent pour l'instant le même cluster Kubernetes et le même serveur de base de données.

Réponse de Cybernetics : Partiellement. Toutes les modifications sont gérées dans Git (GitHub) : code, infrastructure et configuration. Les contrôles automatiques (qualité, CodeQL, dépendances, secrets) sont bloquants avant publication sur le site web ; sur l'API, l'interface et l'agent, ils ne s'appliquent pas encore à tous les contributeurs ni à tous les tags de publication, et les tests de bout en bout ne tournent pas en intégration continue. Leur généralisation est en cours.

Réponse de Cybernetics : Oui. Cybernetics accède à PostgreSQL via le query builder et l'ORM Lucid (AdonisJS), qui paramètrent les requêtes. Les quelques fragments SQL bruts utilisent des paramètres liés ; les seules valeurs interpolées sont des constantes internes ou des valeurs issues d'une liste fermée (par exemple le sens de tri), jamais une saisie libre.

Réponse de Cybernetics : Oui. Cybernetics valide les entrées côté API avec des schémas VineJS (types, formats, listes fermées, expressions régulières) et rejette la requête avant tout traitement si la validation échoue. Côté interface, Vue échappe automatiquement le contenu affiché et aucun rendu HTML brut (v-html) n'est utilisé.

Réponse de Cybernetics : Partiellement. Cybernetics est développé en TypeScript, avec vérification des types dans l'intégration continue et contrôle strict des valeurs nulles. Certaines options du mode strict (comme noImplicitAny) ne sont pas encore activées sur l'API.

Réponse de Cybernetics : Partiellement. Cybernetics utilise un compte PostgreSQL dédié par base (données applicatives, journalisation) et par environnement, distinct du compte d'administration du service managé. Ce compte applicatif sert aussi aux migrations de schéma : il n'existe pas encore de séparation fine entre droits de lecture, d'écriture et de modification du schéma.

Réponse de Cybernetics : Oui. Cybernetics stocke les identifiants de base dans le gestionnaire de secrets OVHcloud OKMS et les injecte dans les pods par External Secrets, jamais dans le code ; Kyverno bloque tout secret Kubernetes créé hors de ce mécanisme. En production, la connexion à PostgreSQL est chiffrée en TLS avec vérification du certificat, et les mots de passe de base sont stockés en SCRAM-SHA-256.

Réponse de Cybernetics : Oui. Cybernetics ne code en dur aucune chaîne de connexion : hôte, port, utilisateur, mot de passe et base sont lus depuis des variables d'environnement typées et validées au démarrage. En production, ces valeurs proviennent du gestionnaire de secrets chiffré OVHcloud OKMS, et aucun fichier .env n'est versionné.

Réponse de Cybernetics : Non. Cybernetics n'utilise pas de procédures stockées. L'accès aux données passe par la couche d'abstraction de l'ORM Lucid (modèles, requêtes paramétrées) et par des contrôles d'autorisation applicatifs.

Réponse de Cybernetics : Oui. Cybernetics gère les connexions par un pool (de 2 à 10 connexions par base) : elles sont rendues au pool dès la fin de chaque requête, et les connexions inactives sont fermées automatiquement.

Réponse de Cybernetics : Partiellement. Cybernetics utilise une base PostgreSQL managée par OVHcloud et n'utilise jamais le compte d'administration du service : l'application se connecte avec des comptes dédiés, dont les mots de passe sont générés par le fournisseur et renouvelés selon une procédure documentée.

Réponse de Cybernetics : Partiellement. Cybernetics active uniquement les extensions PostgreSQL nécessaires (unaccent, pg_trgm), et la base n'est accessible que depuis le réseau privé du cluster. Les autres fonctionnalités du moteur relèvent de l'offre managée OVHcloud et ne font pas l'objet d'une désactivation spécifique de notre part.

Réponse de Cybernetics : Partiellement. Cybernetics ne crée aucun schéma ni jeu de données d'exemple en production : les données de démonstration et de test sont réservées aux environnements hors production. Le contenu initial fourni par le service managé relève d'OVHcloud.

Réponse de Cybernetics : Partiellement. Cybernetics ne crée que les comptes de base strictement nécessaires (un par base et par environnement), et l'application n'utilise aucun compte par défaut. Les comptes système internes du service managé sont gérés par OVHcloud.

Réponse de Cybernetics : Partiellement. Cybernetics sépare les identifiants de base par usage et par environnement : un compte pour les données applicatives, un autre pour la journalisation, et des comptes distincts entre production et préproduction. Il n'existe pas encore de comptes distincts par niveau de privilège (lecture seule, écriture, administration).

​

Réponse de Cybernetics : Oui. Cybernetics n'inclut ni ne charge dynamiquement aucun code à partir de données fournies par l'utilisateur : les seuls chargements dynamiques portent sur des modules internes d'un répertoire fixe de l'application.

Réponse de Cybernetics : Sans objet. Cybernetics ne permet pas le téléversement de fichiers par les utilisateurs. Les images (avatar, fond d'écran) et les preuves de conformité sont référencées par URL, et toutes les routes qui modifient ces données exigent une authentification et une autorisation.

Réponse de Cybernetics : Sans objet. Cybernetics ne permet pas le téléversement de fichiers. L'avatar est une URL : son contrôle porte sur l'extension indiquée dans l'URL (JPEG ou PNG), pas sur le type réel du contenu. Côté navigateur, la politique de sécurité du contenu (CSP) n'autorise le chargement d'images que depuis l'application elle-même et Intercom.

Réponse de Cybernetics : Sans objet. Cybernetics ne reçoit ni ne stocke aucun fichier des utilisateurs, et le serveur ne télécharge jamais les images référencées par URL. Le contrôle des URL d'image porte sur l'extension, non sur le contenu ; la CSP de l'application limite par ailleurs les sources d'images autorisées.

Réponse de Cybernetics : Sans objet. Cybernetics ne stocke aucun fichier téléversé par les utilisateurs. Les seuls fichiers distribués (installateurs de l'agent Cybernetics) sont hébergés sur un stockage objet OVHcloud séparé de l'application et servis par des liens temporaires signés.

Réponse de Cybernetics : Sans objet. Cybernetics ne permet pas le téléversement de fichiers ; aucun fichier fourni par un utilisateur ne peut donc être exécuté ou interprété par le serveur.

Réponse de Cybernetics : Sans objet. Cybernetics n'a pas de répertoire de téléversement. De plus, le système de fichiers des conteneurs applicatifs est en lecture seule et les conteneurs s'exécutent sans privilèges root.

Réponse de Cybernetics : Sans objet. Cybernetics ne permet pas le téléversement de fichiers. Les applications s'exécutent dans des conteneurs Kubernetes isolés, non root, avec un système de fichiers racine en lecture seule, et Kyverno interdit les montages de volumes de l'hôte.

Réponse de Cybernetics : Partiellement. L'avatar référencé par URL est limité aux formats JPEG et PNG. Les liens de preuve de conformité acceptent aujourd'hui les schémas http, https, smb et file, pour référencer un document conservé sur un partage interne de l'entreprise. Ces liens sont uniquement enregistrés comme texte : le serveur ne les ouvre ni ne les récupère jamais, et l'application ne les affiche pas comme liens cliquables. Les schémas smb et file présentent toutefois des risques côté poste de travail (partages internes, emplacements locaux) : leur restriction est planifiée.

Réponse de Cybernetics : Partiellement. Les redirections d'authentification et de paiement sont générées côté serveur à partir de la configuration des fournisseurs, et les liens signés reçus par e-mail sont validés contre leur route d'API exacte, à une exception près en cours de correction. Côté interface, certains identifiants issus de l'URL de la page sont encore insérés dans les chemins d'appel de l'API sans validation de format ; les autorisations côté serveur s'appliquent, et leur validation est planifiée.

Réponse de Cybernetics : Partiellement. Les ressources sont désignées par des identifiants (UUID) et aucun chemin de fichier n'est reçu des utilisateurs ; l'agent transmet encore un nom de fichier d'installation dont la restriction à une liste fermée est en cours.

Réponse de Cybernetics : Oui. Cybernetics ne renvoie jamais de chemin de fichier du serveur au client : les réponses de l'API ne contiennent que des données métier et des URL publiques.

Réponse de Cybernetics : Oui. Cybernetics déploie ses applications avec un système de fichiers racine en lecture seule ; une politique Kyverno en mode bloquant rejette tout conteneur qui ne respecte pas cette règle.

Réponse de Cybernetics : Sans objet. Cybernetics ne permet pas le téléversement de fichiers ; aucune analyse antivirus n'est donc nécessaire côté plateforme.

​

Réponse de Cybernetics : Partiellement. Cybernetics valide toutes les requêtes reçues par l'API avec des schémas VineJS (types, formats, longueurs) et limite leur taille ; les réponses des connecteurs ne sont pas encore validées par schéma (voir 1.3). En sortie, l'interface Nuxt/Vue échappe les données par défaut et n'utilise pas de rendu HTML brut. Un durcissement complémentaire est en cours sur un connecteur qui transmet des données à un outil externe.

Réponse de Cybernetics : Oui. Cybernetics est développé en TypeScript sur des runtimes à mémoire gérée (Node.js pour l'API, Deno pour l'agent) : les bornes des tampons sont vérifiées par le runtime, et Cybernetics ne contient aucun module natif maison.

Réponse de Cybernetics : Oui. Cybernetics ne manipule pas de chaînes terminées par NULL : les chaînes JavaScript/TypeScript ont une longueur explicite, gérée par le runtime Node.js ou Deno.

Réponse de Cybernetics : Oui. Cybernetics s'appuie sur des runtimes à mémoire gérée : un accès hors limites dans une boucle ne peut pas déborder en mémoire, les tableaux et les Buffers étant bornés par le runtime.

Réponse de Cybernetics : Partiellement. La plupart des champs texte sont bornés via les règles de validation (maxLength) et la taille des corps de requête est limitée (1 Mo en JSON et formulaire) ; quelques champs libres ne sont bornés que par cette limite globale. L'analyseur multipart d'AdonisJS n'est associé à aucun type de contenu : aucune route n'accepte de fichier téléversé.

Réponse de Cybernetics : Oui. Cybernetics passe par des transactions gérées qui libèrent explicitement les connexions, ses appels HTTP sortants ont des délais maximaux (20 s par requête, 5 s de connexion), et les connexions à la base sont rendues à un pool avec fermeture automatique des connexions inactives.

Réponse de Cybernetics : Oui. Cybernetics fonctionne sur les runtimes Node.js et Deno (moteur V8), qui s'appuient sur les protections mémoire du système, dont la pile non exécutable. Cybernetics ne compile aucun code natif maison.

Réponse de Cybernetics : Partiellement. Cybernetics n'utilise ni eval ni new Function dans son code, qui est analysé par l'analyse statique Datadog (règles de sécurité Node.js et TypeScript) en intégration continue et par CodeQL chaque semaine ; la généralisation de ces contrôles à tous les contributeurs est en cours. L'exécution de commandes externes subsiste dans deux cas limités (un connecteur et un outil interne de documentation) et doit être remplacée par des appels plus stricts.

Réponse de Cybernetics : Oui. Cybernetics délègue la libération de la mémoire au ramasse-miettes des runtimes Node.js et Deno, sans allocation manuelle ni code natif maison.

Réponse de Cybernetics : Partiellement. Cybernetics efface en mémoire (remplissage par des zéros) les clés racine et les clés dérivées issues du KMS dès la fin de chaque opération de chiffrement ou de déchiffrement. Cet effacement n'est pas encore garanti en cas d'erreur de déchiffrement, et les copies intermédiaires sous forme de chaînes ne peuvent pas être effacées dans un runtime JavaScript.

​

Réponse de Cybernetics : Oui. Cybernetics repose sur du code managé en TypeScript et sur des frameworks éprouvés (AdonisJS, Nuxt, Deno) et leurs bibliothèques standard (node:crypto, WebCrypto). Cybernetics ne contient pas de code natif maison ; seul l'agent Windows appelle directement l'API système Windows pour s'enregistrer comme service.

Réponse de Cybernetics : Partiellement. Cybernetics privilégie les API intégrées. Pour collecter l'inventaire, l'agent lance des outils système avec des arguments séparés ; les valeurs insérées dans ses scripts PowerShell sont échappées, et cet échappement est en cours de renforcement. Côté API, un connecteur fait encore appel à un outil externe en ligne de commande ; son durcissement est en cours.

Réponse de Cybernetics : Partiellement. Les dépendances sont figées par fichiers de verrouillage (npm ci, deno.lock) ; les images de base de l'API et du site sont épinglées par empreinte SHA-256, pas encore celle de l'interface. En production, les images tierces sont signées (Cosign) et vérifiées par Kyverno. Les exécutables de l'agent sont signés et chaque mise à jour est contrôlée par une empreinte SHA-256, sans vérification locale de la signature de l'éditeur à ce jour. Une partie des actions GitHub n'est pas épinglée par empreinte.

Réponse de Cybernetics : Partiellement. Les opérations les plus sensibles sont protégées contre les requêtes simultanées par des transactions avec verrouillage de ligne (par exemple, un jeton de réinitialisation ne peut être utilisé qu'une fois, même en cas de rejeu simultané, et une session ne peut pas être ouverte deux fois en parallèle) ; certains codes à usage unique et certains quotas ne sont pas encore verrouillés, et leur correction est planifiée.

Réponse de Cybernetics : Partiellement. Les ressources partagées sont protégées par des transactions et des verrous de ligne, et la concurrence des traitements vers les services tiers est limitée ; les contrôles de quotas ne sont pas encore protégés contre les requêtes simultanées.

Réponse de Cybernetics : Partiellement. Cybernetics est écrit en TypeScript avec vérification stricte des valeurs nulles (strictNullChecks), et ESLint ou deno lint sont appliqués. Certaines options strictes (noImplicitAny, strictPropertyInitialization) ne sont pas encore activées.

Réponse de Cybernetics : Partiellement. Les conteneurs de l'API et de l'interface tournent avec un utilisateur non root, sans élévation de privilèges, avec toutes les capabilities retirées et un système de fichiers en lecture seule, imposés par Kyverno. L'agent installé sur les postes tourne en revanche avec les privilèges administrateur (root ou compte système) pour collecter l'inventaire, et sa configuration conteneur prévoit elle aussi l'exécution en root, sans mode privilégié ni capabilities.

Réponse de Cybernetics : Oui. Cybernetics stocke les montants (coûts unitaires) en nombres entiers de centimes pour éviter les erreurs d'arrondi des nombres à virgule flottante, et ne les convertit qu'à l'affichage.

Réponse de Cybernetics : Partiellement. Cybernetics n'utilise aucune fonction d'exécution dynamique de code (eval, new Function, vm). Un durcissement complémentaire est en cours sur un connecteur qui transmet des données à un outil externe.

Réponse de Cybernetics : Oui. Cybernetics n'offre aucun moyen aux utilisateurs de générer ou d'exécuter du code et n'utilise pas d'évaluation dynamique. En production, les conteneurs ont un système de fichiers racine en lecture seule, imposé par Kyverno.

Réponse de Cybernetics : Partiellement. Les dépendances sont analysées en continu (Dependabot, Datadog SCA, audit des dépendances, CodeQL) et les images tierces sont scannées (Grype) avant d'être copiées dans le registre interne. Ces contrôles sont bloquants sur le site web et en cours d'extension à l'API, à l'interface et à l'agent.

Réponse de Cybernetics : Partiellement. L'agent Cybernetics récupère ses mises à jour via des liens temporaires signés fournis par l'API et vérifie l'empreinte SHA-256 de chaque paquet avant installation. Les images de conteneurs sont récupérées par empreinte et leur signature Cosign est vérifiée par Kyverno. L'agent ne vérifie pas encore lui-même la signature de l'éditeur au moment de la mise à jour, et le retour automatique à la version précédente en cas d'échec n'est pas encore implémenté.

Une question ? Nous contacter.