Une enquête d’OCCRP publiée fin juillet révèle qu’un gestionnaire de mots de passe présenté comme entièrement européen partage un codebase, des cycles de mise à jour et une documentation quasi identique avec un produit russe certifié par le Ministère de la Défense et le FSB. Au-delà du cas Passwork, l’affaire pose une question que peu d’organisations savent encore trancher correctement : comment vérifier qu’un éditeur logiciel est réellement ce qu’il prétend être
Une frontière technique plus fine que la frontière commerciale
Une société enregistrée en Espagne, Passwork Europe SL, revendique une identité entièrement européenne et des serveurs hébergés sur le continent. Son produit trouve pourtant son origine dans une entreprise russe fondée à Arkhangelsk en 2014, dont les fondateurs restent aujourd’hui liés à une structure basée aux Émirats arabes unis chargée de livrer les mises à jour du logiciel.
Selon les éléments recueillis par OCCRP, les deux versions, russe et européenne, partagent une origine de code commune et publient des mises à jour à quelques jours d’intervalle, avec des descriptions de fonctionnalités quasiment identiques. Le PDG de Passwork Europe reconnaît cette origine partagée sans y voir un problème, tout en assurant qu’aucune infrastructure, aucun accès administratif et aucune donnée client ne sont mutualisés avec l’entité russe.
Ce n’est pas la nationalité des fondateurs qui inquiète les experts en cybersécurité consultés dans l’enquête, mais le mécanisme même de certification du produit russe. Pour obtenir l’agrément du FSTEC, l’organisme technique rattaché au ministère de la Défense russe, un éditeur doit soumettre son code source à un audit destiné notamment à identifier d’éventuelles vulnérabilités ou fonctionnalités non déclarées. Un tel processus, mené par des laboratoires accrédités par l’État russe, peut donner à des acteurs étatiques une connaissance fine des faiblesses potentielles d’un logiciel, y compris lorsque ce logiciel circule ensuite sous une autre marque, dans une autre juridiction.
Reconstruire un audit fournisseur qui tienne la route
C’est précisément ce type de dépendance que NIS2 pousse les organisations à cartographier, sous peine de découvrir le problème au moment d’un incident plutôt qu’en amont. Vérifier l’origine effective d’un logiciel suppose de remonter au-delà du siège social affiché, jusqu’à l’historique des dépôts de code, des marques et des changements de structure juridique de l’éditeur.
Le mécanisme de mise à jour mérite une attention particulière, puisqu’il constitue historiquement l’un des vecteurs d’attaque les plus difficiles à détecter, comme l’a montré l’affaire SolarWinds. Savoir qui développe, qui teste et qui valide chaque version avant son déploiement, et si ce processus passe par une entité tierce dont la gouvernance reste opaque, devrait figurer parmi les clauses non négociables d’un contrat avec un éditeur de solution de sécurité. Le droit d’audit du code source, souvent promis dans la documentation commerciale, gagne également à être formalisé contractuellement plutôt que laissé à l’état de déclaration d’intention, avec des modalités précises sur qui peut l’exercer et dans quel délai.
L’existence de certifications obtenues par un produit apparenté dans un pays tiers, en particulier lorsque ce pays impose par ailleurs à ses entreprises une obligation légale de coopération avec ses services de renseignement, constitue en soi un signal à intégrer dans l’analyse de risque, indépendamment de toute preuve de compromission avérée.
