Il est temps d’auditer votre code, car il semble que certaines fonctionnalités sans/faible code utilisées dans les applications iOS ou Android peuvent ne pas être aussi sécurisées que vous le pensiez. C’est le gros point à retenir d’un rapport expliquant que des logiciels russes déguisés sont utilisés dans des applications de l’armée américaine, du CDC, du parti travailliste britannique et d’autres entités.

Quand Washington devient la Sibérie

Le problème est que le code développé par une société appelée Pushwoosh a été déployé dans des milliers d’applications à partir de milliers d’entités. Ceux-ci incluent les Centers for Disease Control and Prevention (CDC), qui affirment avoir été amenés à croire Pushwoosh était basé à Washington alors que le développeur est en fait basé en Sibérie, Reuters explique. Une visite au Flux Twitter de Pushwoosh montre la société prétendant être basée à Washington, DC.

La société fournit un support de traitement de code et de données qui peut être utilisé dans les applications pour profiler ce que les utilisateurs d’applications de smartphone font en ligne et envoyer des notifications personnalisées. CleverTap, Braze, One Signal et Firebase proposent des services similaires. Maintenant, pour être juste, Reuters n’a aucune preuve que les données collectées par l’entreprise ont été abusées. Mais le fait que l’entreprise soit basée en Russie est problématique, car les informations sont soumises à la législation locale sur les données, ce qui pourrait poser un risque pour la sécurité.

Ce n’est peut-être pas le cas, bien sûr, mais il est peu probable qu’un développeur impliqué dans le traitement de données pouvant être considérées comme sensibles veuille prendre ce risque.

Quel est l’arrière-plan ?

Bien qu’il y ait de nombreuses raisons de se méfier de la Russie en ce moment, je suis certain que chaque pays a ses propres développeurs de composants tiers qui peuvent ou non donner la priorité à la sécurité des utilisateurs. Le défi est de savoir lesquels le font et ceux qui ne le font pas.

La raison pour laquelle un tel code de Pushwoosh est utilisé dans les applications est simple : il s’agit d’argent et de temps de développement. Le développement d’applications mobiles peut coûter cher, donc pour réduire les coûts de développement, certaines applications utiliseront du code standard de tiers pour certaines tâches. Cela réduit les coûts et, étant donné que nous nous dirigeons assez rapidement vers des environnements de développement sans code/à faible code, nous allons voir davantage ce type d’approche de modélisation en briques pour le développement d’applications.

C’est bien, car le code modulaire peut offrir d’énormes avantages aux applications, aux développeurs et aux entreprises, mais il met en évidence un problème que toute entreprise utilisant du code tiers doit examiner.

A qui appartient votre code ?

Dans quelle mesure le code est-il sécurisé ? Quelles données sont collectées à l’aide du code, où vont ces informations et quel pouvoir l’utilisateur final (ou l’entreprise dont le nom figure sur l’application) possède-t-il pour protéger, supprimer ou gérer ces données ?

Il existe d’autres défis : lors de l’utilisation d’un tel code, est-il mis à jour régulièrement ? Le code lui-même reste-t-il sécurisé ? Quelle profondeur de rigueur est appliquée lors des tests du logiciel ? Le code intègre-t-il un code de suivi de script non divulgué ? Quel cryptage est utilisé et où les données sont-elles stockées ?

Le problème est que si la réponse à l’une de ces questions est « ne sait pas » ou « aucune », les données sont à risque. Cela souligne la nécessité d’évaluations de sécurité robustes autour de l’utilisation de tout code de composant modulaire.

Les équipes de conformité des données doivent tester ces éléments de manière rigoureuse – les tests « minimum » ne suffisent pas.

Je dirais également qu’une approche dans laquelle toutes les données recueillies sont rendues anonymes a beaucoup de sens. De cette façon, en cas de fuite d’informations, le risque d’abus est minimisé. (Le danger des technologies personnalisées qui manquent de protection robuste des informations au milieu de l’échange est que ces données, une fois collectées, deviennent un risque pour la sécurité.)

Les implications de Cambridge Analytica illustrent sûrement pourquoi l’obscurcissement est une nécessité à une époque connectée ?

Pomme semble certainement comprendre ce risque. Pushwoosh est utilisé dans environ 8 000 applications iOS et Android. Il est important de noter que le développeur affirme que les données qu’il recueille ne sont pas stockées en Russie, mais cela ne les protège peut-être pas de l’exfiltration, expliquent des experts cités par Reuters.

Dans un sens, cela n’a pas beaucoup d’importance, car la sécurité est basée sur l’anticipation des risques, plutôt que sur attendre que le danger se produise. Étant donné le grand nombre d’entreprises qui font faillite après avoir été piratées, il vaut mieux prévenir que guérir en matière de politique de sécurité.

C’est pourquoi chaque entreprise dont les équipes de développement s’appuient sur du code prêt à l’emploi doit s’assurer que le code tiers est compatible avec la politique de sécurité de l’entreprise. Parce que c’est votre code, avec le nom de votre entreprise dessus, et tout abus de ces données en raison de tests de conformité insuffisants sera votre problème.

Merci de me suivre sur Twitterou rejoignez-moi dans le Le bar-grill d’AppleHolic et Discussions Apple groupes sur MeWe. Aussi, maintenant sur Mastodonte.