Sécurité informatique et fraude : les développeurs anticonformistes sont à l’origine de risques dans les chaînes d’approvisionnement de logiciels et de périphériques IdO, selon Jeff Luszcz, vice-président chargé de la gestion des produits chez Flexera Software. L’une des priorités des équipes de développement est la création d’une nomenclature complet des logiciels tiers utilisés.
Les non-conformistes sont des individus dotés d’une créativité exceptionnelle qui rejettent souvent les règles et conventions pour écouter leur génial sens de l’innovation. À de nombreux égards, les développeurs sont donc les anticonformistes de la chaîne d’approvisionnement de logiciels. L’industrie cinématographique les décrit souvent comme des jeunes aimant faire la fête, à l’image des productions hollywoodiennes telles que The Valley ou The Social Network. Ces individus sont essentiels à l’innovation dans la Silicon Valley. Cependant, ils représentent également des vecteurs de risques de sécurité au niveau de la chaîne d’approvisionnement de logiciels, et les cadres dirigeants doivent en être conscients.
Les développeurs aiment utiliser des composants tiers open source et commerciaux pour faire l’impasse sur la partie ennuyeuse de leur travail. Ce faisant, ils peuvent se focaliser sur la partie difficile nécessitant leurs capacités d’innovation. Les composants open source constitueraient ainsi plus de 50 % du code de l’ensemble des logiciels, un constat également valable pour les dispositifs connectés et intelligents. Or les vulnérabilités logicielles étant le vecteur d’attaque préféré des hackers, celles contenues dans les composants open source et commerciaux sont de fait des sources de risques majeures pour les développeurs.
Pourquoi ? Parce que la plupart des éditeurs et des fabricants de dispositifs IdO n’ont pas mis en place les processus et l’automatisation nécessaires pour suivre et gérer ces composants et leurs vulnérabilités. Et même dans le cas contraire, les anticonformistes dans leurs rangs ont tendance à contourner ces processus sans avoir pleinement conscience des conséquences de leurs actes et la mise en péril des entreprises et leur client.
Un secret inavouable
Tout logiciel comporte des bugs et les éditeurs doivent être réactifs. En effet, de plus en plus de logiciels malveillants exploitent les vulnérabilités connues de composants tiers pour mener ou propager une infection. L’importante quantité de failles au sein de produits finis et dues à de tels composants est d’ailleurs un des secrets inavouables de l’industrie.
Les attaques récentes dans le domaine de l’IdO tiraient ainsi parti de vulnérabilités connues à la fois dans des composants open source et tiers. Ainsi, le malware Bashlite exploitait la faille Shellshock dans l’interpréteur de ligne de commande Bash afin d’infecter des systèmes IdO. D’autres attaques ciblent des composants commerciaux en utilisant des combinaisons nom d’utilisateur et mot de passe…
Pendant de nombreuses années, la conformité des licences open source est passée au second plan par rapport à la livraison de nouvelles fonctionnalités ou versions des produits. Déjà problématique en soi, cette approche a également engendré une situation où les entreprises ont utilisé entre plusieurs centaines et plusieurs milliers de composants tiers dont ils ignoraient beaucoup, voire tout ! C’est tout particulièrement le cas dans le domaine de l’IdO, où chaque dispositif doit intégrer un système d’exploitation : dans de nombreux cas, il est open source, et les développeurs doivent révéler l’utilisation et publier le code source des composants et produits liés aux composants GPL, ce qui est malheureusement rarement le cas.
La comparaison avec l’aérospatiale
À chaque nouvelle attaque, les comparaisons entre l’industrie logicielle et celle de l’aérospatiale abondent. Le fait est que si l’on construisait des avions comme on développe des logiciels, personne ne voudrait jamais prendre l’avion. Le ransomware qui a en grande partie mis les ordinateurs du National Health Service (NHS) hors service montre comment des défauts liés à des vulnérabilités connues mais non corrigées peuvent engendrer des problèmes sanitaires et de sûreté. Cette prise de conscience des risques pousse aujourd’hui l’industrie à traiter la conception et la maintenance des systèmes comme l’aérospatiale avec ses avions. Le suivi des inventaires et des nomenclatures est un élément clé dans l’industrie aérospatiale. Il permet en effet de comprendre les fonctionnalités et les tolérances des produits, et en même temps d’identifier les causes racines des défaillances. Lorsqu’un écrou casse et provoque une panne plus importante, la chaîne de contrôle de cette pièce peut être retracée jusqu’à la commande passée au vendeur, et même jusqu’à la spécification au cours du processus de fabrication…
Mais l’industrie du logiciel, elle n’intègre pas de dispositif de ce genre dans son processus de conception et de maintenance. Jusqu’à la faille Heartbleed, il était rare de voir passer la moindre nomenclature.
Se lancer
L’une des priorités des équipes de développement est la création d’une nomenclature basique. Beaucoup commencent par enregistrer les requêtes de nouveaux composants de premier niveau ou leur utilisation. Cette approche permet de créer une nomenclature pour les composants les plus récents, mais fournit peu d’informations sur les choix effectués auparavant. Un effort doit donc être consenti pour créer l’inventaire complet des logiciels tiers actuellement utilisés. Certaines entreprises choisissent d’assurer un suivi des composants de premier niveau et d’ignorer les dépendances de niveau inférieur. Ce niveau d’analyse est plus simple à gérer pour les équipes juridiques, de développement et de sécurité, mais se limite généralement à 10-30 % de la nomenclature totale.
La chaîne d’approvisionnement de logiciels
Le nombre de composants tiers utilisés généralement dans un logiciel augmente chaque année, et en moyenne, une application ou un dispositif IdO d’entreprise contient plus de 500 composants. Bien que nombre d’entre eux soient choisis par un développeur, une proportion importante est introduite automatiquement par un gestionnaire de dépôt.
De plus, l’horodatage issu de sources externes est accepté dans le code base avec très peu de révision, en particulier s’il provient d’un éditeur commercial. Il est important que les développeurs aient les mêmes exigences élevées pour le code tiers que pour celui qu’ils écrivent eux-mêmes. L’absence de nomenclature doit déclencher la même procédure que pour un défaut logiciel. Il existe deux solutions pour permettre aux entreprises de mieux se tenir informées de leur processus d’acquisition. La première est d’insérer des termes dans leurs contrats détaillant leurs exigences en matière de divulgation de composants tiers, ainsi que le processus afin d’être averti des patches ou des mises à niveau liées à des vulnérabilités tierces. En outre, les équipes de développement peuvent recourir à des analyses ciblées des éléments sources et binaires à la recherche de contenu non divulgué. Typiquement, deux ou trois composants de ce type suffisent pour qu’un dialogue soit nécessaire avec l’éditeur tiers. Cette conversation doit permettre de souligner l’importance d’une nomenclature complète, et de montrer à quel point l’entreprise prend soin de ses intérêts. Les éditeurs incapables de proposer le niveau de détails attendu devront alors être évités pour de futurs travaux, et il ne suffit plus pour eux de s’assurer que leurs composants soient sûrs uniquement à leur sortie, en particulier si le code sera utilisé dans des dispositifs connectés en permanence et faisant l’objet d’une faible supervision. Plus vite ils sonneront l’alarme, et plus vite une mise à niveau testée pourra être déployée sur ces dispositifs et au niveau de la base installée.
En changeant d’attitude quant aux individus responsables de la sécurité des composants open source ; en sensibilisant les équipes aux actions permettant de découvrir, gérer et résoudre les problèmes liés à ces composants ; et en conservant le même niveau d’exigences pour les éditeurs et les fournisseurs, il est possible de créer un environnement sécurisé où la moitié du code utilisé provient de tiers.
