Ce que les développeurs frontaux doivent savoir sur les SBOM en JavaScript

Principaux enseignements

• Les applications JavaScript comprennent souvent des centaines de dépendances cachées, à la fois directes et transitives.
• Les SBOM vous donnent une visibilité complète de votre base de code, en révélant les vulnérabilités et en garantissant la transparence.
• Des outils tels que Syft et CycloneDX simplifient la génération de SBOM et vous aident à renforcer la sécurité et à maintenir la conformité.

Votre application JavaScript est une boîte noire de dépendances. Ouvrez node_modules et vous trouverez peut-être un millier de paquets dont vous ne soupçonniez pas l'existence, dont certains sont aussi énigmatiques que des OVNI sur un écran radar. À une époque où les attaques contre la chaîne d'approvisionnement se multiplient, ce n'est pas seulement effrayant, c'est dangereux.

Voici les SBOM (Software Bill of Materials) : votre carte des étoiles pour naviguer dans la galaxie des dépendances JavaScript. Dans ce billet, nous expliquerons ce que sont les SBOM, pourquoi les développeurs frontaux ne peuvent pas les ignorer et comment des outils comme CycloneDX et Syft vous permettent de cartographier votre écosystème, d'intégrer la sécurité dans votre flux de travail et d'attraper les vulnérabilités avant qu'elles ne s'écrasent.

Rencontres du genre JavaScript

Lorsque nous considérons les logiciels dans leur ensemble, nous avons plusieurs pièces qui les relient. Il y a des progiciels, des licences, des personnes, des processus, etc. qui s'emboîtent comme des pièces de puzzle...la plupart du temps.

Les dépendances logicielles peuvent sembler aussi étranges qu'un OVNI (Objet volant non identifié) ou un PAN (Phénomène aérien non identifié) : parfois explicables, souvent déconcertantes, et toujours porteuses de la possibilité d'une rencontre surprise.

Il peut y avoir des valeurs aberrantes dans votre code dont vous ne soupçonnez peut-être pas l'existence et, en un clin d'œil, votre logiciel peut être compromis. C'est là que les SBOM entrent en jeu.

Vous pouvez en quelque sorte y penser comme suit : vous installez un paquet, ce paquet installe un autre paquet, puis votre vaisseau mère et TOUS ses vaisseaux enfants sont détruits.

Ce film résume assez bien la situation !

Combien y a-t-il de dépendances dans votre application ?

Essayez de deviner : votre application a-t-elle 20 dépendances ? 200 ? Ou l'équivalent d'une petite galaxie - plus près de mille ?

Si vous lancez npm ls dans votre terminal, vous obtiendrez une liste de dépendances.

Pourquoi ne pas lister TOUTES les dépendances ? C'est possible, cela risque de surcharger le terminal car les arbres de dépendances peuvent être volumineux, mais c'est possible.

Cette façon de lister les dépendances permet d'afficher non seulement les dépendances directes, mais aussi les dépendances transitives.

Deux formes de dépendance

Lorsque nous regardons les dépendances de notre projet, nous sommes confrontés à deux types de dépendances : l'une est une dépendance directe. Celle que vous pouvez voir si vous ouvrez votre fichier package.json, l'arbre des dépendances directes.

Par exemple, next est une dépendance directe car vous en avez besoin pour construire une application Next.

JSON

"dependencies": {

"react": "^19.0.0",

"react-dom": "^19.0.0",

"next": "15.3.4"

}

Il y a ensuite les dépendances transitives. Ce sont des dépendances de dépendances qu'il faut creuser profondément pour les trouver. Habituellement, dans un fichier package.json dans le dossier node_modules d'un dossier de paquetage.

Dans cet exemple, @next/env est une dépendance transitive de next.

JSON

"dependencies": {

"@next/env": "15.3.4"

}

Qu'est-ce qu'un SBOM ?

Un SBOM est essentiellement le manifeste de votre projet - un inventaire lisible par une machine qui précise chaque composant, chaque dépendance et chaque relation. Il s'agit de la liste des ingrédients de votre base de code ou du manifeste de vol qui indique exactement qui est à bord. Un SBOM répertorie toutes les dépendances et versions d'un projet.

