Un startup de santé peut passer des mois à concevoir un flux de travail mobile sécurisé, puis découvrir que le téléphone d'un testeur jailbreaké a exposé les dossiers patients à travers les captures d'écran et les caches locaux. En même temps, une version de débogage du panneau d'administration de l'équipe Electron pourrait expédier avec une clé API intégrée dans son bundle. Les deux incidents impliquent le chiffrement, mais aucun n'est résolu en ajoutant une bibliothèque de chiffrement.
Le chiffrement d'application est un système de décisions. Les équipes doivent décider de la protection des données stockées, de la manière dont elles se déplacent entre les systèmes, où les clés vivent, ce que l'attaquant peut apprendre de l'emballage de l'application, de la manière dont le runtime répond à la manipulation, et de la manière dont les mises à jour signées préservent ces garanties. Un point de départ utile est un évaluation des risques d'application qui cartographie les données sensibles, les limites de confiance, les capacités du client et les chemins d'abus probables.
Les applications mobiles et cross-plateformes font face à un environnement particulièrement exposé. Les appareils quittent le bureau, les builds peuvent être copiés ou installés par le côté, les fichiers locaux peuvent être inspectés et les outils de reverse-engineering sont largement disponibles. Les sections ci-dessous construisent le modèl’étape par étape, du stockage et du transport à la protection des clés de plateforme, la sécrétion côté client, la conformité et les opérations de mise en production.
Table des Matières
- Pourquoi la cryptage des applications compte plus que jamais
- Le Chiffrement en Place de Repos Versus en Transit
- Protéger Code, les données et les secrets dans l'application
- Considérations de plateforme pour iOS, Android, Capacitor, et Electron
- Gestion des clés et les limites de la confidentialité côté client
- Implications réglementaires et de conformité
- Pièges courants et meilleures pratiques renforcées
- Intégrer tout cela dans votre plan d'encryption
Pourquoi l'encryption des applications compte plus que jamais
Une application web garde généralement beaucoup de sa logique sensible et de ses matériaux secrets sur des infrastructures que l'organisation contrôle. Une application mobile envoie code, actifs, configuration et logique de gestion des données sur un appareil qui appartient à quelqu'un d'autre. Une application Electron a un problème similaire, car son JavaScript, ses ressources et ses fichiers empaquetés peuvent être inspectés par un utilisateur qui peut exécuter l'application.
Cela change la limite de sécurité. Le client est utile, mais ce n'est pas un coffre-fort. La protection de l'information peut empêcher une inspection occasionnelle et rendre les fichiers volés moins utiles, mais l'application a toujours besoin d'accéder au texte brut à un moment donné. Un attaquant qui contrôle le dispositif peut observer les entrées, inspecter la mémoire, instrumenter les API ou modifier l'exécution.
Considérez l'exemple de la santé. La mise en cryptage d'une base de données peut protéger les dossiers copiés du disque, mais elle ne stoppera pas un runtime compromis de afficher les enregistrements décryptés à un processus malveillant. La protection du trafic réseau peut protéger la demande d'un clinicien pendant qu'elle voyage vers l'arrière-plan, mais elle ne protégera pas une exportation locale après que l'application l'a enregistrée dans une cache non protégée. Une clé cachée dans le JavaScript minifié reste récupérable si l'application doit l'utiliser.
Règle pratique : Traitez chaque protection côté-client comme une couche qui réduit l'exposition, et non comme une preuve que le dispositif est fiable.
Un design complet combine généralement :
- Protection au repospour les bases de données, les fichiers, les caches, les préférences et les documents téléchargés.
- Protection en transitpour les demandes, la synchronisation, la livraison d'actualisations et la communication service à service.
- Stockage de clés de plateformeAinsi, les clés d'encryption ne sont pas laissées dans des fichiers d'application ordinaires.
- Code et protections de runtimey compris l'obfuscation, les vérifications d'intégrité, les mesures anti-débogage et la validation des certificats appropriés.
- Un canal de mise à jour contrôléPuisque la version signée doit conserver les hypothèses de sécurité intégrées dans les versions précédentes.
- Des contrôles de conformité documentésy compris la propriété, la preuve, le suivi et les procédures de réponse.
Les obligations réglementaires ajoutent de la pression, mais elles améliorent également la discipline d'ingénierie. Le RGPD, le HIPAA, le PCI DSS et le SOC 2 n'ont pas transformé l'encryption en un case à cocher universel. Ils exigent des équipes de comprendre ce qu'elles protègent, comment les clés sont contrôlées et comment elles peuvent démontrer que les mesures de sécurité fonctionnent comme prévu.
Chiffrement en Réserve Versus en Transit
Imaginez un document confidentiel envoyé par courrier recommandé. L'enveloppe scellée protège le message pendant qu'il voyage entre les personnes. Une fois le destinataire l'a ouvert, le document nécessite encore un tiroir fermé. La protection en transit sécurise les mouvements. La protection au repos sécurise les stockages. L'enveloppe et le tiroir résolvent des problèmes différents.
L'encryption en cours de stockage
L'encryption en cours de stockage s'applique lorsque les données sont en attente sur un appareil, un disque de serveur, un sauvegarde, une base de données ou un volume amovible. Sur les plateformes mobiles, les protections du système d'exploitation peuvent chiffrer automatiquement certaines parties de l'appareil, mais votre application doit encore choisir des emplacements de stockage sûrs, des contrôles d'accès et des clés utilisées. Les fichiers d'application sensibles doivent utiliser la cryptographie et les clés prises en charge par la plateforme et stockées dans des magasins protégés plutôt que d'utiliser une clé écrite à côté des données chiffrées.
L'authentification chiffrée compte ici. OWASP recommande les API cryptographiques de plateforme, le stockage de clés basé sur matériel où disponible, et les modes authentifiés comme AES-GCM ou AES-CCMqui aident à détecter toute tentative de manipulation ainsi qu'à cacher le contenu. La même recommandation suggère de protéger les données sensibles à la fois en repos et en transit, de placer les données privées dans un stockage interne, et d'éviter les algorithmes cryptographiques propriétaires au profit des implémentations de plateforme (Le guide de sécurité des applications mobiles de OWASP).
Les détails pratiques diffèrent d'une plateforme à l'autre. iOS fournit des services de protection des données et de clés. Android fournit des options et des bibliothèques basées sur le Keystore qui peuvent aider à gérer des fichiers chiffrés. Les applications de bureau dépendent davantage des informations d'identification du système d'exploitation et des contrôles d'accès locaux. Les équipes travaillant avec des fichiers dans un environnement Chromium Embedded Framework peuvent également examiner les meilleures pratiques pour le stockage de documents CEF pour examiner les limites de stockage au-delà du chiffrement lui-même.
La protection en transit
In-transit encryption protects requests and responses as they cross networks. A properly configured TLS connection helps prevent an intermediary from reading or modifying application traffic, but TLS only works when the client validates the server correctly and the backend presents a trusted certificate. A disabled certificate check, unsafe fallback, or accidental cleartext endpoint can undermine the intended protection.
La mise en œuvre de la certification peut ajouter une autre couche de vérification dans certaines scénarios mobiles sélectionnés, notamment lorsque l'équipe contrôle les opérations de certification et a un plan de reprise pour la rotation. Il ne s'agit pas d'une remplacement correcte du TLS, et une mauvaise pin peut bloquer les utilisateurs légitimes. Les équipes construisant avec Capacitor peuvent examiner La sécurisation SSL pour les applications Capacitor avant de déterminer si les compromis opérationnels conviennent à leur application.
Les modes de panne sont complémentaires. La sécurité de transport ne protégera pas une base de données copiée d'un appareil perdu. L'encryption de stockage ne protégera pas un mot de passe soumis à travers une connexion compromis. Conceptionnez les deux chemins, puis testez les points où le texte clair apparaît, y compris les journaux, les captures d'écran, les fichiers temporaires, les rapports de panne, le contenu de la zone de transfert, et les files d'attente de synchronisation.
Protégez Code, les Données et les Secrets dans l'Application
Les équipes utilisent souvent les mots « encryption », « obfuscation » et « hardening » comme s'ils décrivaient le même contrôle. Ce n'est pas le cas. Chacun d'entre eux s'adresse à une action d'attaquant différente, et les confondre crée une confiance fausse.
Obfuscation et minification rendez code plus difficile à lire. Ils peuvent augmenter le coût de la copie d'une application ou de la compréhension de la logique métier, mais ils n'empêchent pas un secret d'être inaccessible à une application qui doit l'utiliser. Une clé API dans un bundle JavaScript, un certificat de signature dans un archive, ou une valeur reconstruite par une fonction prévisible peuvent toujours être extraites. Le bytecode Hermes et Electron asar Les archives peuvent être moins faciles à inspecter que les fichiers source, mais le packaging n'est pas la même chose que la confidentialité.
La cryptage des données protège le contenu des utilisateurs et les informations de connexion locales pendant qu'elles sont stockées. Il devrait utiliser les API cryptographiques de la plateforme et les clés stockées dans Keychain, Keystore, Secure Enclave, StrongBox, ou un équivalent de la facilité de système d'exploitation où disponible. La guidance de test de cryptographie d'OWASP avertit contre la mise en place de mots de passe ou de clés dans les fichiers source code et met en évidence que les secrets restant sur le client peuvent être extraits (Test de cryptographie OWASP MASTG).
Les protections en temps d'exécution recherchent les conditions qui augmentent la probabilité de manipulation ou d'abus automatisé. Les signaux de jailbreak et de root, la détection de débogueur, les vérifications d'intégrité de l'application, l'attestation et la validation de certificat peuvent rendre les attaques plus difficiles ou fournir un signal de réponse. Aucune ne rend un appareil fiable. Un attaquant déterminé peut modifier les vérifications, et un utilisateur légitime peut déclencher un heuristique.
| Le couche de protection | Ce qu'il sécurise | Ce qu'il ne peut pas arrêter |
|---|---|---|
| l'obfuscation de Code | Lisibilité et clonage nonchalant de la logique de l'application | Extraction de secrets auxquels l'application peut accéder |
| Chiffrement des données | Confidentialité et intégrité des données stockées sélectionnées | Exposition au texte brut après décryptage légitime |
| Protections en temps de cours | Quelques manipulations, débogage et abus automatisés | Un attaquant expérimenté qui contrôle l'exécution |
Un design plus sûr garde les secrets de haute valeur sur le serveur, donne au client des crédencials étroitement ciblés, et chiffre uniquement les données locales qui nécessitent une accès hors ligne. La gestion de stockage de jetons mérite sa propre revue de durée de validité, de révocation, de comportement de rafraîchissement et de liaison de plateforme. Le guide de stockage de jetons sécurisé pour les développeurs mobiles est utile lorsqu'on transforme ces décisions en exigences d'implémentation.
Les approches naives échouent car elles protègent l'apparence de la discrétion plutôt que le cycle de vie du secret. XOR-er une valeur dans la source code, diviser une clé en plusieurs fichiers ou se fier à la minification JavaScript n'change pas le fait que l'application exécutée doit reconstruire et utiliser la valeur.
Considérations de plateforme pour iOS, Android, Capacitor, et Electron
Le même design de chiffrement se comporte différemment d'un runtime à l'autre car chaque plateforme expose des magasins de clés, des API, des limites d'isolement et des mécanismes de récupération différents. Une abstraction cross-platform peut simplifier l'application code, mais elle ne peut pas effacer ces différences.
Les plateformes mobiles natives
Sur iOS, le Keychain fournit un stockage de crédentiels protégés, tandis que Le Secure Enclave peut isoler certaines opérations de clés du processeur d'application principal. L'application doit encore sélectionner des contrôles d'accès qui correspondent à ses exigences d'usabilité, telles que si les données doivent être disponibles après l'authentification du dispositif ou uniquement lorsque l'utilisateur a été authentifié.
Le Keystore Android fournit un chemin sécurisé sur les appareils pris en charge, et StrongBox peut offrir un environnement isolé plus fort si disponible. Les équipes Android devraient également considérer les capacités du dispositif, le comportement de sauvegarde, les exigences d'authentification et les signaux d'attestation. Le support matériel n'est pas uniforme, donc l'application doit avoir une politique de fallback définie plutôt que d'assumer que chaque appareil offre une protection identique.
Les coques cross-platform
Les applications Capacitor combinent le web code avec les capacités de plateforme native à l'aide d'un pont. Ce pont est une limite de sécurité, et non simplement une couche de commodité. localStorage, IndexedDB et les préférences web ordinaires ne doivent pas être traitées par défaut comme des magasins de secrets chiffrés. Une équipe doit choisir explicitement un plugin de stockage natif ou implémenter un module natif qui utilise les installations de clés protégées de la plateforme.
Electron a un modèle de menace différent. Son processeur de rendu gère le contenu web, tandis que le processus principal a des privilèges plus larges, donc les opérations sensibles devraient rester hors d'un processeur de rendu exposé. Le processeur de rendu d'Electron safeStorage peut utiliser la protection des informations d'identification du système d'exploitation, mais la sécurité résultante dépend du système d'exploitation hôte, du compte d'utilisateur, de la configuration de bureau et de l'isolement du processus. La clé n'est pas automatiquement isolée sur le matériel de la même manière qu'une plateforme mobile peut isoler une clé protégée.
| Plateforme | Stockage de la clé | Chiffrement API | Modèle de menace par défaut |
|---|---|---|---|
| iOS | Clé de chiffrement et, si disponible, Enclave sécurisé | Cryptographie de la plateforme Apple et Protection des données | Le dispositif et l'application sont séparés, mais un dispositif compromis ou un runtime peut observer l'utilisation |
| Android | Keystore et, où supporté, StrongBox | Cryptography du plateforme Android et composants de sécurité de Jetpack | Les capacités matérielles et logicielles varient d'appareil à appareil |
| Capacitor | Stockage natif sélectionné par l'intermédiaire de plugins ou de pont personnalisé code | APIs Web plus APIs de plateforme native | Les actifs Web s'exécutent à l'intérieur d'un shell natif et n'héritent pas automatiquement d'un stockage sécurisé |
| Electron | OS facilite les crédentiels par le biais d'APIs telles que safeStorage |
APIs d'application compatibles Node et Chromium | Exposition du rendu et accès au niveau de l'hôte sont des préoccupations centrales |
Les équipes devraient documenter le comportement par cible plutôt que de décrire le produit comme « chiffré sur tous les plateformes ». approche des différences de plateforme Capacitor aide à définir le pont comme un endroit où les décisions spécifiques au plateau doivent rester visibles.
Gestion des Clés et les Limites de la Sécurité côté Client
La cryptage protège les données uniquement lorsque la gestion des clés protège les clés. Un cycle utile compte cinq étapes : génération, distribution, stockage, rotation et révocationChaque étape crée un mode d'erreur différent.
Générez des clés avec des API cryptographiques de plateforme ou de serveur fiables. Distribuez-les à l'aide d'un protocole authentifié plutôt que de les intégrer dans un ensemble. Stockez-les dans un espace de plateforme protégé lorsque possible. Effectuez une rotation lorsque les politiques, les risques ou les exigences cryptographiques le demandent. Révoquez l'accès à l'aide d'une autorisation contrôlée par le serveur lorsque le dispositif, le compte ou la session ne devrait plus déchiffrer les données.
Le client est plus faible que l'infrastructure pour ces opérations car l'utilisateur contrôle le dispositif et peut potentiellement inspecter l'état de l'application. Une clé tenue par le client peut être sensée pour les données hors ligne protégées par un mot de passe dérivé par l'utilisateur, à condition que le produit accepte les conséquences de récupération et d'utilisation. Cela fait beaucoup moins de sens pour un jeton API qui accorde un accès backend large. Si un attaquant extrait ce jeton, le cryptage autour d'une base de données locale ne limitera pas ce que le jeton peut faire à distance.
La cryptage par enveloppe sépare la clé de cryptage des données de la clé maîtresse. L'application peut chiffrer un objet local avec une clé de données à vie courte, tandis qu'un service de gestion de clés côté serveur ou un système HSM protège la clé de wrapping. Un design de libération de clés à distance peut nécessiter un appareil, un utilisateur, une décision de politique ou un signal d'attestation authentifié avant de libérer les matériaux nécessaires pour la déchiffrement. Ces modèles ne rendent pas un client compromis sûr, mais ils réduisent l'autorité qui s'installe définitivement sur le dispositif.
OWASP identifie les données sensibles locales comme incluant les informations personnelles identifiables, les matériaux cryptographiques, les secrets et les API clés. Il relie également le cryptage avec les contrôles de cycle de vie comme le stockage local sécurisé, la rotation de clés et la zérotation après utilisation. Le principe architectural est simple :
Conserve les secrets à haute valeur sur les systèmes contrôlés par l'équipe. Accordez au client uniquement l'autorité minimale requise pour sa tâche actuelle.
For release systems, key management also applies to update signing and delivery. A team should define who can sign a bundle, where signing credentials reside, how access is audited, and how a compromised signing credential is replaced. Guidance on sécurisation des mises à jour OTA avec gestion des clés Puisque cela peut aider à relier l'encryption de l'application au cycle de mise à jour.
Conséquences réglementaires et de conformité
Les équipes de conformité ne considèrent généralement pas la déclaration « l'application utilise l'encryption » comme preuve suffisante. Elles demandent quelles données sont couvertes, quels algorithmes et protocoles sont actifs, qui contrôle les clés, comment l'accès est restreint et comment l'organisation détecte les dérives de configuration.
La directive GDPR Article 32 considère l'encryption comme une mesure technique appropriée pour réduire le risque, comme le reflète le texte de l'Union européenne sur le GDPR. L'obligation est basée sur le risque, donc l'organisation doit encore relier ses mesures de sécurité à la nature des données personnelles et de l'environnement de traitement. Une application mobile qui gère des informations médicales, des données d'identité ou des dossiers financiers nécessite une explication défendable de la mise en cache locale, du transport, de l'accès et de la réponse aux incidents.
La règle de sécurité HIPAA considère l'encryption des informations de santé protégées électroniques comme un moyen de sécurité adressable plutôt qu'un case à cocher technique universel. Cela signifie qu'une entité couverte ou un associé d'affaires devrait évaluer si l'encryption est raisonnable et approprié, documenter la décision et appliquer des mesures alternatives où elle ne met pas en œuvre le moyen de sécurité. La guidance de la règle de sécurité de l'HHS fournit le contexte régissant.
Le PCI DSS sépare les données du titulaire de la carte stockées de la transmission à travers les réseaux ouverts. Les équipes devraient mapper les décisions d'encryption aux exigences applicables et éviter de stocker les données de paiement inutilement. La bibliothèque de documents de la PCI Security Standards Council est le lieu approprié pour vérifier la formulation actuelle et le champ d'application.
Les examinateurs SOC 2 se concentrent sur des preuves que les contrôles fonctionnent. Ces preuves peuvent inclure des politiques de gestion des clés, des configurations TLS, des inventaires de chiffrements, des journaux d'accès, des approbations de changement, des dossiers d'incident, des résultats de tests et des preuves que les versions signées suivent le processus prévu.
Le fil conducteur est la preuveConstruissez l'histoire de l'audit en implémentant la cryptage de l'application, et non la veille d'un audit.
Les pièges courants et les meilleures pratiques renforcées
La plupart des échecs de chiffrement commencent comme des décisions d'ingénierie ordinaires. Un développeur a besoin d'un jeton disponible lors du démarrage, un équipe veut une recherche hors ligne qui se sente rapide, ou un processus de mise à jour nécessite une façon rapide de distribuer un correctif chaud. Le risque apparaît lorsque le raccourci devient une partie permanente du modèle de confiance.
Une étude récente sur les risques mobiles a rapporté que plus de 60 % des applications évaluées utilisaient des cryptographies iniques ou obsolètes pour les données sensiblesalors que environ un tiers ont réutilisé des vecteurs d'initialisation et 20% utilise des valeurs statiques fixées par définition . Ces constats déplacent la question de « l'application crypte-t-elle ? » à « peut l'implémentation préserver la confidentialité et l'intégrité dans un usage réel ? » SC World report on mobile app risks)
| Piège commun | Pratique renforcée |
|---|---|
| Hardcodage des clés API ou des clés d'encryption dans le code source, le bytecode ou les bundles | Conservez les informations sensibles côté serveur et utilisez un stockage de plateforme protégé pour les données matérielles scoping appareil. |
| Chiffrer une base de données SQLite tout en laissant les caches, les exports, les journaux ou les sauvegardes en clair | Inventorisez toutes les copies de données sensibles et appliquez la même politique de stockage aux artefacts temporaires. |
| Stockage de jetons de renouvellement dans un stockage web ordinaire | Utiliser un stockage de plateforme de crédentials, étendre le champ d'application des jetons et supporter la révocation côté serveur |
| Écrire de la cryptographie personnalisée ou inventer une obfuscation de clé | Utilisez des API de plateforme éprouvées et des modes d'encryption authentifiés |
| Désactiver la validation des certificats pour résoudre les problèmes de connectivité | Configurez TLS correctement, puis évaluez la mise en cache avec un processus de récupération testé |
| Considérer la minification comme une protection de secret | Supprimez les secrets du client code et utilisez l'obfuscation uniquement pour augmenter le coût de reverse-engineering |
| Omitting app integrity checks and attestation signals | Vérifiez l'identité de la mise à jour où cela est approprié et utilisez les signaux pour ajuster l'accès ou déclencher une revue. |
| Permettre des mises à jour non signées ou faiblement contrôlées | Signez les artefacts de version, protégez vos clés de signature et surveillez les résultats des mises à jour. |
Un rapport de menace séparé a décrit des équipes de logiciels espions visant les comptes Signal et WhatsApp en faisant du piratage d'applications et en abusant des téléphones sous-jacents. Le même rapport citait une évaluation de menace mobile dans laquelle Les attaques de smartphones Android ont augmenté de 29 % en H1 2025 par rapport à H1 2024 (La couverture de The Register sur les rapports liés à CISALa leçon n'est pas que l'encryption a échoué. Les attaquants choisissent souvent le dispositif, le compte, la session ou le chemin d'actualisation car ces couches peuvent contourner le texte chiffré protégé.
Transformez chaque pratique renforcée en règle de mise à jour automatique. Le CI peut rejeter les modèles de secrets connus, signaler des cryptographies personnalisées code, vérifier les étapes de signature, inspecter les contenus du bundle et exiger une revue de sécurité lors de changements de paramètres de stockage ou de transport. L'objectif est de capturer une mauvaise décision avant qu'elle ne devienne une dépendance livrée.
Mettre tout en place dans votre plan d'encryption.
Un plan d'encryption doit ressembler à un contrat d'ingénierie. Il doit dire ce que l'application protège, où les clés vivent, quels composants peuvent voir du texte en clair et comment l'équipe prouve que les contrôles restent actifs après chaque mise à jour.
Commencez par la classification des données. Marquez les enregistrements, les jetons, les documents, les journaux, les caches, les sauvegardes et les champs d'analytique selon la sensibilité et les besoins de conservation. Minimisez les copies locales avant de sélectionner un algorithme. Les données qui ne parviennent jamais au dispositif n'ont pas besoin d'un design de stockage du dispositif.
Ensuite, documentez les décisions de stockage et de transport :
- Schéma de stockage à l'arrêt : Choisissez l'encryption authentifié, le stockage de clés géré par la plateforme, des emplacements de fichiers protégés, le comportement de sauvegarde, et la gestion de suppression ou de zérosage.
- Protocole de transport en cours : Définez la configuration TLS, la validation de certificat, la politique d'extrémité et si la fixation est appropriée pour le modèle de menace.
- La garde des clés : Procédures de génération, d'accès, de distribution, de rotation, de révocation, de récupération et de remplacement d'urgence.
- Code et contrôles en temps de exécution : Déterminez quelles protections de l'écran sensible, la détection de débogueur, la vérification d'intégrité, l'attestation et l'obfuscation contribuent.
- Preuves d'audit : Capturer les inventaires de configuration, les journaux d'accès, les approbations de version, les résultats de test, les enregistrements d'incident et les exceptions.
La séquence compte. La classification des données détermine ce qui doit être protégé. Cette décision façonne la garde des clés et le stockage. Les contrôles de transport et d'actualisation préserveront ensuite le chemin entre les services fiables et le client. Capacitor et les équipes d'Electron devraient répéter la revue par cible, car un coffre de clés natif iOS, une option Android sécurisée par matériel, un stockage de navigateur API et un poste de crédentials de bureau ne fournissent pas les mêmes garanties.
Le canal d'actualisation doit se trouver à l'intérieur de ce plan, et non après. Une mise à jour signée peut préserver code l'intégrité, tandis que la ciblage contrôlé, la protection de rollback et l'observabilité de la mise à jour aident l'équipe à répondre lorsque une mise à jour vulnérable ou une configuration atteint les utilisateurs. Révisez le plan chaque fois que l'application ajoute des données hors ligne, change son plugin de stockage, introduit une nouvelle permission de backend ou modifie la façon dont les mises à jour sont signées et livrées.
Capgo fournit des mises à jour signées en temps réel pour les applications CapacitorJS et Electron, avec un support de bundle chiffré pour le JavaScript code et les actifs, des canaux de mise à jour contrôlés, une protection de rollback et une observabilité des mises à jour par appareil. Capgo évaluer comment un chemin d'actualisation contrôlée peut soutenir votre plan d'encryption de l'application et de gouvernance des mises à jour.
