Que se passe-t-il réellement lorsque vous exécutez npm i -s
Quand vous tapez npm i -sVous faites bien plus qu'installer une dépendance ; vous modifiez la chaîne d'approvisionnement de votre projet. Le -s drapeau est l'abréviation de -SauverL'exécution de `npm i -s` ou `npm install --save` installe un paquet et l'enregistre dans le répertoire `save`. dépendances section de votre package.jsonÀ partir de ce moment-là, chaque environnement qui s'exécute npm installer téléchargera cette même dépendance.
Exemple :
# Adds express to dependencies
npm i -s express
C'est pratique, mais aussi persistant. Si la source du paquet n'est pas vérifiée, ou si l'arbre de dépendances inclut des paquets non fiables, vous créez de fait une faille de sécurité potentielle qui se propage à chaque compilation, dans chaque environnement et sur chaque machine de développeur. Les paquets non vérifiés peuvent contenir :
- Rappels réseau cachés
- Code d'exfiltration de données
- Scripts post-installation qui s'exécutent automatiquement
La commande npm i -s n'est pas dangereuse en soi, mais ce qu'elle installe, et d'où, peut ouvrir la porte à des paquets npm malveillants qui compromettent silencieusement votre projet.
Comment les attaquants exploitent npm pour diffuser des paquets malveillants
Les attaquants adorent npm car il est au cœur du développement d'applications modernes. Chaque fois qu'un développeur exécute `npm install --save`, une faille de sécurité existe si les sources des dépendances ne sont pas soigneusement validées.
Vecteurs d'attaque courants
- Typosquattage: Les attaquants publient des paquets dont les noms sont similaires à des paquets populaires. Exemple : installation express au lieu de express via npm i -s, le « s » supplémentaire charge un paquet cheval de Troie.
- Confusion des dépendances: Une dépendance privée comme @internal/client-api pourrait être éclipsé par un package npm public du même nom.
Lorsqu'un développeur exécute la commande npm i -s @internal/api-client, c'est la version publique malveillante qui s'installe à la place. - Mainteneurs compromis : Les attaquants détournent des comptes légitimes ou injectent du code malveillant dans des projets de confiance, transformant ainsi une dépendance connue en vecteur d'infection.
Exemple d'injection malveillante :
❌ Exemple d'extrait de code de dépendance malveillante
postinstall: node exfiltrate-secrets.jsMême les grandes organisations ont été touchées par la propagation de paquets malveillants npm. standard npm install –save Les attaquants exploitent la chaîne de confiance, et les développeurs ne s'en aperçoivent généralement que lorsque des identifiants ou des données commencent à fuiter.
La menace silencieuse des scripts d'installation et de post-installation Hooks – npm i -s
L'écosystème npm permet aux packages d'exécuter des scripts de cycle de vie comme installer or post-installation Automatiquement. C'est utile pour la création de binaires, mais cela ouvre aussi la porte à des abus. Lorsque vous exécutez `npm i -s` ou `npm install --save`, npm exécute automatiquement ces scripts sans demander de confirmation. dépendance malveillante peut utiliser ce comportement pour :
- Lancer les commandes du système
- Créer des portes dérobées dans l'environnement local
- Voler des clés SSH, des jetons ou des variables d'environnement
Exemple (comportement non malveillant mais risqué) :
"scripts": {
"postinstall": "node ./scripts/setup.js"
}
If configuration.js Si le code en amont est remplacé ou modifié, votre système pourrait exécuter silencieusement du code contrôlé par un attaquant pendant l'installation. In CI/CD pipelines, où npm i -s Ce risque s'accroît lorsqu'il s'exécute automatiquement lors des compilations. Un simple paquet npm malveillant peut compromettre l'agent de compilation, exfiltrer des données sensibles ou altérer les artefacts de déploiement.
Pourquoi la vérification manuelle des paquets ne suffit pas avec npm i -s
Les développeurs pensent souvent que vérifier un package.json Lire un fichier ou le fichier README d'un dépôt ne garantit pas la sécurité. Ce n'est pas le cas. Une simple commande `npm install --save` peut installer des dizaines, voire des centaines, de dépendances transitives. Chacune d'elles pourrait introduire des vulnérabilités ou du code malveillant sans être visible dans vos dépendances de premier niveau.
Problème du monde réel : la prolifération des dépendances
Un projet comportant 20 dépendances directes peut facilement se retrouver avec plus de 500 dépendances transitives. Leur vérification manuelle est impossible. Les attaquants exploitent cette complexité pour dissimuler des paquets npm malveillants au cœur de l'arborescence.
Mini-liste de vérification pour une utilisation plus sûre des dépendances
- Utilisez le audit npm et npm ls identifier les dépendances cachées.
- Vérifiez l'auteur du paquet et la date de sa dernière mise à jour avant d'exécuter la commande npm i -s.
- Évitez d'installer des logiciels à partir d'URL non vérifiées ou de dépôts Git.
- Vérifier la présence de scripts suspects (installer, préparer, post-installation) dans package.json.
- Verrouiller les versions utilisant package-lock.json et activer la vérification de signature.
L'examen manuel est un début, mais l'automatisation est indispensable pour une véritable protection.
Intégration de l'analyse des dépendances et des contrôles de politiques dans CI/CD
DevSecOps moderne pipelines Chaque commande `npm i -s` doit être considérée comme un point d'entrée potentiel pour les paquets malveillants npm. L'analyse des dépendances n'est pas optionnelle ; elle fait partie intégrante de vos pratiques de compilation.
Stratégies d'automatisation
- Analyse statique des dépendances: Utilisez des scanners automatisés pour vérifier la présence de packages malveillants ou vulnérables connus avant les étapes de compilation.
- Vérification de la signature: Vérifiez l'intégrité du paquet par comparaison de hachage ou par métadonnées signées.
- L'application de la politique: Empêcher l'installation de sources non vérifiées.
Exemple pipeline configuration:
security-scan:
script:
- xygeni scan --dependencies --npm --detect-malicious
- xygeni enforce --policy supplychain.yaml
Intégrer cela dans votre CI/CD Ce système garantit la validation de chaque commande `npm install --save`. Tout paquet ne respectant pas les règles, non signé, inconnu ou présentant un risque, est automatiquement bloqué. Cela protège non seulement les systèmes de construction, mais empêche également la contamination en aval des environnements de production.
Construire une chaîne d'approvisionnement fiable : de npm à la production
La sécurité ne s'arrête pas à l'installation. Chaque commande `npm i -s` contribue à votre chaîne d'approvisionnement logicielle, et si elle n'est pas vérifiée, elle représente un risque.
Pour instaurer la confiance de bout en bout :
- « Générer » SBOMs (nomenclature du logiciel): Suivre chaque version et source du package.
- Utilisez des autorisations signées : Adoptez la signature des colis ou la vérification des signatures pour garantir leur authenticité.
- Valider à chaque étape: Appliquez des contrôles d'intégrité non seulement dans l'intégration continue, mais aussi lors du déploiement et de l'exécution.
- Constructions isolées : Effectuez les installations dans des environnements isolés (sandboxes) afin d'empêcher tout accès non autorisé au réseau ou aux fichiers.
Exemple de configuration sécurisée des cookies pour les environnements API, souvent exposés via des dépendances infectées :
Version sécurisée, téléchargez, vérifiez, puis exécutez
# ✅ Secure cookie setup
Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Strict
Ces mesures, combinées à une analyse automatisée des dépendances, peuvent neutraliser les paquets npm malveillants avant qu'ils ne se propagent dans votre chaîne d'approvisionnement.
Conclusion : Sécurisez vos installations npm avant qu’elles ne vous sécurisent.
Chaque commande `npm i -s` ou `npm install --save` introduit bien plus qu'une simple fonctionnalité ; elle instaure la confiance. Et la confiance sans vérification représente un risque.
Pour protéger votre chaîne d'approvisionnement logicielle :
- Automatiser la validation des dépendances
- Appliquer la vérification de signature et d'intégrité
- Analysez en continu les paquets npm malveillants.
- Bloquez les sources non vérifiées dès le début de votre CI/CD
Xygéni aide les équipes DevSecOps à détecter et bloquer les dépendances npm malveillantes, à appliquer les politiques de paquets et à surveiller l'intégrité des builds, garantissant ainsi que ce que vous installez est exactement ce que vous souhaitez exécuter.
Car en matière de sécurité de la chaîne d'approvisionnement, la prévention n'est pas une étape de construction ; c'est le fondement.
