Cosa si nasconde nel tuo codice?

Tutti i messaggi

Anche i progetti più semplici tendono a crescere rapidamente e questa tendenza è amplificata dalla facilità di incorporare pezzi di codice o librerie di nodi esistenti.

È ancora in qualche modo gestibile quando sei l'unico a scrivere quel codice, ma diventa più difficile quando il codice viene scritto da un numero di sviluppatori e team, come avviene normalmente.

Anche il team leader, colui che ha il compito di approvare tutte le richieste pull, non può conoscere ogni riga di codice, ogni funzione e ogni variabile.

Una questione di fiducia

Questo è uno dei motivi per cui è avvenuta una piccola modifica al codice nell'app Orion alla fine del 2020, nel caso successivamente noto come vento solare, è passato inosservato per così tanto tempo. L'intera modifica consisteva in poche dozzine di righe di codice, ed erano molto buone nascosto all'interno della classe originale.

Il prodotto modificato era firmato correttamente, quindi non c'era motivo di sospettarlo e i team di sviluppo si fidavano del proprietario del codice.

Solo di recente abbiamo appreso che NPM aveva un “difetto logico" che ha consentito ad autori malintenzionati di spacciare librerie canaglia come legittime. Fondamentalmente, NPM consentiva di aggiungere chiunque come manutentore di un pacchetto senza avvisare questi utenti o ottenere il loro consenso. 

Ciò ha consentito di creare pacchetti contenenti malware e di assegnarli a manutentori affidabili e famosi a loro insaputa. Un caso di fiducia malriposta potrebbe significare una vulnerabilità problematica nascosta nel tuo codice.

Un'altra pratica comune da considerare è che gli sviluppatori copiano e incollano il codice dalle librerie esistenti o da StackOverFlow per utilizzarlo nel proprio codice o per ricaricarlo in nuove librerie. Ciò aumenta la possibilità di copiare anche codice non sicuro e vulnerabile che ora è sostanzialmente non tracciato. Anche se il codice originale riceve un CVE ed eventualmente una riparazione, la funzione problematica che hai copiato è invisibile e potrebbe contaminare qualsiasi base di codice che la utilizzerebbe negli anni a venire. 

In un recente studio condotto presso l’Università del Kansas (“Cos'è la Forchetta? Trovare cloni di codice nascosti in npm”), i ricercatori illustrano come l’utilizzo anche di pacchetti completamente controllati possa essere pericoloso.

Cosa si può fare?

Pertanto, non puoi fidarti dei prodotti firmati e degli aggiornamenti dei fornitori. Il tuo codice potrebbe essere già stato modificato o aggiunto, a causa di tutte quelle librerie esterne e del codice incorporato al suo interno. Cosa puoi fare, quindi, per essere veramente sicuro di non installare file dannosi nel tuo sistema?

Ci sono alcune cose che puoi fare:

  1. Richiedi una SBOM completa a ciascun proprietario di libreria o fornitore di programmi che incorpori. Una SBOM può aiutarti a verificare quali siano tutti gli "ingredienti" nella libreria o nel prodotto. Inoltre, se trovi qualcosa nella libreria o nel prodotto che non è elencato nella SBOM, dovrebbe essere considerato sospetto. Puoi saperne di più su cos'è una SBOM qui.
  2. Richiedi un'attestazione attendibile al venditore o al proprietario della biblioteca che sia stato effettuato un controllo di integrità e che stai ottenendo ciò che ti aspetti. Non dovresti fidarti solo della garanzia del venditore.
  3. Durante l'installazione dei pacchetti utilizzare il flag CLI npm --ignore-scripts per evitare di eseguire script da pacchetti di terze parti durante la fase di installazione.
  4. Utilizzare Pacchetto-lock.json file per bloccare i numeri di versione del pacchetto. Quando usi a Pacchetto-lock.json non blocchi solo le versioni del pacchetto che stai utilizzando, ma blocchi anche le loro dipendenze. Il rischio è che non verranno inseriti aggiornamenti automatici del pacchetto che potrebbero includere correzioni a vari bug. Ma, se ti sei impegnato per verificare una determinata versione e non vuoi includere nient'altro senza prima verificarla, bloccare i numeri di versione è l'opzione migliore.

A seguire nuove regole, si prevede che la maggior parte delle persone inizierà a utilizzare le SBOM in un futuro molto prossimo. Più aziende richiederanno SBOM e altri attestati, più organizzazioni e manutentori dovranno conformarsi.

Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.