Comment Tenvo est construit, crypté et opéré, et comment signaler une vulnérabilité. Réponses honnêtes, y compris sur ce que nous n'avons pas encore certifié.
Le contenu des sessions (écran, frappes, fichiers transférés) est chiffré par TLS avec un certificat unique par appareil. Les connexions pair-à-pair directes sont chiffrées de bout en bout. Le client est open source, ce qui permet un audit indépendant du chiffrement.
Nous ne sommes pas encore certifiés SOC 2 ou ISO 27001. Les fournisseurs d'infrastructure sur lesquels nous comptons le sont. Si vous trouvez une vulnérabilité, écrivez à support@tenvoai.com.
Cette page décrit l'architecture de sécurité du client Tenvo et le service relais hébergé opéré par upDevTeam LTD sur tenvoai.com, et le processus de divulgation responsable pour signaler les vulnérabilités.
C'est informatif. Les engagements de sécurité contractuels figurent dans les Conditions de Service et le DPA.
Les connexions sont chiffrées par TLS. Chaque appareil reçoit un certificat unique délivré par notre autorité de certification. Sur les connexions pair-à-pair directes, la session est chiffrée de bout en bout entre les deux appareils ; lorsqu'une connexion directe n'est pas possible, le trafic est relégué et chiffré en transit.
Les bibliothèques cryptographiques sont fixées aux versions amont auditées et mises à jour selon un calendrier documenté. Nous n'implémentons pas nos propres primitives.
L'infrastructure de production repose sur un petit nombre de prestataires :
Chaque prestataire traitant des données personnelles est lié par un accord de traitement des données. Lorsque le traitement a lieu en dehors de l'EEE, nous nous appuyons sur des garanties appropriées telles que les Clauses Contractuelles Types de l'UE.
Contrôles d'accès au niveau utilisateur :
Statut honnête à la date en haut de cette page : Tenvo et upDevTeam LTD ne sont PAS actuellement certifiés selon SOC 2, ISO 27001, ISO 27017, ISO 27018, HIPAA, PCI-DSS, FedRAMP, ou tout autre standard de sécurité formel de tierce partie. Les affirmations publiques à l'inverse sont erronées.
Nos prestataires d'hébergement, de base de données (Supabase) et de paiement (Stripe) sont eux‑mêmes audités SOC 2 / ISO 27001 ; notre sécurité hérite d'une partie de leur assurance mais ne l'égale pas.
Nous travaillons en vue d'une révision de sécurité externe pour 2026 et publierons le résultat sur cette page dès qu'il sera disponible. Nous ne prétendrons pas à des certifications que nous ne détenons pas.
Les actions administratives sur les systèmes de production sont enregistrées dans un journal central, append-only, avec une rétention d'au moins 90 jours. Le journal enregistre l'acteur, l'action, le timestamp et l'IP source. L'accès à la production est limité à un petit nombre d'ingénieurs nommés avec une authentification à deux facteurs obligatoire.
Nous surveillons le temps de disponibilité, les taux d'erreur et les signaux liés aux abus (pics de trafic soudains, tentatives de force brute, énumération des identifiants de pair) et effectuons une rotation de la couverture d'astreinte sur une base hebdomadaire.
Les dispositifs du personnel utilisés pour accéder aux systèmes de production doivent :
Le client Tenvo est open source sous AGPL-3.0. Tout le monde peut lire le code source, le compiler et vérifier qu'il fonctionne comme nous l'affirmons. Le code du relais (un fork de hbbr / hbbs) est également open source.
Nous publions des hachages SHA-256 pour chaque installateur publié. Nous poursuivons la signature de code EV pour Windows et la notarisation d'Apple pour macOS ; l'état de la construction actuelle est sur la page de téléchargement.
Nous accueillons les rapports des chercheurs en sécurité indépendants. Pour signaler une vulnérabilité :
Nous ne gérons actuellement pas de programme de récompense pour les bugs payants. Nous reconnaissons publiquement les rapports significatifs (avec votre permission) sur une page hall of fame une fois le problème corrigé.
Les découvertes critiques (RCE, chiffrement de session brisé, contournement massif de l'authentification) sont immédiatement escaladées vers l'ingénieur de garde et priorisées par rapport au travail planifié.
Les éléments suivants ne sont pas éligibles au traitement en zone de sécurité au titre de la section 9 et peuvent être signalés mais risquent de ne pas être considérés comme des vulnérabilités :
Nous maintenons un manuel de réponse aux incidents écrit couvrant la détection, la containment, l'éradication, la récupération et la révision post-incident. Le manuel est examiné au moins une fois par an et après chaque incident matériel.
En cas de violation de données personnelles, les délais de notification de notre Politique de Confidentialité et du DPA s'appliquent.
Lorsque l'architecture ou tout engagement sur cette page change de manière matérielle, nous mettons à jour la date 'Dernière mise à jour' et annonçons le changement dans le journal des modifications.
Lire le code source est le moyen le plus fiable de vérifier une affirmation de sécurité. Commencez sur github.com/GoDeskFlow.