La checklist di sicurezza per chi pubblica pacchetti su npm

Se sviluppi pacchetti open source o pubblichi codice su npm, ti muovi in un ambiente dove negli ultimi anni sono emersi attacchi molto sofisticati. Non basta più dire “funziona sulla mia macchina” prima di fare il deploy.

La verità è che la maggior parte di questi problemi si può evitare. Basta applicare un po’ di disciplina e usare gli strumenti giusti.

Perché la sicurezza va controllata prima della pubblicazione

Un singolo pacchetto può finire in migliaia di applicazioni e pipeline di build. Questa diffusione lo rende un bersaglio interessante per chi vuole rubare credenziali o inserirsi in ambienti CI/CD, dove spesso si eseguono con privilegi elevati.

Per fortuna, la maggior parte degli attacchi si evita con controlli semplici ma rigorosi.

I 12 vettori di attacco più comuni su npm

1. Compromissione dell’account e pubblicazione malevola

L’incubo peggiore: le tue credenziali npm vengono rubate e un aggressore pubblica una versione modificata del tuo pacchetto. Gli utenti la installano automaticamente e il codice malevolo finisce in produzione.

Come proteggersi:

• Attiva il 2FA sul tuo account npm
• Usa token di accesso con permessi limitati invece della password principale
• Abilita l’approvazione delle pubblicazioni per i pacchetti più sensibili
• Controlla regolarmente i log delle pubblicazioni

2. Gli hook del ciclo di vita

npm permette l’uso di hook come preinstall e postinstall. Con un pacchetto controllato, un aggressore può eseguire codice arbitrario al momento dell’installazione, prima ancora che il tuo codice venga caricato.

Come ridurre il rischio:

• Esamina ogni hook presente in package.json
• Chiediti se serve davvero eseguire codice durante l’installazione
• Se li devi usare, tienili semplici e trasparenti
• Valuta alternative che operino durante la build

3. I worm che si replicano

Un pacchetto può modificare altri pacchetti dentro node_modules e propagare il codice malevole attraverso il dependency tree. Questo è il vettor di attacco del worm.

Come difendersi:

• Evita modifiche al filesystem durante l’installazione
• Non toccare i file di altri pacchetti
• Mantieni le dipendenze isolate
• Usa npm audit e tool di analisi delle dipendenze

4. Attacchi all’identità CI/CD

I tuoi pipeline CI/CD contengono credenziali. Se un aggressore riesce a inserire un pacchetto in un build, può accedere a tutto quel layer di identità.

Difesa a più livelli:

• Usa credenziali minime e con scopo limitato per ogni fase
• Ruota i token spesso
• Non inserire credenziali nei comandi di package.json
• Considera OpenID Connect per l’autenticazione
• Controlla chi ha accesso ai segreti

5. Dipendenze da Git nascoste

Installare dipendenze da repository Git bypassa i controlli del registry. Un aggressore può mettere un fork malevolo e trarre in inganno gli utenti.

Contromisure:

• Blocca le dipendenze sulle versioni del registry,而不是 su Git
• Se devi usare Git, verifica l’hash del commit
• Non usare mai latest o riferimenti a branch da repository non fidati
• Documenta sempre il motivo di una dipendenza da Git

6. Dipendenze dinamiche remote

Alcune pacchetti eseguono code fetch at runtime. Questo crea un attacco surface invisibile, in cui il tuo pacchetto agisce come mere loader per payload malevoli.

Best practice:

• Tutte le dipendenze devono essere dichiarate in package.json
• Non fetch ed eseguire code at runtime
• Usa tool di static analysis per detectare dynamic requires
• Se serve runtime flexibility, designa senza code execution

7. Infrastrutture di phishing

Gli attacchi possono usare npm per ospitare phishing pages e credential-harvesting. Un pacchetto apparentell looks legitimate ma redirecting users a fake login pages.

How to protect users:

• Be transparent about what your package does
• Clarify your official domains and documentation sites
• Implement CSP headers on any associated web properties
• Monitor for typosquatting variations of your package name
• Report suspicious packages immediately

