Il Rischio di Licenza Nascosto Nelle Vostre Installazioni Homebrew

Quasi tutte le conversazioni sulla sicurezza di Homebrew finiscono per parlare di CVE e strumenti pericolosi. Quasi nessuna arriva a parlare di licenze — finché l'ufficio legale non trova una libreria con licenza copyleft dentro un prodotto commerciale, di solito durante un audit o, peggio, durante la due diligence di un'acquisizione.

È un pessimo momento per scoprirlo. Ed è anche del tutto evitabile.

Il rischio che nessuno sorveglia

Quando uno sviluppatore installa un pacchetto, accetta implicitamente la licenza con cui viene distribuito, che se ne renda conto o no. Il più delle volte non è un problema: MIT, Apache, BSD. A volte lo è. Una dipendenza con licenza GPL o AGPL comporta obblighi legali reali su come potete distribuire il software che la utilizza — e questi obblighi non chiedono il permesso prima di attaccarsi al vostro codice.

Ciò che coglie impreparate la maggior parte delle aziende: raramente si tratta del pacchetto installato direttamente dallo sviluppatore. È qualcosa da cui quel pacchetto dipende silenziosamente. Nessuno l'ha scelto, nessuno l'ha controllato — e quando emerge durante un audit, è già integrato in un prodotto già distribuito.

I controlli a livello di pacchetto non lo intercettano, perché rispondono alla domanda sbagliata. Bloccare nmap perché è uno strumento di scansione di rete è una decisione di sicurezza su uno strumento specifico. Niente in quel modello sorveglia una clausola di licenza sepolta tre dipendenze più in basso.

Perché diventa costoso

Il rischio di licenza non si manifesta come un incidente. Si manifesta come un'acquisizione che si blocca, un rilievo di conformità senza soluzione semplice, o un ordine al team di ingegneria di rimuovere e sostituire una dipendenza dopo che il prodotto è già stato rilasciato. Tutto questo è molto più difficile e costoso che impedire l'installazione fin dall'inizio. E non è una decisione che l'IT può prendere da sola: quali licenze siano accettabili lo decide il legale.

Questo è il vero problema: il legale definisce la policy, ma non ha modo di farla rispettare nell'unico momento in cui conta davvero — quello dell'installazione.

Colmare il vuoto

EnterpriseBrew trasforma una policy sulle licenze in qualcosa che viene davvero applicato, non in un documento che nessuno consulta. Il team legale decide quali condizioni di licenza sono inaccettabili — GPL, AGPL, qualunque cosa dica la policy — e ogni installazione in tutta l'azienda viene controllata automaticamente rispetto a quella regola, incluso tutto ciò che quel pacchetto trascina silenziosamente con sé. Potete anche lavorare al contrario: definire le licenze approvate, e tutto il resto viene bloccato di default.

Qualunque modello scegliate, è una regola valida per tutta l'azienda, non un'impostazione di team da cui qualcuno può escludersi. Un'eccezione di sicurezza per un ingegnere ha senso. Un'eccezione legale per un solo laptop no — l'obbligo nasce nel momento in cui il codice viene usato, non nel momento in cui qualcuno se ne accorge.

Il risultato

Invece di scoprire un problema di licenza dopo che il prodotto è già stato rilasciato, quel pacchetto semplicemente non viene mai installato. Il legale definisce la policy una sola volta. L'IT non deve sorvegliarla manualmente, e gli sviluppatori non devono diventare esperti di licenze per restare conformi — il controllo avviene automaticamente, prima che qualcosa raggiunga una macchina.

Il prossimo audit non è più una corsa contro il tempo per scoprire cosa è installato e a cosa vi espone. La risposta è già applicata in partenza.