Le librerie che hai installato hanno falle già pubblicate

Un'applicazione moderna è fatta per la maggior parte di codice scritto da altri. Quando in quel codice si scopre una falla, diventa pubblica — e chi attacca la legge prima di te.

7 minSviluppatori, CTO, chi mantiene un'applicazione

Cosa portare a casa

Risposta breve

Ogni applicazione usa decine o centinaia di librerie di terzi. Quando in una di esse si scopre una vulnerabilità, viene registrata in database pubblici (come OSV o gli avvisi ufficiali) insieme alla versione che la corregge. Da quel momento la falla è nota a tutti: chi difende deve aggiornare, chi attacca deve solo cercare chi non l'ha fatto. È la voce «componenti vulnerabili e obsoleti» della classifica OWASP 2021, e si controlla con un comando.

La maggior parte del codice di un'app moderna non l'ha scritto chi l'ha costruita: sono librerie di terzi.

Le falle di quelle librerie sono pubbliche: chi attacca legge l'elenco e cerca chi non ha ancora aggiornato.

Il controllo è un comando (npm audit e simili, o i database OSV): dice quali dipendenze hanno falle note e la versione che le corregge.

È un lavoro continuo, non una tantum: le falle note oggi non sono quelle di fra tre mesi.

Data Hub

CONSOO

Torna alle guide

Il vantaggio è di chi legge l'elenco per primo

C'è un paradosso nella sicurezza delle dipendenze: rendere pubblica una falla insieme alla correzione serve a proteggere, ma nell'intervallo fra la pubblicazione e il vostro aggiornamento il vantaggio è di chi attacca. Lui non deve scoprire nulla: apre il database delle vulnerabilità note, vede che una certa libreria in una certa versione ha un buco, e cerca in rete tutti i siti che usano ancora quella versione. Voi, per stare al sicuro, dovete accorgervene e aggiornare prima che tocchi a voi in quella ricerca.

Il controllo, in pratica

  1. 01

    Lanciate il controllo del vostro gestore di pacchetti

    Nell'ecosistema JavaScript è «npm audit»; altri linguaggi hanno l'equivalente. Confronta le vostre dipendenze con i database delle falle note e vi dice quali sono coinvolte.

  2. 02

    Leggete gravità e versione che corregge

    Per ogni falla il report indica quanto è grave e in quale versione è risolta. È la vostra lista di aggiornamenti, già ordinata per urgenza.

  3. 03

    Aggiornate, ma con una rete

    Aggiornare una libreria può cambiarne il comportamento: fatelo avendo dei test o un ambiente di prova, così un aggiornamento di sicurezza non ne rompe il funzionamento.

  4. 04

    Automatizzatelo

    Il vero valore è ripeterlo da solo: esistono strumenti che eseguono il controllo a ogni modifica e vi avvisano quando esce una falla nuova su una libreria che usate. È così che il lavoro continuo smette di dipendere dalla memoria.

Le trappole da conoscere

  • Le dipendenze delle dipendenze: una libreria che usate ne usa altre, e la falla è spesso in una di quelle indirette, che non avete scelto voi ma che è comunque nel vostro sistema.
  • L'aggiornamento che rompe: la paura di rompere qualcosa è il motivo più comune per cui non si aggiorna. Si supera con i test, non rimandando.
  • La libreria abbandonata: se chi la manteneva non la aggiorna più, la prossima falla non verrà mai corretta. Va sostituita, ed è meglio saperlo prima.
  • Il falso allarme: non ogni falla segnalata è sfruttabile nel vostro caso. Valutarlo richiede giudizio, ma il punto di partenza resta vedere l'elenco.

Risorse collegate utili

Domande frequenti

Se il comando non segnala nulla, sono a posto?

Sulle falle note in quel momento, sì, ed è una buona notizia. Ma «note in quel momento» è la chiave: domani può emergere una vulnerabilità su una libreria che oggi risulta pulita. Per questo il controllo va ripetuto con regolarità, idealmente automatizzato, non fatto una volta e archiviato.

Ho un'app vecchia con dipendenze molto datate: aggiorno tutto insieme?

È lo scenario più delicato: aggiornare librerie ferme da anni tutte insieme rompe spesso qualcosa, perché nel frattempo sono cambiate molto. Conviene procedere per priorità — prima le falle gravi e sfruttabili — e con una rete di test. È anche il caso in cui un test di sicurezza aiuta a capire quali aggiornamenti sono urgenti davvero e quali possono aspettare.

Vale anche per chi non sviluppa in casa ma ha commissionato l'app?

Sì, ed è una domanda giusta da fare al vostro fornitore: chi controlla le dipendenze, ogni quanto, e cosa succede quando esce una falla grave su una libreria che usiamo? Se la risposta è vaga, avete trovato un rischio che non dipende da quanto è ben scritta l'app, ma da come viene mantenuta.

Non sapete chi controlla le dipendenze della vostra app, né ogni quanto? È una domanda che vale un incidente. Guardiamo insieme come siete messi. Consulenza gratuita.

CONSOO trasforma idee su software, AI e integrazioni in un percorso tecnico chiaro per PMI.

  • 30 minuti, online
  • Nessun impegno
  • Analisi del tuo caso reale
  • Risposta entro 24 ore