8. Raccolta di credenziali e segreti

Una backdoored package can harvest environment variables, API keys, tokens, and other secrets. Durante l’installazione, it reads .env files, Docker configs, or CI/CD environment variables.

Hardening measures:

• Non commit secrets to version control
• Usa secret management systems
• Implementa il principle of least privilege for credentials
• Audit what environment data your package accesses
• Non log sensitive information

9. Exfiltration e dead-drop channels

Stolen data needs somewhere to go. Gli attacchi usano various covert channels—DNS queries, image requests, obfuscated API calls—to exfiltrate data without looking suspicious.

Detection and prevention:

• Monitor outbound network connections from packages
• Usa tool che analyze package behavior pre-installation
• Implementa egress controls in your security posture
• Question any external calls your package makes
• Document all network dependencies

10. Persistence e anti-forensics

Avanzati attacchi non just steal data once—they establish persistence, modifying system files, cron jobs, or environment configurations to survive beyond the initial infection.

Defensive strategy:

• Review post-installation filesystem changes
• Implementa file integrity monitoring in production
• Keep immutable audit logs of package installations
• Usa containerization to limit persistence vectors
• Consider read-only filesystems where possible

11. Obfuscation e payload packaging

If your code is difficult to read, security reviews become impossible. Gli attacchi deliberately obfuscate malicious code using minification, encoding, and encryption tricks.

Code review best practices:

• Keep your code readable and unobfuscated
• If you minify for production, publish source maps
• Avoid unnecessary encoding or encryption in install-time code
• Use deobfuscation tools during security audits
• Remember: legitimate code doesn't need to hide

12. Package naming e discovery abuse

Typosquatting, lookalike names, and registry manipulation make packages discoverable for wrong reasons. An attacker publishes expresss knowing developers will mistype the real express.

Protection tactics:

• Register common misspellings of your package name
• Use namespaced packages to reduce collision risk
• Document your official package name prominently
• Monitor for copycat packages
• Report typosquatting to npm

La checklist pre-publicazione

Prima di fare publish, usa questo framework:

Security Checklist:

• [ ] 2FA abilitato sul tuo account npm
• [ ] Nessun segreto hardcoded in package.json o codice
• [ ] Lifecycle hooks minimi e giustificati
• [ ] Nessuna dinamica code loading durante l’installazione
• [ ] Nessuna modifica a directory node_modules
• [ ] Tutte le dipendenze bloccate su versioni del registry
• [ ] Nessun unexplained external network call
• [ ] Codice leggibile e non obfuscated
• [ ] Malicious package scanner run (e.g., socket.dev, snyk)
• [ ] Peer review da parte di un developer con focus sulla sicurezza
• [ ] Audit log preparato per la publish action

Process Checklist:

• [ ] Changelog documentato
• [ ] Security policy definita
• [ ] Maintainer contact information provided
• [ ] License clearly specified
• [ ] Repository link verificato e legittimo
• [ ] README che spiega chiaramente il purpose del pacchetto

Il quadro più ampio: spostare la sicurezza a sinistra

La difesa più efficace è integrare la sicurezza nel processo di sviluppo dall’inizio, not bolting it on before publishing. Questo significa:

• Pensa come un aggressore: cosa targeteresti nel tuo pacchetto?
• Automazione lo scanning: usa tool che analyze packages for suspicious patterns
• Rimanere informato: follow npm security advisories and maintainer security best practices
• Costruire trust nella community: be transparent about your process
• Assumere breach: design your package assuming it might be compromised

Prospettiva futura

Il npm ecosystem è incredibly powerful perché è so accessible. Quella accessibility viene con responsibility. Ogni pacchetto che publish runs with significant privilege—it executes during installation, it has access to the filesystem, it can modify the build process.

I developers e organizations che take security seriously, che audit their code before publishing, e che implement these preventative measures aren’t being paranoid. They’re being responsible stewards of a shared infrastructure.

Your package matters. Your users’ security depends on you getting this right.