La chaîne d’approvisionnement en logiciels est, comme la plupart d’entre nous le savent maintenant, à la fois une bénédiction et une malédiction.
Il s’agit d’un réseau de composants incroyable, labyrinthique et complexe (certains diraient désordonné) qui, lorsqu’il fonctionne comme prévu, offre les commodités et les avantages magiques de la vie moderne : des informations et des connexions du monde entier, ainsi que de la musique, des vidéos, et autres divertissements, le tout dans nos poches. Véhicules avec assistance de voie et système d’évitement d’accidents.
Systèmes de sécurité à domicile. Systèmes de trafic intelligents. Et ainsi de suite.
Mais lorsqu’un ou plusieurs de ces composants présentent des défauts pouvant être exploités par des criminels, cela peut être risqué et dangereux. Cela met toute la chaîne en péril. Vous savez, le syndrome du maillon le plus faible. Les vulnérabilités logicielles peuvent être exploitées pour perturber la distribution de le carburant ou aliments. Il peut être utilisé pour voler des identités, vider des comptes bancaires, piller la propriété intellectuelle, espionner une nation et même attaquer une nation.
La sécurité de chaque maillon de la chaîne d’approvisionnement en logiciels est donc importante – suffisamment importante pour en faire une partie du décret exécutif du président Joe Biden de mai 2021, « Améliorer la cybersécurité de la nation » (également connu sous le nom d’EO 14028).
C’est aussi assez important pour avoir été l’un des principaux sujets de discussion à La conférence RSA 2022 à San Fransisco. Parmi les dizaines de présentations sur le sujet lors de la conférence figurait « Chaîne d’approvisionnement en logiciels : les défis, les risques et les stratégies de réussite » par Tim Mackey, stratège principal en matière de sécurité au sein du Synopsys Cybersecurity Research Center (CyRC).
Défis et risques
Les défis et les risques sont nombreux. Pour commencer, trop d’organisations ne vérifient pas toujours les composants logiciels qu’elles achètent ou extraient d’Internet. Mackey a noté que même si certaines entreprises effectuent une vérification approfondie des antécédents des fournisseurs avant d’acheter – couvrant tout, de l’équipe de direction, des finances, de l’éthique, de la qualité des produits et d’autres facteurs pour générer un score d’évaluation des risques des fournisseurs – ce n’est pas la norme.
« Le reste du monde traverse, en fait, un processus d’approvisionnement non géré », a-t-il déclaré. « En fait, les développeurs adorent pouvoir télécharger n’importe quoi sur Internet et l’intégrer à leur code. »
Bien qu’il puisse y avoir des exigences réglementaires ou de conformité pour ces développeurs, « ils ne sont généralement pas là du point de vue de la sécurité », a déclaré Mackey. « Donc, une fois que vous avez décidé que, par exemple, une licence Apache est une chose appropriée à utiliser au sein d’une organisation, s’il existe des CVE non corrigés [Common Vulnerabilities and Exposures] associé à quoi que ce soit avec une licence Apache, c’est le problème de quelqu’un d’autre. Il y a beaucoup de choses qui entrent dans la catégorie des problèmes de quelqu’un d’autre.
Ensuite, il y a le fait que la grande majorité des logiciels utilisés aujourd’hui – près de 80% – sont open source, comme le documente le rapport annuel « Sécurité open source et analyse des risques» (OSSRA) rapport du Synopsys CyRC.
Les logiciels open source ne sont ni plus ni moins sécurisés que les logiciels commerciaux ou propriétaires et sont extrêmement populaires pour de bonnes raisons – ils sont généralement gratuits et peuvent être personnalisés pour faire ce que veut l’utilisateur, dans certaines limites de licence.
Mais, comme l’a noté Mackey, les logiciels open source sont généralement créés par des communautés de bénévoles – parfois de très petites communautés – et les personnes impliquées peuvent éventuellement perdre tout intérêt ou être incapables de maintenir un projet. Cela signifie que si des vulnérabilités sont découvertes, elles ne seront pas nécessairement corrigées.
Et même lorsque des correctifs sont créés pour corriger des vulnérabilités, ils ne sont pas « poussés » vers les utilisateurs. Les utilisateurs doivent les «extraire» d’un référentiel. Ainsi, s’ils ne savent pas qu’ils utilisent un composant vulnérable dans leur chaîne d’approvisionnement logicielle, ils ne sauront pas qu’ils doivent insérer un correctif, ce qui les exposera. Le tristement célèbre groupe de vulnérabilités Log4Shell dans la bibliothèque de journalisation open source Apache Log4j en est l’un des exemples les plus récents.
Garder une trace ne suffit pas
La gestion de ce risque nécessite des efforts sérieux. Le simple suivi des composants d’un produit logiciel peut devenir très compliqué très rapidement. Mackey a parlé d’une application simple qu’il a créée et qui avait huit « dépendances » déclarées – des composants nécessaires pour que l’application fasse ce que le développeur veut qu’elle fasse. Mais l’un de ces huit avait 15 dépendances. Et l’un de ces 15 en avait 30 autres. Au moment où il a atteint plusieurs niveaux, il y en avait 133 – pour une seule application relativement simple.
En outre, au sein de ces 133 dépendances se trouvaient « plusieurs instances de code auxquelles étaient associées des déclarations explicites de fin de vie », a-t-il déclaré. Cela signifie qu’il n’allait plus être maintenu ou mis à jour.
Et le simple suivi des composants ne suffit pas. Il y a d’autres questions que les organisations devraient se poser, selon Mackey. Ils incluent : Disposez-vous d’environnements de développement sécurisés ? Êtes-vous en mesure de rétablir l’intégrité de votre chaîne d’approvisionnement ? Testez-vous régulièrement les vulnérabilités et les corrigez-vous ?
« Ce sont des choses très détaillées », a-t-il dit, ajoutant encore plus de questions. Comprenez-vous la provenance de votre code et quels sont les contrôles ? Fournissez-vous une nomenclature logicielle (SBOM) pour chaque produit que vous créez ? « Je peux presque garantir que la majorité des gens sur ce [conference] le show floor ne fait pas ça aujourd’hui », a-t-il déclaré.
Mais si les organisations veulent vendre des produits logiciels au gouvernement américain, ce sont des choses qu’elles doivent commencer à faire. « Les clauses du contrat pour le gouvernement américain sont en train d’être réécrites », a-t-il déclaré. « Cela signifie que tous ceux d’entre vous qui produisent des logiciels qui seront consommés par le gouvernement doivent y prêter attention. Et c’est une cible mouvante – vous ne pourrez peut-être pas vendre au gouvernement américain la façon dont vous avez l’habitude de le faire.
Même les SBOM, bien qu’utiles et nécessaires – et un sujet brûlant dans la sécurité de la chaîne d’approvisionnement logicielle – ne suffisent pas, a déclaré Mackey.
Efforts coordonnés
« La gestion des risques de la chaîne d’approvisionnement (SCRM) consiste en réalité en un ensemble d’efforts coordonnés au sein d’une organisation pour identifier, surveiller et détecter ce qui se passe. Et cela inclut le logiciel que vous créez et acquérez, car même s’il est gratuit, il doit toujours passer par le même processus », a-t-il déclaré.
Parmi ces efforts coordonnés, il y a la nécessité de traiter les composants de code tels que les bibliothèques de la chaîne d’approvisionnement qui sont obsolètes – qui ne sont plus maintenues. Mackey a déclaré que les développeurs qui n’en sont pas conscients enverront fréquemment des « demandes d’extraction » demandant quand la prochaine mise à jour d’une bibliothèque arrivera.
Et s’il y a une réponse, c’est que le composant est en fin de vie, a été en fin de vie, et que la seule chose à faire est de passer à une autre bibliothèque.
« Mais et si tout en dépendait ? » il a dit. « C’est un exemple parfait des types de problèmes que nous allons rencontrer lorsque nous commencerons à gérer les chaînes d’approvisionnement en logiciels. »
Un autre problème est que les développeurs ne connaissent même pas certaines dépendances qu’ils intègrent dans un projet logiciel et ne savent pas si celles-ci peuvent présenter des vulnérabilités.
« Le rapport OSSRA a révélé que le meilleur framework avec des vulnérabilités l’année dernière était jQuery [a JavaScript library]. Personne ne décide d’utiliser JQuery, c’est un jeu d’enfant », a-t-il déclaré, ajoutant que c’est également vrai pour d’autres, notamment Lodash (une bibliothèque JavaScript) et Spring Framework (un cadre d’application et un conteneur d’inversion de contrôle pour la plate-forme Java). ). « Ils sont tous venus pour la balade », a-t-il déclaré. « Ils ne font partie d’aucune surveillance. Ils ne sont pas corrigés parce que les gens ne les connaissent tout simplement pas.
Construire de la confiance
Il existe de nombreuses autres activités nécessaires au sein de SCRM qui, collectivement, visent à rendre beaucoup plus probable la fiabilité d’un produit logiciel. Beaucoup d’entre eux sont contenus dans le conseils sur la sécurité de la chaîne d’approvisionnement des logiciels publié début mai par l’Institut national des normes et de la technologie en réponse à l’OE de Biden.
Mackey a déclaré que cela signifie que les organisations auront besoin que leurs «équipes d’approvisionnement travaillent avec l’équipe du gouvernement pour définir quelles sont les exigences de sécurité. Ces exigences vont ensuite informer ce que l’équipe informatique va faire – ce que signifie un déploiement sécurisé. Ainsi, lorsque quelqu’un achète quelque chose, ces informations sont transmises à l’approvisionnement pour validation. »
« Un fournisseur doit être en mesure d’expliquer ce qu’est son SBOM et d’où il a obtenu son code, car c’est de là que les correctifs doivent provenir », a-t-il déclaré.
Enfin, Mackey a déclaré que la plus grande menace est la tendance à supposer que si quelque chose est sécurisé à un moment donné, il le sera toujours.
« Nous aimons mettre des cases à cocher à côté des choses – déplacez-les dans la colonne « Terminé » et laissez-les là », a-t-il déclaré. « La plus grande menace que nous avons est que quelqu’un va exploiter le fait que nous avons une coche sur quelque chose qui est en fait quelque chose de dynamique – pas quelque chose de statique qui mérite une coche. C’est le monde réel. C’est désordonné – vraiment désordonné.
Dans quelle mesure les éditeurs de logiciels sont-ils prêts à mettre en œuvre les mesures de sécurité qui leur seront éventuellement imposées ? Mackey a déclaré avoir vu des rapports montrant que pour certaines de ces mesures, le pourcentage atteignait 44 %. « Mais environ 18% est plus typique », a-t-il déclaré. « Les gens comprennent un peu le message, mais nous n’en sommes pas encore là. »
Donc, pour ceux qui veulent vendre au gouvernement, il est temps d’améliorer leur jeu SCRM. « Le temps presse », a déclaré Mackey.
Cliquez sur ici pour trouver plus de contenu Synopsys sur la sécurisation de votre chaîne d’approvisionnement logicielle.
Source link