Les projets possédant des dépendances indirectes sont bien plus vulnérables comme le montre cette récente étude ou cet article de snyk. Le grand problème est qu’il devient difficile de simplement corriger une faille de sécurité rapidement puisqu’elle n’est pas directement liée à la dépendance que vous utilisez.
Évitez à tout prix les packages avec des dépendances dépassant une profondeur de 2-3 packages (cela introduit toujours plusieurs dépendances indirectes à maintenir et sécuriser ce qui peut très vite devenir complexe).
Le projet NodeSecure permet d’analyser en profondeur les dépendances d’un projet ou d’un package npm.
Important
Attention à ne pas non plus tomber dans la parano. Il n’est pas non plus, tout le temps simple, de résoudre des problématiques en quelques packages. L’important est d’être conscient du problème et de faire attention.
Attaque de la chaîne d'approvisionnement en français. Pour un acteur malveillant il est ici question d'attaquer à un élément tiers comme vos dépendances, votre CI ou tout autres composants qui pourrait devenir vulnérable et donner accès à des informations sensibles.
En quelques années cela est devenu un problème très important et massivement exploité pour diverses attaques. Des initiatives et outils comme SLSA et Sigstore on vu le jour dans l'objectif de garantir la provenance d'artifacts (packages etc..).
Des startups ont là aussi vu le jour comme Socket.dev dans l'objectif d'apporter des solutions professionnelles viables (notamment à l'écosystème JavaScript).
Pour diverses raisons, vous pourriez être amené à réaliser un inventaire de vos dépendances (artéfacts). Des standards et outils comme CycloneDX vous permettront de générer facilement un fichier JSON, aisément analysable par des tiers (comme Snyk).
De mon côté j'utilise le CLI cdxgen pour générer un inventaire compliant à partir du package.json.
⬅️ 🔐 Sécurité: Garder sous contrôle votre Environnement | ➡️ 🔐 Sécurité: Faille de sécurité courante