Voici un extrait de Tahir Balarabe sur Medium. Cette explication résume parfaitement la situation.

"Un SBOM, ou nomenclature logicielle, est une liste détaillée, lisible par une machine, de tous les composants d'un logiciel, y compris les dépendances, les métadonnées et les relations entre les composants.

• https://medium.com/@tahirbalarabe2/why-every-modern-software-needs-a-software-bill-of-materials-sbom-for-security-04a4fec312c8

Vous vous demandez peut-être : "Pourquoi avons-nous besoin d'un SBOM ?". Il y a de nombreuses raisons pour lesquelles nous avons besoin d'un ou de plusieurs SBOM lorsque nous produisons ou consommons des logiciels. L'une d'entre elles est la transparence. Nous devons savoir ce que contient notre produit. Expédier un produit ou offrir un produit non sécurisé n'est bénéfique pour personne ; cela entraînera éventuellement des problèmes à l'avenir.

La transparence en ce qui concerne le contenu de votre arbre de dépendances contribue à la sécurité et à la conformité, qui sont également deux raisons très importantes. Savoir ce que contient votre produit est une chose, mais être sécurisé et conforme en est une autre.

Types de SBOM

Lorsque nous parlons de SBOM ou que nous en élaborons pour nos logiciels, nous en avons 6 types différents. Tous ces types se décomposent en différentes parties du SLDC (Software Development Lifecycle - cycle de vie du développement logiciel).

• Conception SBOM
• Source SBOM
• Construire le SBOM
• SBOM analysé
• SBOM déployé
• Exécution SBOM

Pour plus d'informations sur les définitions de ces SBOM, consultez le PDF Types of Software Bill of Materials (SBOM) de la CISA (Cybersecurity & Infrastructure Security Agency).

Une chose à garder à l'esprit lorsque l'on parle de SBOM est qu'il ne s'agit pas d'un fichier de paquetage ou d'un fichier de verrouillage - c'est plus complet. Un SBOM fournit également une liste complète et standardisée de tous les éléments de votre projet : composants, métadonnées, etc.

Gros problème au niveau de l'interface utilisateur

Si vous lisez ceci et que vous avez installé quoi que ce soit sur le frontend en utilisant npm, vous avez très probablement rencontré le problème de taper par mémoire musculaire parce que vous l'avez fait 100 fois auparavant. Parfois, vous ne faites pas attention et vous installez juste ce dont vous pensez avoir besoin. Il se peut même que vous ne fassiez pas de copier-coller directement à partir du site du fournisseur ou du registre npm. Cela entraîne de nombreux problèmes ; nous parlons ici de Typosquatting.

Le typosquattage est également connu sous le nom de détournement d'URL. Il s'agit d'un type d'attaque où un attaquant enregistre un ou plusieurs domaines avec des variations légèrement différentes de fautes d'orthographe pour inciter les utilisateurs à consulter son site, souvent malveillant. Ce phénomène s'étend également à la gestion des paquets. Les attaquants publient également des paquets malveillants et les orthographient mal, tout comme les domaines. Un développeur peut accidentellement faire une faute de frappe et installer un paquet malveillant au lieu du paquet correct.

L'exemple ci-dessous en est une illustration :

npm install express vs. npm install expres

Vous pouvez constater que la deuxième version est la version incorrecte d'express et qu'elle peut être potentiellement dangereuse.

Pourquoi les SBOM sont-ils importants ?

Il y a plusieurs raisons pour lesquelles il est extrêmement important de disposer d'un SBOM :

• Visibilité des composants
• Gestion de la vulnérabilité
• Sécurité de la chaîne d'approvisionnement
• Collaboration et gestion des correctifs
• Conformité réglementaire

