Les exemples d’attaques opérées sur la chaîne d’approvisionnement et qui exploitent des logiciels tiers pour infiltrer une entreprise se multiplient. En 2020, un code malveillant introduit au sein d’une mise à jour du logiciel SolarWinds s’est d’abord répandu dans les systèmes de différentes branches du gouvernement fédéral américain, avant de se diffuser à l’international et d’infecter environ 18 000 entreprises. En mars 2021, plus de 20 000 entreprises américaines ont vu leur sécurité compromise par une vulnérabilité du logiciel Microsoft Exchange Server. Le risque infiltre également souvent la supply chain via les partenaires, généralement considérés comme inoffensifs ; ce fut le cas lors de l’attaque menée sur la supply chain de CodeCov, logiciel à destination des développeurs, qui a offert aux pirates la possibilité de prendre également le contrôle des chaînes d’approvisionnement des clients de l’entreprise.

Si les risques liés à la chaîne d’approvisionnement logicielle ne peuvent pas être ignorés, il est tout aussi impossible de renoncer aux avantages des nouvelles technologies. Un dilemme quotidien pour de nombreuses entreprises, face auquel les développeurs logiciels doivent faire un choix entre rester conformes aux normes de sécurité les plus élevées et miser sur davantage d’autonomie.

Pour concilier ces deux approches antinomiques, il peut être utile de repenser le processus de signature de code, qui permet de prouver qu’un logiciel n’a été ni altéré ni corrompu avant son déploiement.

Les techniques de signatures de code traditionnelles utilisent des clés cryptographiques pour prouver l’identité de l’auteur du code ou l’intégrité du contenu d’un livrable logiciel. Une charge supplémentaire pour les développeurs qui doivent générer ces clés et préserver leur sécurité. Face à cette responsabilité, certains décident de ne pas signer leurs codes (ce qui est mauvais pour la sécurité) ou d’en écrire moins (ce qui est mauvais pour l’innovation). Ces deux approches ont un impact négatif sur les autres développeurs. Alors qu’une grande part des logiciels utilisés aujourd’hui dans le monde sont conçus sur des principes open source, qui permettent à n’importe qui d’accéder au code et de l’adapter à sa convenance, la question de la provenance est de plus en plus importante. Cela s’applique aussi aux logiciels propriétaires, qui utilisent de plus en plus de codes open source.

Dans ce contexte, la communauté open source doit montrer la voie et simplifier l’environnement de signature de code pour les développeurs, en remplaçant par exemple les clés permanentes par des clés éphémères liées à des éléments d’identification existants (semblables à des identifiants d’adresses e-mail ou de réseaux sociaux), ou en produisant un log public et immuable qui répertorie toute activité. Ces deux types de capacités combinées libèrent les développeurs du fardeau de la signature de code, pour qu’ils puissent se consacrer à ce qu’ils font le mieux, et sécurise fortement le système.

La chaîne d’approvisionnement logicielle couvre un spectre très large d’environnements, depuis le développeur jusqu’au client final, et depuis le code source jusqu’à la livraison, en passant par la construction, les dépendances, l’assemblage, l’empaquetage. Dans le contexte actuel où les objets connectés se multiplient sans interruption, le risque qui pèse sur les chaînes d’approvisionnement d’être victimes de cyberattaques augmente également. Pour limiter au maximum les dégâts, un effort supplémentaire doit être accordé, en termes de sécurité, aux supply chains.

Les communautés Open Source sont à pied d’œuvre pour traiter ce problème et de nombreux projets voient le jour et se complètent pour améliorer la sécurité de la supply chain dans son ensemble, parmi lesquels sigstore, slsa.dev ou encore CycloneDX.