Le présent Aperçu de sécurité décrit les mesures administratives, techniques et organisationnelles que nous utilisons pour protéger les Services Melaya, les comptes utilisateurs, le Contenu utilisateur, les identifiants d’échange, les tokens OAuth Google et les données opérationnelles. Il fait partie de nos Conditions d’utilisation et de notre Politique de confidentialité et vise à expliquer le modèle de sécurité de Melaya aux clients, partenaires et chercheurs en sécurité.
1. Chiffrement en transit et au repos
Toutes les données en transit entre les clients des utilisateurs et les Services sont protégées par le protocole Transport Layer Security (TLS) version 1.2 ou supérieure, avec terminaison chez Cloudflare en périphérie du déploiement. Le profil TLS de production suit le guide de compatibilité Mozilla Intermediate : TLS 1.2 et 1.3 uniquement, suites de chiffrement ECDHE uniquement, chiffrements AEAD à confidentialité persistante uniquement, HSTS avec un max-age de deux ans et la directive preload, ainsi qu'une politique de sécurité du contenu stricte avec une liste d'autorisation explicite pour connect-src. La politique de sécurité du contenu est appliquée sur les deux interfaces : le serveur API définit default-src 'none' via son middleware de gestion des en-têtes de sécurité, et l'application web publique intègre une politique qui autorise nos propres backends ainsi que les fournisseurs de paiement et de connexion, bloque le contenu des extensions et le détournement par balise base ou action de formulaire, et restreint l'exécution des scripts, de sorte qu'un script injecté ne peut exfiltrer des données vers une origine attaquante. Le profil TLS complet, la liste de chiffrements validée et la cadence de révision trimestrielle sont documentés dans le manuel de référence TLS Baseline dans le coffre-fort de sécurité interne. Les appels internes entre services au sein de notre infrastructure transitent par des liens en loopback ou sur des réseaux privés.
Le chiffrement des données au repos est mis en oeuvre aujourd'hui au niveau de la couche applicative par un chiffrement en enveloppe au niveau des champs. Le chiffrement intégral des disques au niveau de la couche de stockage n'est pas encore activé : les dispositifs de blocs en production ne sont actuellement pas chiffrés au niveau du disque. Le chiffrement au niveau des volumes à l'aide de LUKS a été sélectionné comme solution corrective et constitue un élément validé de la feuille de route de sécurité. Dans l'attente de sa mise en oeuvre, Melaya ne présente pas le chiffrement au niveau du disque ni le chiffrement des volumes géré par le fournisseur comme un contrôle actif.
Les valeurs sensibles sont protégées par une couche de chiffrement en enveloppe au niveau applicatif, mise en oeuvre dans notre service de chiffrement en enveloppe. Les identifiants d'API des plateformes d'échange (clé, secret, phrase de passe), les identifiants de connecteur par utilisateur et les jetons OAuth, ainsi que les secrets TOTP et les codes de récupération MFA, sont encapsulés avec AES-256-GCM à l'aide d'une clé principale de 256 bits détenue uniquement dans le processus serveur avant d'être transmis au fournisseur de coffre Infisical ou écrits dans la table de repli agents.credentials. Le format de transmission inclut un identifiant de clé explicite (v1:<kid>:<base64(iv|ciphertext|tag)>) afin que le serveur puisse accepter plusieurs clés valides pendant une fenêtre de rotation et acheminer les lectures vers la clé exacte ayant encapsulé chaque valeur. Les nouvelles écritures utilisent toujours la clé active, qui est la première entrée dans la liste de clés configurée. La rotation est une procédure en trois versions qui ne met jamais la plateforme hors service : ajout de la nouvelle clé en deuxième position (les écritures vont toujours vers l'ancienne clé, la nouvelle clé est en lecture seule), promotion en première position (les écritures basculent vers la nouvelle clé, l'ancienne clé reste lisible), ré-encapsulation des lignes historiques liées à l'identifiant de clé retirée, puis suppression de l'ancienne entrée. Ni Infisical ni l'hôte Postgres ne voient les identifiants en clair à aucun moment : une compromission de l'un ou l'autre sous-traitant pris isolément ne produit que du texte chiffré, et l'attaquant doit en outre disposer d'une clé d'enveloppe configurée pour récupérer une clé d'échange. Un script de migration ponctuel a traité les lignes en clair résiduelles antérieures à l'existence de la couche d'enveloppe. La migration a été exécutée sur la base de données de production et son vérificateur de bout en bout (envelope-verify.ts, 7/7 scénarios) se termine avec un code zéro à chaque exécution CI et contre la production en direct.
2. Isolation des tenants et des pipelines
La plateforme applique une isolation logique entre les locataires au niveau de la couche applicative. Chaque requête authentifiée contient un identifiant utilisateur dérivé d'un JSON Web Token validé, et chaque requête de base de données, accès au stockage objet et recherche dans l'index de récupération est délimitée par cet identifiant via des requêtes SQL paramétrées et le câblage du contexte tRPC. Les index de récupération construits pour le cadre agentique sont stockés par pipeline et ne sont retournés qu'aux requêtes provenant du pipeline qui les possède. L'état du moteur, les configurations de stratégie et les historiques d'ordres sont également partitionnés par utilisateur. La sécurité au niveau des lignes de Postgres est appliquée comme couche de défense en profondeur derrière le cloisonnement de la couche applicative : FORCE ROW LEVEL SECURITY est actif en production sur 44 tables des schémas agents.* et cex.* sous 117 politiques de sécurité au niveau des lignes, et l'application se connecte sous un rôle dédié à faibles privilèges qui exécute NOBYPASSRLS et ne peut donc pas accéder aux données d'autres locataires même si une requête omet accidentellement sa clause WHERE user_id. Le contexte de sécurité au niveau des lignes par requête définit l'identifiant du locataire et le rôle comme paramètres de session avant l'exécution de toute requête, et le pool de connexions émet DISCARD ALL à la libération afin que le contexte ne puisse pas se propager entre les locataires. Dix-sept scénarios inter-locataires dans notre vérificateur rls-verify.ts se terminent avec un code zéro sur la base de données en production à chaque exécution CI, couvrant les cas SELECT, INSERT, UPDATE, DELETE, réaffectation de propriété, contournement administratif, zéro ligne sans contexte, et régressions de fuite de contexte.
3. Gestion des clés et des secrets
Les secrets applicatifs, les clés de signature, les identifiants de base de données et les clés d'API tierces utilisées par Melaya elle-même sont stockés dans un fichier de secrets contrôlé par l'opérateur chargé au démarrage du processus et dans notre fournisseur de coffre. Ils ne sont jamais consignés dans le contrôle de source et les valeurs de production ne sont pas partagées entre les développeurs. La clé de chiffrement en enveloppe est une clé de chiffrement dédiée détenue uniquement dans le magasin de secrets de l'opérateur, séparément des identifiants de base de données Postgres et séparément du jeton de coffre Infisical, de sorte que la compromission de l'un quelconque des trois ne révèle pas les identifiants d'échange en clair. Il est fortement recommandé aux clients de limiter chaque clé d'API d'échange aux seules permissions de trading, de désactiver les retraits sur la plateforme émettrice et d'appliquer la liste blanche d'IP lorsque la plateforme le prend en charge.
Les jetons de session sont signés dans une fenêtre de rotation multi-clés. Le serveur accepte un ensemble ordonné de clés de signature, chacune étiquetée avec un identifiant de clé court. Les nouveaux jetons sont signés sous la première clé (active) et portent cet identifiant dans l'en-tête JWT pour une vérification en O(1). Les jetons émis sous une clé retirée de la fenêtre continuent de se vérifier jusqu'à l'expiration de leur TTL de sept jours, après quoi la clé retirée peut être supprimée. Les jetons expirés sont rejetés immédiatement, même si une clé non active les accepterait autrement. Les allers-retours de vérification sont contrôlés dans notre vérificateur jwt-keys-verify.ts.
4. Authentification et contrôle d'accès
L'authentification des utilisateurs repose sur l'adresse électronique et le mot de passe avec hachage bcrypt au facteur de travail 12, combinée à une limitation du débit sur les points d'entrée de connexion, d'inscription et de mot de passe oublié (20 tentatives par IP par période de 15 minutes, appliquée par un limiteur distribué Redis). Les jetons de session sont émis sous forme de JSON Web Tokens avec une expiration de sept jours et liés aux revendications utilisateur, rôle et niveau. Le contrôle d'accès basé sur les rôles distingue user de admin, et le contrôle d'accès basé sur le niveau conditionne les fonctionnalités selon le catalogue à quatre niveaux. Chaque action importante est vérifiée côté serveur. Les contrôles côté client ne constituent qu'un indice d'interface et ne sont jamais utilisés à des fins de sécurité.
L'authentification à deux facteurs est disponible pour tous les utilisateurs via le profil TOTP standard (RFC 6238, SHA-1, 6 chiffres, période de 30 secondes, tolérance de dérive de ±1 fenêtre) et est compatible avec toutes les applications d'authentification courantes. Les secrets partagés TOTP sont générés côté serveur avec 160 bits d'entropie, encapsulés via la couche de chiffrement en enveloppe décrite à la section 1, et stockés dans une colonne encapsulée sur la ligne utilisateur. Les codes de récupération sont générés une seule fois lors de l'inscription, hachés avec bcrypt au facteur de travail 12, puis encapsulés une seconde fois par la couche d'enveloppe, de sorte qu'une compromission de la base de données seule ne permet pas de les reconstituer. L'inscription est un processus en deux étapes qui exige de l'utilisateur qu'il prouve avoir configuré son application d'authentification en saisissant un code actif avant que le second facteur soit marqué comme actif. Le flux de connexion devient une vérification de mot de passe, puis un jeton de défi de courte durée (cinq minutes), puis une vérification de code qui consomme atomiquement la ligne de défi. Un jeton de défi capturé ne peut pas être rejoué après un consommation réussie. L'authentification multifacteur est obligatoire pour l'ajout d'identifiants d'API CEX et pour la génération de clés d'API de la plateforme, les deux actions à plus fort impact sur les fonds dans le produit. Chaque résultat de défi MFA (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) est inscrit dans le journal d'audit en ajout seul décrit à la section 6, de sorte que les schémas de défi sont auditables et infalsifiables.
L'accès des employés de Melaya aux systèmes de production est accordé ingénieur par ingénieur selon un processus d'approbation à deux personnes documenté, et révoqué lorsqu'il n'est plus nécessaire. Le provisionnement des accès requiert l'approbation d'une personne autre que le demandeur, et la procédure de départ désactive le compte, fait pivoter les clés de signature JWT pour invalider les sessions en cours, révoque les clés d'API et supprime les clés SSH. Les entrées sudoers privilégiées obsolètes et les clés autorisées SSH sont nettoyées session par session, et une cadence de révision d'accès trimestrielle est documentée. Une séparation complète entre l'utilisateur de déploiement et l'utilisateur d'exécution du service (afin qu'un processus de service compromis ne puisse pas pivoter vers le chemin de déploiement) est suivie comme un contrôle prévu sur la feuille de route de sécurité.
5. Réseau et limitation de débit de l'infrastructure
La limitation du débit est appliquée au niveau de la couche applicative par un magasin partagé Redis, de sorte que les limites sont globales pour toutes les instances serveur et non par processus. Deux compartiments configurés indépendamment s'appliquent : un compartiment strict sur les points d'entrée d'authentification (20 tentatives par IP par fenêtre de 15 minutes) et un compartiment API général (200 requêtes par IP par minute). Le limiteur est fermé en cas d'échec : si le magasin Redis est inaccessible, les points d'entrée d'authentification refusent les requêtes plutôt que de les laisser passer. Le wrapper tRPC batch-aware du limiteur est vérifié par notre vérificateur rate-limit-verify.ts (7/7 scénarios, incluant l'attaque de contournement par lot).
Le trafic en périphérie est traité par Cloudflare avec WAF, détection de bots et blocage géographique sur les chemins à haut risque. Un scaffold Terraform pour la zone Cloudflare est consigné avec un runbook opérationnel couvrant la détection de dérive, le contournement d'urgence et la règle de réconciliation à 24 heures. L'importation et la réconciliation de la zone actuellement manuelle par rapport à ce scaffold sont en cours et constituent la tâche bloquante avant la planification du premier test de pénétration externe.
6. Monitoring, journalisation et audit
La plateforme émet des journaux structurés depuis le serveur tRPC Node.js, le moteur Rust, le worker Python et la périphérie. Tous les journaux au niveau de l'hôte et du conteneur (le journal systemd, les journaux système de l'hôte, les journaux d'accès et d'erreurs nginx, les sorties standard des conteneurs CI et forge de code source, ainsi que tous les journaux applicatifs Melaya) sont transmis hors machine en temps réel vers un locataire Grafana Cloud Loki dans la même région que l'hôte de production via un collecteur Grafana Alloy, de sorte que la piste d'audit survit à une compromission de l'hôte ou à une perte de disque. Les connexions réseau sortantes sont enregistrées par une règle de journalisation des sorties au niveau réseau et transmises au même collecteur délocalisé ; ce trafic sortant est journalisé et observé aujourd'hui, tandis que l'application d'une liste d'autorisation de sorties basée sur le refus reste un élément de la feuille de route en attente.
Les événements pertinents pour la sécurité (résultats d'authentification, résultats de défis MFA, ajouts et suppressions d'identifiants CEX, émission et révocation de clés d'API de la plateforme, changements de niveau et retours en arrière) sont en outre inscrits dans une table agents.audit_log en ajout seul. Le schéma révoque UPDATE et DELETE du rôle applicatif, maintient une chaîne de hachage cryptographique sur les lignes (prev_hash / row_hash), stocke l'IP de l'acteur uniquement sous forme de condensat HMAC-SHA256 avec une clé secrète (et non un SHA-256 simple, qui est vulnérable aux attaques par dictionnaire), et fournit une table annexe agents.audit_log_tombstone pour les effacements au titre de l'article 17 du GDPR qui ne modifie jamais la chaîne. Un vérificateur quotidien (verify-audit-chain.ts) parcourt la chaîne de bout en bout, vérifie la monotonie des horodatages avec une tolérance NTP de ±2 secondes, et produit un condensat d'ancre adapté à un stockage externe en écriture seule. Six scénarios de falsification dans audit-log-verify.ts se terminent avec un code zéro contre la production en direct.
7. Gestion des vulnérabilités
Chaque commit exécute npm audit --production et un scan Trivy du système de fichiers dans le cadre du CI. Trivy est invoqué deux fois à chaque build : une fois en mode bloquant avec ignore-unfixed: true afin que les résultats exploitables fassent échouer le contrôle, et une fois avec ignore-unfixed: false et sans blocage afin que la surface de vulnérabilité complète soit téléversée dans l'onglet Sécurité du dépôt comme preuve de conformité. L'hôte de production exécute unattended-upgrades avec le canal de sécurité activé et une fenêtre de redémarrage automatique. Les images de conteneurs tiers pour les services CI, source-forge, coffre de secrets, Postgres et Redis sont soumises à validation avant les mises à jour de version, suivies dans le runbook de cadence de correction dans le coffre de sécurité interne, et surveillées par un détecteur de dérive d'empreinte d'image quotidien qui émet une alerte dans les 24 heures suivant toute rotation silencieuse d'image.
Melaya n'a pas encore fait l'objet d'un test de pénétration externe par un tiers. Le périmètre de l'engagement (incluant les actifs dans le périmètre et hors périmètre, les règles d'engagement, la liste restreinte de fournisseurs exigeant l'accréditation CREST, et la cadence de remédiation post-engagement) est consigné dans le runbook interne Pentest Scope afin que la sélection du fournisseur puisse avancer dès que la réconciliation IaC Cloudflare de la section 5 est réalisée. Aucune affirmation de "test de pénétration annuel" n'est faite dans la documentation de Melaya.
8. Développement logiciel sécurisé
Les modifications apportées à la plateforme transitent par le contrôle de source avec révision par les pairs avant la fusion. Le mode strict de TypeScript et l'analyse statique s'exécutent sur chaque build client et serveur. gitleaks s'exécute en tant que hook de pré-commit et dans le CI, avec une liste d'autorisation limitée par chemin plutôt que globale, de sorte que la divulgation accidentelle d'identifiants fait échouer le build avant la fusion. Toutes les actions CI sont épinglées par SHA de commit afin d'éviter les attaques de réécriture de tags dans la chaîne d'approvisionnement. Les déploiements en production transitent par un wrapper Jenkins SSH restreint avec une restriction command= dans authorized_keys, de sorte que même un runner CI compromis ne peut invoquer que les opérations explicites resync <service> et log <service> pour les services Melaya autorisés : pas de shell arbitraire, pas de traversée du système de fichiers, pas d'escalade de privilèges au-delà du redémarrage du service lui-même. Chaque invocation de pipeline de déploiement est journalisée hors de la machine vers le locataire Grafana Cloud Loki pour audit, accompagnée d'un enregistrement de provenance consigné reliant le binaire en cours d'exécution à son commit source.
9. Réponse aux incidents
Melaya maintient un runbook de réponse aux incidents écrit couvrant la déclaration de gravité (quatre niveaux de gravité), les attributions de rôles (Commandant d'incident, responsable technique, communications, scribe), une liste de contrôle de confinement comprenant des étapes explicites de rotation de la clé d'enveloppe, de la clé JWT et de la clé IP-HMAC du journal d'audit, la matrice de notification de 72 heures de l'article 33 du GDPR, et un modèle de post-mortem. Le runbook est consigné dans le coffre de sécurité interne et traité comme un document vivant : le premier exercice de simulation est prévu pour le 2026-07-15, et le runbook est explicitement marqué comme "non actif" dans ses propres procédures jusqu'à l'exécution de cet exercice. Les ingénieurs d'astreinte répondent aux incidents réels aujourd'hui. La porte de l'exercice concerne l'exercice de simulation formel, et non l'existence du chemin de réponse.
10. Sauvegarde et reprise après sinistre
Les objectifs de temps de récupération (RTO) et de point de récupération (RPO) par sous-système sont publiés dans le runbook interne RTO RPO : le niveau agents.* vise un RTO de 15 minutes et un RPO de 2 heures, le stockage des identifiants CEX vise un RTO de 5 minutes et un RPO de 1 heure, Infisical et le stockage d'objets visent un RTO de 4 heures et un RPO de 1 heure, et Redis est sans sauvegarde et reconstruit à la reconnexion. La mécanique de sauvegarde combine l'archivage WAL continu avec une fenêtre de récupération à un instant précis de 14 jours, un dump logique nocturne conservé dans une autre région, une sauvegarde de base mensuelle et un export quotidien d'ancre de journal d'audit en écriture seule vers un emplacement externe. Tous les artefacts de sauvegarde sont compressés, checksumés et chiffrés avec restic. La vérification de restauration s'effectue selon deux cadences : une tâche automatisée hebdomadaire effectue une vérification d'intégrité restic et une restauration ponctuelle dans un répertoire de travail temporaire, et le premier exercice de restauration complète dans un environnement jetable est prévu pour le 2026-07-15, après quoi son attestation écrite du temps de restauration réel et de la vérification d'intégrité sera consignée dans le même runbook. Melaya opère depuis une seule région d'hébergement principale aujourd'hui. Ce point est divulgué clairement, et les contrôles compensatoires (dumps nocturnes dans une autre région, archivage WAL continu, sonde de santé inter-région et basculement DNS Cloudflare) bornent le RTO de perte totale de région au pire à environ 24 heures, documenté et accepté comme risque.
11. Continuité d'activité
Un plan de continuité d'activité écrit est consigné dans le coffre de sécurité interne, couvrant la réponse à une panne de la région principale, la défaillance du fournisseur Postgres, la panne du coffre Infisical (le serveur continue de servir les sessions existantes via des identifiants mis en cache, les nouvelles écritures CEX sont refusées avec une erreur visible par l'utilisateur), la panne Stripe (les abonnements existants ne sont pas affectés), la matrice de disponibilité du personnel et un tableau de contingence par fournisseur. Le plan est révisé selon la même cadence trimestrielle que le socle TLS, avec un passage en revue complet annuel dans le cadre de l'exercice de simulation.
12. Sécurité des vendors et des sous-traitants ultérieurs
Melaya utilise des sous-traitants ultérieurs et fournisseurs d’infrastructure pour les fonctions décrites dans la liste publique des Sous-traitants. La qualité contractuelle, la localisation et la garantie de transfert de chaque fournisseur doivent être évaluées selon le déploiement et l’accord réels ; les fournisseurs de modèles, connecteurs, commerçants ou outils choisis par le client peuvent agir sur ses instructions et selon leurs propres conditions plutôt qu’en vertu des contrats fournisseurs de Melaya. Les clients entreprise bénéficient des droits de notification et d’opposition applicables selon leur accord ou avenant de traitement des données. L’environnement hébergé principal de Melaya est actuellement exploité à Singapour, qui ne bénéficie pas d’une décision d’adéquation de l’Union européenne ; les transferts applicables exigent donc un mécanisme licite et des garanties supplémentaires lorsque requis. Un environnement local exécute Python, les fichiers locaux, les opérations de récupération et certains identifiants sur le matériel contrôlé par le client, mais la configuration de l’exécution, le contenu signé envoyé, la livraison d’identifiants sélectionnés, les événements de collaboration, la télémétrie, les demandes aux modèles cloud ou les appels de connecteurs peuvent encore passer par Melaya ou atteindre Melaya et des tiers selon le mode choisi. La page publique des Sous-traitants, l’accord client et le flux réel - et non le seul terme « local » - déterminent les divulgations relatives aux destinataires et à la résidence.
13. Posture de conformité
Melaya construit ses contrôles en tenant compte des critères de services de confiance SOC 2 et de la norme ISO/IEC 27001. A la date du présent document, Melaya ne détient PAS le SOC 2 Type I, le SOC 2 Type II, l'ISO/IEC 27001, ni aucune autre attestation de sécurité tierce équivalente, et aucune évaluation par un organisme d'audit ou de certification n'a été réalisée. Il s'agit de jalons aspirationnels sur notre feuille de route. Tout client potentiel exigeant une attestation aujourd'hui doit s'attendre à recevoir une analyse d'écart plutôt qu'un rapport achevé. Les clients entreprise peuvent demander notre matrice de contrôle actuelle et la liste des remédiations en cours en contactant [email protected].
Un modèle de Data Processing Addendum en quinze sections a été rédigé et commit dans le coffre interne de sécurité. Il intègre les Clauses contractuelles types de la Commission européenne (Module 2 pour controller-to-processor et Module 3 pour processor-to-processor), l'UK International Data Transfer Addendum et l'équivalent suisse FADP. L'engagement de notification de violation à 72 heures de l'Article 33 RGPD, la procédure de restitution ou de suppression et les droits d'audit (limités aux SOC 2 Type II annuels et sous NDA lorsque cela atterrit) sont tous liés dans le modèle. La revue par un conseil externe est en attente avant que le DPA ne soit proposé en acceptation par clic aux paliers payants et en version signable bilatéralement au palier citadel.
14. Responsabilités des clients
La sécurité sur Melaya est partagée. Les clients sont responsables de choisir des mots de passe forts et uniques, de protéger leurs identifiants de compte, de scoper les clés API d'échange aux autorisations minimales requises, de revoir et de valider le comportement des pipelines qu'ils construisent, de contrôler le contenu qu'ils chargent dans les indices de récupération, de revoir les conditions et pratiques de traitement des données de tout fournisseur tiers de modèles de langage qu'ils choisissent d'y router, et de signaler rapidement toute compromission suspectée. Nous recommandons fortement d'activer la two-factor authentication dans les paramètres de compte dès la première connexion ; elle est requise avant qu'un credential CEX puisse être ajouté ou qu'une clé API plateforme puisse être générée, et c'est le contrôle de sécurité à plus fort impact qu'un client puisse appliquer à son propre compte.
15. Responsible Disclosure et Safe-Harbor
Safe-harbor. Melaya Labs LLC n'engagera pas et ne soutiendra aucune action en justice de tiers contre des chercheurs en sécurité agissant de bonne foi et respectant la présente politique. Cet engagement s'applique aux prétentions que Melaya pourrait par ailleurs faire valoir au titre du U.S. Computer Fraud and Abuse Act (CFAA), du U.K. Computer Misuse Act, des dispositions équivalentes des statuts de computer-misuse des États membres de l'UE, et de toutes prétentions de droit civil pour rupture de contrat, ingérence délictuelle ou intrusion dans des biens meubles. La « bonne foi » signifie que le chercheur a fait un effort sincère pour respecter le scope et les rules of engagement ci-dessous, n'a pas accédé, modifié, détruit ni exfiltré les données d'autres utilisateurs, n'a pas intentionnellement dégradé les Services pour d'autres utilisateurs, et a divulgué le finding en privé à [email protected] avant toute divulgation publique. Cette clause est contraignante pour Melaya et n'exige pas d'approbation par rapport. Elle ne couvre pas les conduites indépendamment illégales dans la juridiction du chercheur, telle qu'une fraude financière réelle envers d'autres utilisateurs, ou de l'extorsion.
Scope. Les tests sont autorisés contre melaya.org et tous les sous-domaines de la zone *.melaya.org, la surface applicative à app.melaya.org, les endpoints Builder API et les pages légales publiées par Melaya. Les tests ne sont PAS autorisés contre : (i) le placement, l'annulation ou la modification d'ordres en direct sur toute plateforme d'échange tierce atteinte via Melaya ; (ii) les fournisseurs tiers de modèles de langage (OpenAI, Anthropic, Google, Cohere, runtimes locaux) atteints via un pipeline configuré par l'utilisateur ; (iii) l'infrastructure de Cloudflare, de l'hébergeur ou du fournisseur de coffre-fort eux-mêmes ; (iv) toute forme d'attaque par déni de service (flood L3/L4, flood L7, credential stuffing en volume) ; (v) social engineering des employés, sous-traitants ou clients de Melaya ; (vi) intrusion physique.
Rules of engagement. Les chercheurs doivent cesser les tests dès qu'un finding est démontré (une seule lecture non destructive suffit comme preuve d'accès inter-tenant), ne doivent jamais modifier ni exfiltrer les données d'autres utilisateurs, ne doivent pas installer de persistance, et doivent maintenir les tests automatisés sous 1 requête par seconde en soutenu. Le trafic de test doit porter un header distinct User-Agent: Melaya-research/<handle> afin que Melaya puisse le distinguer du trafic réel et ne pas paginer l'astreinte à son sujet.
SLA de triage. Melaya s'engage à accuser réception des rapports valides dans un délai de cinq (5) jours ouvrables suivant la réception, à fournir une évaluation initiale de la gravité dans un délai de dix (10) jours ouvrables suivant l'accusé de réception, et à remédier aux constats selon l'échelle de gravité : Critique dans les 48 heures, Haute dans les 7 jours calendaires, Moyenne dans les 30 jours calendaires, Faible dans les 90 jours calendaires. Si Melaya ne respecte pas un engagement de SLA, le chercheur peut fournir un préavis écrit de sept (7) jours d'intention de publication, et la protection de la clause de refuge reste en vigueur pendant la publication, sous réserve que le chercheur ait respecté les règles d'engagement tout au long du processus.
Contact. Les rapports doivent être envoyés à [email protected]. Une clé PGP pour les rapports chiffrés sera publiée à /.well-known/security.txt. Les rapports ne doivent pas être envoyés via les réseaux sociaux, les issues GitHub des dépôts publics de Melaya, ni via aucune surface de chat de support : ces canaux ne sont pas monitorés pour le contenu security-sensitive et créent un risque de divulgation publique accidentelle avant remédiation.
La présente section 15 est autosuffisante et ses engagements sont contraignants. Le safe-harbor du premier paragraphe, le scope et les rules of engagement des deuxième et troisième paragraphes, le triage SLA du quatrième paragraphe, AINSI QUE les règles d'interaction avec les Conditions d'utilisation et de modification uniquement prospective du paragraphe immédiatement suivant constituent ensemble l'ensemble complet des engagements contraignants pour Melaya à l'égard des chercheurs en sécurité. Chaque paragraphe de cette section 15, pas seulement les quatre premiers, fait partie de l'ensemble d'engagements contraignants. Melaya maintient un runbook opérationnel interne pour le routage et l'escalation du triage, mais ce runbook n'ajoute, ne soustrait ni ne modifie aucun des engagements de la présente section 15, et un chercheur n'a pas besoin de lire un autre document pour s'appuyer sur le safe-harbor ci-dessus. Toute modification de la présente section 15 ne s'applique que prospectivement : un finding rapporté de bonne foi sous la version de la présente section 15 en vigueur au moment du rapport reste protégé par le safe-harbor de cette version, indépendamment de tout amendement ultérieur.
Interaction avec les Conditions d'utilisation (contraignant). La présente section 15 constitue l'autorisation expresse de Melaya pour l'activité de recherche en sécurité qui serait autrement restreinte par les interdictions des Conditions d'utilisation contre le contournement, la désactivation ou l'interférence avec les fonctionnalités de sécurité, de limitation de débiting ou de contrôle d'accès de Melaya. Un chercheur agissant dans le scope et les rules of engagement ci-dessus n'est donc pas en violation des Conditions pour cette conduite, et Melaya renonce à toute prétention qu'il pourrait par ailleurs faire valoir au titre des Conditions à l'égard de cette conduite spécifique. Le présent paragraphe fait lui-même partie de l'ensemble d'engagements contraignants ci-dessus et n'est pas un simple texte interprétatif.
Modèle de sécurité de Device Control
Device Control est conçu comme un canal autorisé par l’utilisateur et refusé par défaut. L’application Android ne peut activer seule l’Accessibilité ou la capture d’écran ; l’utilisateur doit accorder ces autorisations dans le système. Android peut exiger l’approbation des paramètres restreints pour les versions installées hors boutique.
Les téléphones associés s’authentifient au moyen d’un jeton révocable stocké sous forme de condensat côté serveur. Ces jetons sont limités aux points de terminaison téléphoniques, distincts des sessions de navigateur et jetons d’environnement d’exécution, et révocables depuis le compte.
L’accès aux applications est contrôlé par une liste d’autorisation. Le serveur conserve les paquets approuvés ; le téléphone synchronise cette politique et vérifie l’application au premier plan avant la lecture de l’arborescence, l’éligibilité de capture, les appuis, saisies, balayages et autres actions limitées.
Les images en direct utilisent un relais de dernière image pour la visualisation en temps réel. Elles ne servent pas d’identifiants généraux du compte et ne sont associées qu’au canal de l’utilisateur propriétaire. Les agents ne doivent demander des captures que lorsque les données d’accessibilité structurées sont insuffisantes.
Les exécutions mobiles natives enregistrent une exécution active pour le téléphone de l’utilisateur. La commande d’arrêt de la superposition ne peut interrompre que cette exécution pour le même utilisateur, et non des pipelines arbitraires. Les états terminaux et d’intervention humaine renvoient l’utilisateur vers Melaya afin que le contrôle reste visible.
Contrôles relatifs aux Agents mobiles et à l’exécution sur appareil
La sécurité des Agents mobiles sépare décision, autorisation, acheminement et exécution physique. Un modèle ou agent peut proposer une commande ; les services Melaya valident l’utilisateur authentifié, l’état du téléphone associé, la politique d’action et l’enveloppe de commande ; le premier téléphone admissible qui interroge la file peut réclamer une tâche mise en file au niveau de l’utilisateur ; puis l’appareil enregistré et contrôlé par l’utilisateur exécute la commande conformément aux autorisations du système.
Les identifiants d’appareil sont distincts des sessions de navigateur, identités de service cloud, identifiants des fournisseurs et jetons des environnements locaux. Le serveur stocke un condensat SHA-256 du jeton de téléphone révocable. Android stocke actuellement le jeton brut dans des SharedPreferences privées, tandis qu’iOS le stocke dans le Trousseau. Un jeton de téléphone n’autorise ni l’administration générale du compte, ni les points de terminaison du téléphone d’un autre utilisateur, ni un environnement sans rapport.
Les commandes sont refusées par défaut et limitées à l’utilisateur authentifié, la tâche réclamée, la politique d’application, le type d’action, les paramètres et la durée de vie de la file. La file et la liste d’autorisation sont actuellement limitées à l’utilisateur et ne sont pas adressées de manière déterministe à un appareil sélectionné lorsque plusieurs téléphones sont associés ; après réclamation, des contrôles de propriété lient le résultat. Les points de terminaison sensibles authentifient les appelants, valident les tailles et la propriété et rejettent les tâches expirées ; les clients ne doivent associer que des appareils de confiance.
Les actions à fort impact ou ambiguës doivent exiger une nouvelle confirmation humaine, des informations claires sur leur cible et leurs conséquences et une possibilité de suspension ou d’arrêt. Les indicateurs persistants, superpositions, notifications de service au premier plan, aperçus, délais, limites de débit, journaux d’audit et nettoyages d’état terminal assurent une défense en profondeur sans garantir qu’une action soit correcte ou réversible.
Les canaux de commande et de télémétrie utilisent un transport chiffré et des identités authentifiées. La signature ou protection d’intégrité des envois, valeurs à usage unique, identifiants de commande, expiration, association à l’appareil et détection des répétitions sont utilisés lorsqu’ils sont mis en œuvre pour réduire l’altération et l’exécution entre utilisateurs. Le chiffrement du transport n’empêche pas un point autorisé de voir le texte en clair nécessaire à l’exécution.
Les environnements locaux conservent l’exécution Python, les fichiers locaux et l’inférence locale dans l’environnement de l’utilisateur, sous réserve des contrôles de son système. Les exécutions hybrides exposent en outre les charges utiles d’inférence ou d’outils aux fournisseurs cloud sélectionnés. Les exécutions cloud ont lieu dans l’infrastructure gérée par Melaya et peuvent traiter les données d’exécution et certains secrets. Le cloisonnement et l’isolation réduisent sans éliminer les risques liés aux applications, dépendances, modèles, injections d’invites ou infrastructures.
Les identifiants stockés utilisent le chiffrement ou des contrôles de gestion des secrets et ne sont transmis que lorsqu’ils sont sélectionnés. Le processus d’exécution et le fournisseur externe reçoivent nécessairement des éléments d’authentification utilisables. Les utilisateurs doivent appliquer le moindre privilège, séparer les identifiants de production et de test, les renouveler et révoquer rapidement, limiter les autorisations des fournisseurs et ne jamais placer de secrets dans des invites, captures, journaux ou sorties d’outils non fiables.
Les services de télémétrie et collaboration peuvent recevoir tout message, trace, événement d’outil, résultat, coût, état, demande d’approbation, capture d’écran ou charge de diagnostic émis. Les clients doivent configurer le niveau de détail et la conservation, éviter les données sensibles inutiles et appliquer les contrôles d’accès à l’espace de travail et au projet. « Local » décrit le lieu d’exécution et ne garantit pas l’absence de télémétrie transmise.
L’Accessibilité Android et MediaProjection sont des capacités sensibles accordées par l’utilisateur. L’application doit fournir l’information mise en évidence et recueillir le consentement positif requis avant l’accès, employer l’API la plus limitée, rester visible lorsque requis, fonctionner de manière dégradée en cas de refus et ne jamais contourner la sécurité ou dissimuler l’activité. Une version Google Play ne doit pas permettre à l’Accessibilité de lancer, planifier et exécuter des actions de manière autonome contrairement aux règles de Google Play.
L’application iOS de l’App Store est limitée par le bac à sable, les droits et les API publiques d’Apple et n’offre pas de contrôle illimité d’applications tierces. Les parcours utilisant un environnement Mac, le Mode développeur, XCTest, WebDriverAgent, un appareil associé ou des tests signés présentent un modèle de menace et de confiance différent et exigent le contrôle du Mac, de l’identité de signature, de l’association, de la cible de test et du canal réseau.
Aucun contrôle n’élimine tout risque. Les modèles peuvent être manipulés par des invites ou le contenu d’un écran ; les applications peuvent modifier leur agencement ; les autorisations être excessives ; les dépendances être compromises ; les appareils être perdus ; et des utilisateurs autorisés détourner les capacités. Nous enquêtons sur les signalements crédibles, pouvons révoquer ou isoler les identifiants ou appareils concernés et recommandons d’utiliser immédiatement les procédures d’arrêt, révocation, renouvellement et signalement d’incident.
16. Modifications de cet Aperçu
Melaya peut mettre à jour cet aperçu de sécurité de temps à autre pour refléter les modifications apportées à la plateforme, à ses contrôles ou à ses sous-traitants. La date de "Dernière mise à jour" figurant en haut de ce document reflète la révision la plus récente. Lorsque les éléments en attente d'exécution (tels que le premier exercice de restauration, le premier exercice de simulation de réponse aux incidents, le premier test de pénétration externe, le chiffrement des disques au niveau des volumes, ou la révision par un conseil externe du modèle d'avenant de traitement des données) sont achevés, la section correspondante est réécrite pour refléter le nouvel état et le changement est annoncé dans le journal des modifications du produit.
17. Contact
Pour les questions de sécurité, les rapports de vulnérabilité ou pour demander de la documentation de conformité, contactez :