Qu'est-ce qui se cache dans votre code ?

Même les projets simples ont tendance à prendre de l'ampleur rapidement et cette tendance est amplifiée par la facilité d'incorporation de morceaux de code ou de bibliothèques de nœuds existants.

C'est encore quelque peu gérable lorsque vous êtes le seul à écrire ce code, mais cela devient plus difficile lorsque le code est écrit par un certain nombre de développeurs et d'équipes, comme c'est normalement le cas.

Même le chef d’équipe, celui chargé d’approuver toutes les demandes d’extraction, ne peut pas connaître chaque ligne de code, chaque fonction et chaque variable.

Une question de confiance

C'est l'une des raisons pour lesquelles le changement mineur de code a eu lieu dans l'application Orion fin 2020, dans le cas connu plus tard sous le nom de Vents solaires, est resté inaperçu pendant si longtemps. L'ensemble du changement ne concernait que quelques dizaines de lignes de code, et elles étaient très bien caché à l'intérieur de la classe d'origine.

Le produit modifié était correctement signé, il n'y avait donc aucune raison de le soupçonner, et les équipes de développement ont fait confiance au propriétaire du code.

Ce n'est que récemment que nous avons appris que le NPM avait un «défaut logique» qui permettait à des acteurs malveillants de faire passer des bibliothèques malveillantes pour légitimes. Fondamentalement, NPM permettait d'ajouter n'importe qui en tant que responsable d'un package sans en informer ces utilisateurs ni obtenir leur consentement. 

Cela a permis de créer des packages contenant des logiciels malveillants et de les attribuer à des responsables fiables et populaires à leur insu. Un cas de confiance mal placée pourrait signifier une vulnérabilité problématique cachée dans votre code.

Une autre pratique courante à considérer consiste pour les développeurs à copier et coller du code à partir de bibliothèques existantes ou de StackOverFlow pour l'utiliser dans leur propre code ou pour le recharger dans de nouvelles bibliothèques. Cela augmente le risque de copier également du code non sécurisé et vulnérable qui n’est désormais pratiquement pas suivi. Même si le code d'origine obtient un CVE et éventuellement une correction, la fonction problématique que vous avez copiée est invisible et pourrait contaminer toute base de code qui l'utiliserait pendant des années. 

Dans une étude récente menée à l’Université du Kansas («C'est quoi la fourchette ? Trouver des clones de code cachés dans npm"), les chercheurs illustrent à quel point l'utilisation de packages, même entièrement vérifiés, peut être dangereuse.

Que peux-tu y faire?

Vous ne pouvez donc pas faire confiance aux produits signés et aux mises à jour des fournisseurs. Votre propre code a peut-être déjà été modifié ou ajouté, en raison de toutes ces bibliothèques externes et du code qui y est incorporé. Alors, que pouvez-vous faire pour être vraiment certain que vous n’installez pas de fichiers malveillants sur votre système ?

Vous pouvez faire plusieurs choses :

1. Demandez un SBOM complet à chaque propriétaire de bibliothèque ou fournisseur de programme que vous incorporez. Un SBOM peut vous aider à vérifier quels sont tous les « ingrédients » de la bibliothèque ou du produit. De plus, si vous trouvez quelque chose dans la bibliothèque ou dans le produit qui n'est pas répertorié dans le SBOM, cela doit être considéré comme suspect. Vous pouvez en savoir plus sur ce qu'est un SBOM ici.
2. Demandez au fournisseur ou au propriétaire de la bibliothèque une attestation fiable attestant qu'un contrôle d'intégrité a été effectué et que vous obtenez ce que vous attendez. Vous ne devriez pas avoir à vous fier uniquement à la propre assurance du fournisseur.
   
3. Lors de l'installation de packages, utilisez l'indicateur CLI npm --ignore-scripts pour éviter d'exécuter des scripts à partir de packages tiers pendant la phase d'installation.
4. Utiliser un package-lock.json fichier pour verrouiller les numéros de version du package. Lorsque vous utilisez un package-lock.json vous ne verrouillez pas seulement les versions de package que vous utilisez, vous verrouillez également leurs dépendances. Le risque est que vous n’effectuerez aucune mise à jour automatique des packages pouvant inclure des correctifs pour divers bogues. Mais si vous avez travaillé pour vérifier une certaine version et que vous ne souhaitez rien inclure d'autre sans l'avoir vérifié au préalable, le verrouillage de vos numéros de version est la meilleure option.

Suivant(e) nouveaux règlements, la plupart des gens devraient commencer à utiliser les SBOM dans un avenir très proche. Plus les entreprises demanderont des SBOM et autres attestations, plus les organisations et les responsables devront s’y conformer.