Il est essentiel d'avoir une visibilité sur nos composants, en particulier lorsqu'il s'agit de dépendances transitives. Nous voulons également pouvoir gérer nos vulnérabilités en fonction de ce que nous avons installé. Et ne négligez pas le facteur humain : le partage des SBOM renforce la confiance des clients, prouvant que votre chaîne d'approvisionnement en logiciels est transparente et sûre.

En tant que professionnels du web et du logiciel, si nous créons un logiciel qui sera utilisé par d'autres, nous voulons être sûrs d'avoir une relation solide avec nos clients. Il est essentiel de s'assurer que les SBOM sont disponibles pour nos clients.

Installation d'un outil pour générer un SBOM

Il y a plusieurs façons d'installer différents outils pour générer un SBOM. Dans ce billet, nous allons utiliser Syft d'Anchore. Voici quelques commandes pour installer Syft sur votre machine.

La méthode recommandée est l'utilisation de la boucle :

curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin

Vous pouvez également installer le paquet avec Brew :

brew install syft

Il existe également une version pour Windows qui peut être installée via Chocolatey :

choco install syft -y

Microsoft propose également un outil permettant de générer des SBOM à l'aide de Winget :

winget install Microsoft.SbomTool

Une fois Syft installé, nous pouvons passer à la génération d'un SBOM dans notre projet.

Génération de SBOM

Il existe deux formats populaires pour générer un SBOM : SPDX et CycloneDX. Dans les exemples suivants, nous utilisons SPDX pour formater notre SBOM. Nous générons également un SBOM dans un projet Angular, spécifiquement v19.

Une fois que vous êtes dans votre projet, vous exécutez la commande ci-dessous pour générer le SBOM. Il est lisible par une machine, mais nous allons y remédier avec la deuxième commande que nous allons lancer. Vous verrez qu'il y a deux drapeaux à la fin de la commande, -source-name et -source-version. Si vous ne les incluez pas dans la commande, le terminal vous criera dessus. C'est une bonne pratique de les inclure.

syft packages dir:. -o json > sbom.json --source-name "my-js-project" --source-version "1.0"

Maintenant, pour générer une version du SBOM qui puisse être lue par un humain. Vous pouvez lancer une commande appelée jq pour imprimer le SBOM de façon à ce que vous puissiez le parcourir et regarder ce qui a été créé.

jq . sbom.json > sbom-pretty.json

Lorsque vous installez de nouveaux paquets, c'est une bonne pratique de générer un nouveau SBOM afin que le paquet que vous installez puisse être documenté. Vous trouverez ci-dessous une vidéo de l'installation du paquet Lucide pour Angular et de la régénération manuelle du SBOM pour voir le nouveau paquet reflété.

Cela peut également être fait en utilisant une action GitHub. Lorsque vous poussez vers main, dev, ou une branche release, cela déclenche un workflow pour générer un nouvel artefact SBOM au format JSON, qui est stocké dans GitHub. C'est à vous de choisir ce que vous voulez faire de ce fichier.

Réflexions finales

Un SBOM n'est plus optionnel - c'est un élément essentiel du développement des logiciels modernes. Il ne se contente pas de vous indiquer ce qui est installé ; il vous donne une carte vivante des dépendances directes et transitives. Il facilite également la gestion des vulnérabilités et la sensibilisation à la conformité.

La transparence est primordiale, et pour beaucoup d'organisations, un SBOM est un moyen de démontrer leur engagement en matière de visibilité. Dans le cadre de son programme Endless Lifecycle Support (ELS) pour les applications, par exemple, TuxCare fournit automatiquement un SBOM à ses utilisateurs, en fournissant des détails complets sur la façon dont chaque paquet est construit, vérifié et distribué. C'est ainsi que TuxCare permet aux développeurs qui utilisent ses correctifs étendus pour les produits logiciels libres en fin de vie de garantir la transparence et la responsabilité dans leurs écosystèmes logiciels.

La prochaine fois que vous ouvrirez votre projet, générez un SBOM, passez-le dans un scanner de vulnérabilités et voyez exactement quels paquets pourraient abriter des exploits connus. C'est l'un des moyens les plus simples et les plus intelligents d'améliorer votre posture de sécurité frontale.