Une faille Zero Day dans votre application logicielle d'entreprise préférée a permis à des attaquants d'accéder à votre réseau et de compromettre des données sensibles. Les réparations coûteront très cher avant même d'arriver aux amendes réglementaires et aux poursuites judiciaires des clients – et l'application ne vous appartient même pas. Qui doit payer ?

Ce ne sera probablement pas la société qui vous a vendu le logiciel. Leurs contrats de licence d'utilisateur final (CLUF) limitent généralement leur responsabilité. La plupart d'entre nous ne les lisent pas parce qu'ils sont trop long et trop complexe.

Au cours des derniers mois, les demandes visant à changer cette situation se sont multipliées et ont atteint les plus hauts niveaux du gouvernement. En février, Jen Easterly, directrice de la Cybersecurity and Infrastructure Security Agency, explicitement appelé pour la responsabilité du fournisseur lors d'un discours à l'Université Carnegie Mellon.

Le monde en est venu à accepter les technologies dangereuses comme la règle alors qu’elles devraient être l’exception, a-t-elle déclaré. « Les fabricants de technologies doivent s’approprier les résultats en matière de sécurité pour leurs clients. »

Easterly a demandé au gouvernement de publier une législation qui empêcherait les entreprises technologiques de décliner toute responsabilité contractuelle. L'administration Biden Stratégie nationale de cybersécurité, lancé en mars dernier, a fait écho à l'appel en faveur de cette loi.

Un débat de longue date

Les gouvernements ont déjà réfléchi à ce problème. La Chambre des Lords du Royaume-Uni recommandé tenir les éditeurs de logiciels pour responsables en 2007, même après avoir entendu les arguments contre la responsabilité des développeurs de logiciels pour divers motifs.

Ces protestations portaient notamment sur la complexité des environnements logiciels modernes. De nombreux types de logiciels coexistent, a souligné le développeur, ajoutant qu'ils pouvaient interagir les uns avec les autres de manière étrange. Pouvons-nous raisonnablement nous attendre à ce qu’un éditeur de logiciels prévoie chaque cas limite d’interopérabilité ?

Une autre préoccupation était le risque d’erreur de l’utilisateur. Que se passe-t-il si un utilisateur a mal configuré le logiciel, ce qui rend celui-ci ou un composant avec lequel il interagit non sécurisé en raison d'une mauvaise interface utilisateur ? Que se passe-t-il si l'utilisateur n'a pas appliqué un correctif pour une raison légitime, comme une contrainte réglementaire ? Existe-t-il une responsabilité partielle en cas de mauvaise configuration, et comment cela pourrait-il être décidé ?

Il existe d’autres défis pour les entreprises qui tentent de se conformer aux questions de responsabilité des fournisseurs. De nombreux logiciels ne sont pas créés en vase clos ; il s'appuie sur des bibliothèques tierces – souvent publiées sous licences open source – qui peuvent contenir leurs propres problèmes de sécurité. Log4Shell, le bug de la bibliothèque de journalisation Java Log4J qui a affecté la cybersécurité de milliers d'entreprises de manière inaperçue depuis 2013, en est un excellent exemple. Qui paie si le logiciel que vous avez créé utilise un composant tiers non sécurisé ?

Votre vision du logiciel doit s'étendre au-delà de vos propres frontières, a suggéré Easterly. Elle a fait écho à l'appel de la Maison Blanche en faveur d'une nomenclature logicielle (SBOM) pour définir la provenance des logiciels assemblés.

À quoi ressemble un logiciel sécurisé ?

Tenir pour responsables les fournisseurs d'un produit complexe soulève d'autres problèmes, tels que la manière dont nous définissons même la sécurité des logiciels. Les définitions s'inscrivent dans un continuum allant de l'inadéquat – prouvant certains tests logiciels statiques de base – à l'impraticable – la vérification formelle. Ce dernier vérifie le fonctionnement du logiciel par rapport à un modèle mathématique abstrait. De tels systèmes existent, mais ils sont destinés à des applications spécialisées et impliquent beaucoup de temps de codage.

La définition la plus réaliste se situe quelque part entre les deux, avec des preuves documentées des meilleures pratiques qui intègrent la sécurité directement dans la production logicielle dès la phase de conception. Cadre de développement de logiciels sécurisé du NIST, recommandé par le NCS, en énonce bon nombre.

Une autre recommandation d'Easterly était l'utilisation de langages sécurisés pour la mémoire. De nombreuses failles de sécurité des logiciels modernes trouvent leur origine dans une mauvaise utilisation de la mémoire. En tant que langages rapides et de bas niveau qui obligent les programmeurs à gérer eux-mêmes la mémoire, le C et le C++ sont ici particulièrement faibles. Go, Python et Java sont des langages interprétés de niveau supérieur qui gèrent la mémoire au nom du programmeur. Un langage plus récent, Rust de Mozilla, est également sécurisé en mémoire – et est le premier langage autre que C et Assembly à être pris en charge dans le noyau Linux.

Easterly a également appelé à des politiques transparentes de divulgation des vulnérabilités parmi les éditeurs de logiciels. Trop souvent, ils font de leur mieux pour garder les bugs de sécurité discrets, ignorant ou parfois décourageant les rapports de bugs de sécurité. Elle a déclaré qu’une relation plus ouverte et collaborative avec les chercheurs en cybersécurité contribuerait à combler les lacunes logicielles.

Étapes intermédiaires

En attendant le Congrès, la Maison Blanche s'appuie sur le Décret exécutif sur l'amélioration de la cybersécurité de la nation, maintenant âgé de plus de deux ans, pour pousser les fournisseurs dans la bonne direction. Le Bureau Ovale ne peut pas punir directement les entreprises qui créent du code minable, mais l'EO interdit aux agences fédérales de le leur acheter.

Nous pouvons également nous tourner vers la standardisation pour obtenir des réponses. La norme ISO 27001:2022 mise à jour comprend Annexe A Contrôle 8.28, qui définit des principes de conception et de développement sécurisés pour les logiciels développés en interne et la réutilisation de code externe. Alors que de nombreuses entreprises comptent sur cette accréditation comme différenciateur clé, l'ajout de ce contrôle crée une pression supplémentaire pour améliorer et documenter la sécurité des logiciels.

Changer les marées politiques

Même si la responsabilité des fournisseurs est un sujet délicat, le Congrès n'a pas hésité à recourir à la législation pour s'attaquer à des problèmes technologiques complexes dans le passé. L’intérêt des entreprises joue un rôle important dans leur réticence à s’attaquer à ce problème particulier, motivée par une industrie du logiciel dotée d’un grand pouvoir de lobbying.

Néanmoins, de plus en plus de personnes ont pour mission de demander des comptes à une industrie extrêmement compétitive. Facebook a peut-être officiellement abandonné son ancien slogan interne, « Agir vite et casser les choses », mais il s'agit toujours d'un modèle opérationnel de facto pour les entreprises technologiques qui s'empressent d'innover. Alors que les logiciels affectent de plus en plus notre vie quotidienne, une sorte d’équilibre entre le développement imprudent de fonctionnalités géniales et la responsabilité mesurée d’un fonctionnement sécurisé est plus nécessaire que jamais.