Il y a - et il y aura toujours - des vulnérabilités dans les logiciels. Tout comme il n'y a pas de sécurité parfaite, il n'y a pas de base de code parfaite. D'où la question suivante : Quelle est la meilleure façon de résoudre les problèmes logiciels, en particulier à grande échelle ? Comme c'est souvent le cas lorsqu'il s'agit de questions de sécurité, la réponse est "ça dépend".
Qui laisse sortir les bogues ?
Les logiciels libres permettent à quiconque - pour le meilleur ou pour le pire - de jeter un coup d'œil sous le capot et, avec un peu de chance, de corriger les problèmes de sécurité ou de fonctionnalité. Mais ils peuvent aussi introduire des portes dérobées qui peuvent passer inaperçues, parfois pendant des années, selon une étude de 2022 publiée lors du31e symposium sur la sécurité de l'USENIX.
Les logiciels à code source fermé, quant à eux, reposent sur le secret de leur code source et sur l'expertise de leurs propres développeurs, une sorte de sauce secrète interne dont on espère qu'elle est entretenue par des experts jouissant d'une solide réputation en matière de sécurité, et dont les compétences sont au moins suffisantes pour fidéliser les clients et rester dans le circuit. Qu'ils mettent ou non leur code source à disposition, les développeurs peuvent bénéficier de documents tels que le Top Ten de l'OWASP et les normes de codage du SEI CERT, qui encouragent le développement de pratiques de codage sécurisées.
Si l'origine des logiciels libres remonte aux années 1950, ce n'est qu'au début des années 1980 que les logiciels ont été considérés comme protégeables par le droit d'auteur aux États-Unis. Cela a notamment eu pour conséquence que de nombreux fournisseurs qui livraient auparavant le code source dans le cadre de leurs produits ont cessé de le faire. Tout au long des années 1980 et jusque dans les années 2000, certains éditeurs de logiciels tels que Microsoft ont considéré les logiciels libres comme une sorte de menace existentielle pour leurs activités, avant de les adopter dans les années 2010.
Aujourd'hui, les grandes entreprises technologiques encouragent de plus en plus la collaboration entre le secteur public et le secteur privé en matière de sécurité des logiciels libres, à tel point que la Maison Blanche a organisé un sommet sur la sécurisation des logiciels libres en 2022, peut-être en raison de l'exploitation généralisée des vulnérabilités des logiciels libres. Au moment de la rédaction de cet article, la CISA a annoncé la publication de sa feuille de route pour la sécurité des logiciels libres, soulignant ainsi sa reconnaissance de l'importance des logiciels libres dans l'écosystème technologique et son engagement à contribuer à leur sécurisation.
Les entreprises de logiciels à code source fermé ont également la possibilité de confier à quelqu'un la tâche de mettre à jour les logiciels en fonction des problèmes qui se présentent. Les logiciels libres sont généralement plus dépendants des foules de bénévoles qui interviennent et corrigent les problèmes au fur et à mesure qu'ils surviennent, une propriété connue sous le nom de loi de Linus: "avec suffisamment d'yeux, tous les bogues sont superficiels". Mais comme les bénévoles sont difficiles à rassembler, il est plus difficile de les forcer à faire le travail quotidien de correction des bogues - la partie de la sécurité qui n'est pas glamour - et les mises à jour peuvent être à la traîne. Cette situation est peut-être en train de changer : les programmes de primes aux bugs proposés par Google et Huntr sont un moyen de monétiser la découverte et la correction des vulnérabilités dans les logiciels à code source ouvert.
La réalité des logiciels modernes se situe quelque part entre les deux, puisque de nombreux projets à code source fermé s'appuient souvent sur des logiciels d'"échafaudage" à code source ouvert pour effectuer les tâches de base avant d'ajouter leur sauce secrète par-dessus. Il est logique, par exemple, de ne pas créer une application de courrier électronique à partir de zéro pour effectuer des notifications administratives : il existe des projets à code source ouvert qui ont fait leurs preuves et qui peuvent facilement s'en charger.
À l'inverse, certaines entreprises plus orientées vers les logiciels libres contribuent activement aux projets de logiciels libres qu'elles jugent importants et, parce qu'elles ont des clients commerciaux, leurs revenus commerciaux leur permettent d'employer quelqu'un dont le travail consiste à corriger les bogues.
Mais cette étrange confluence de forces peut encore permettre des problèmes tels que les vulnérabilités de Log4j, qui peuvent saper l'infrastructure et peut-être même fournir une porte dérobée, que la pile complète que vous utilisez en tant que produit soit ouverte, fermée, ou plus probablement quelque chose entre les deux.
Un effet secondaire des logiciels à code source ouvert est qu'ils aident à faire démarrer des communautés entières de logiciels de communication qui veulent agir en toute sécurité, puisqu'ils n'ont pas besoin de tout construire à partir de zéro pour essayer d'obtenir une cryptographie correcte.
C'est ce que font certains des projets logiciels de protection de la vie privée les plus populaires au monde, comme Proton et Signal, qui jouissent tous deux d'une solide réputation et d'une longue histoire en matière de protection de la vie privée et de la sécurité.
Les auteurs de Signal invitent tout le monde à examiner leur code, et comme la messagerie personnelle est une fonction si importante pour la société, de nombreux spécialistes de la sécurité se concentrent sur ce point, car une vulnérabilité, ou une faiblesse cryptographique, peut avoir des conséquences d'une telle ampleur.
Proton, basée en Suisse, a débuté dans le domaine de la messagerie électronique ultra-sécurisée, puis s'est développée dans un ensemble d'autres services autour de la protection de l'identité des utilisateurs - une autre fonction extrêmement importante pour la société, et lourde de conséquences en cas d'erreur.
Au cas où vous penseriez que les logiciels à code source fermé ont de meilleurs antécédents, sachez que même les logiciels à code source fermé les plus utilisés au monde peuvent contenir des vulnérabilités pendant des années, voire des dizaines d'années. Prenons l'exemple de CVE-2019-0859. Découverte par Kaspersky Lab, il s'agit d'une vulnérabilité de type "use-after-free" trouvée dans dix ans de systèmes d'exploitation Microsoft Windows, de Windows 7 à Windows 8 à Windows 8.1 à Windows 10 du côté des ordinateurs de bureau, et dans les versions 2008 R2, 2012, 2012 R2, 2016 et 2019 de Windows Server.
Le diable se cache dans les détails
La vérité est que ni les logiciels libres ni les logiciels fermés ne sont intrinsèquement plus sûrs les uns que les autres. Ce qui compte, c'est le processus de développement des logiciels et la mise en œuvre de correctifs pour remédier aux vulnérabilités. C'est sur la fiabilité de ces correctifs et la rapidité avec laquelle ils peuvent être mis en œuvre que les organisations devraient se concentrer pour déterminer leur posture de sécurité, et non sur le type de licence logicielle.
En fin de compte, tout dépend de la réactivité de l'organisation hôte vis-à-vis de la communauté de la sécurité au sens large. ESET, par exemple, contribue de manière significative au cadre ATT&CK® de MITRE et fournit de nombreux autres outils de sécurité qui sont souvent gratuits ou open source.
Dans le monde hybride des logiciels, qui est presque toujours un mélange de logiciels à code source ouvert et fermé, cela devient le test décisif : l'entreprise ou l'organisation est-elle ouverte aux suggestions et aux contributions, et réinvestit-elle dans la communauté de la sécurité ? Comme le dit un proverbe, il faut s'assurer que les utilisateurs de logiciels sont en bonne compagnie, et la marée montante de la sécurité soulèvera tous les navires numériques. Et même si la sécurité parfaite reste insaisissable, de grandes équipes jouissant d'une bonne réputation peuvent certainement y contribuer.
