Gestione sicura delle dipendenze

Le applicazioni moderne importano centinaia di pacchetti di terze parti. Ogni dipendenza, comprese le dipendenze transitive, amplia la superficie di attacco. Una vulnerabilità in una libreria diffusa, come Log4Shell in Log4j, può esporre migliaia di applicazioni contemporaneamente.

I file di lock (package-lock.json, yarn.lock, Pipfile.lock) fissano ogni dipendenza a una versione esatta, incluse le dipendenze transitive. Eseguire il commit dei file di lock nel controllo versione. In questo modo si garantiscono build riproducibili e si impediscono aggiornamenti accidentali delle versioni che introducono vulnerabilità.

Gli strumenti SCA analizzano gli alberi delle dipendenze confrontandoli con i database CVE per identificare i pacchetti vulnerabili. OWASP Dependency-Check, Snyk e GitHub Dependabot rilevano automaticamente le vulnerabilità note e suggeriscono versioni con patch, fornendo indicazioni per la correzione.

Dependabot e Renovate Bot aprono automaticamente PR quando sono disponibili nuove versioni compatibili che non introducono modifiche incompatibili. Danno priorità agli aggiornamenti di sicurezza. Configurare l'unione automatica per gli aggiornamenti delle patch con CI superata, così da mantenere aggiornate le dipendenze riducendo al minimo l'intervento manuale.

Prima di aggiungere una dipendenza, verifichi il numero di download, l'attività recente dei commit, il numero di issue aperte, la compatibilità della licenza e lo storico delle CVE note. Preferisca pacchetti ben mantenuti, con processi attivi di risposta agli incidenti di sicurezza, rispetto ad alternative non mantenute.

Le dipendenze dirette includono a loro volta altre dipendenze. Nell'incidente event-stream, gli aggressori hanno preso il controllo di una dipendenza transitiva utilizzata da milioni di pacchetti. Verifichi l'intero albero delle dipendenze, non solo quelle dirette.

Gli attacchi di dependency confusion consistono nel pubblicare pacchetti dannosi su registry pubblici con lo stesso nome dei pacchetti interni. Li mitighi usando nomi di pacchetto con scope, l'autenticazione al registry privato e una allowlist dei registry approvati in .npmrc o pip.conf.

Una Software Bill of Materials (SBOM) è un inventario leggibile dalle macchine di tutti i componenti del software. Generi SBOM con Syft o CycloneDX. Le SBOM consentono di valutare rapidamente l'impatto delle vulnerabilità quando vengono pubblicate nuove CVE: permettono di identificare le versioni interessate in pochi minuti.

Le licenze OSS impongono determinati obblighi. La GPL può richiedere la divulgazione del codice sorgente. MIT e Apache 2.0 sono permissive. FOSSA e TLDR-Legal aiutano a valutare la compatibilità delle licenze. Integri la scansione delle licenze nella CI per impedire l'inclusione accidentale di GPL nei prodotti commerciali.

La Subresource Integrity (SRI) per gli script ospitati su CDN usa un hash crittografico nell'attributo integrity. npm package.json include un campo integrity. Verifichi i checksum durante il download dei pacchetti nella CI per rilevare manomissioni della catena di fornitura.

Applichi le patch di sicurezza entro 24-48 ore dalla pubblicazione della CVE per le vulnerabilità critiche. Usi i punteggi CVSS e i dati sulla sfruttabilità per stabilire le priorità. Una dipendenza corretta che introduce una modifica incompatibile è preferibile a una vulnerabilità sfruttabile in produzione.

Che cos'è un attacco di dependency confusion?

Una gestione sicura delle dipendenze richiede il blocco delle versioni nei file di lock, l'esecuzione della scansione SCA nella CI/CD, l'automazione degli aggiornamenti delle patch, la generazione di SBOM per valutare l'impatto e la valutazione del livello di sicurezza delle nuove dipendenze prima di adottarle.