La supply chain software è un rischio di board, non un problema DevOps

Tre incidenti in dieci giorni rivelano una fragilità sistemica che la governance aziendale continua a trattare come questione tecnica

Venticinque validatori, zero controlli dove conta

Venticinque controlli di sicurezza attivi nel runtime. Nessun controllo sul processo di pubblicazione. Risultato: oltre mezzo milione di righe di codice sorgente finiscono su un registry pubblico per un errore umano nel workflow di rilascio. Non un attacco sofisticato. Non un exploit zero-day. Un processo banale, non governato, che ha esposto ciò che doveva restare protetto.

Questo episodio non è isolato. In una finestra di dieci giorni si sono verificati tre incidenti distinti nella catena di fornitura software globale: una GitHub Action malconfigurata in uno strumento di sicurezza ampiamente adottato, la compromissione dell'account di un singolo maintainer di una libreria con oltre settantamila dipendenze dirette, e la pubblicazione accidentale di codice proprietario. Voci autorevoli del settore, tra cui Rami McCarthy, Principal Security Researcher presso Wiz, e Jun Zhou, Full Stack Engineer presso Straiker, convergono su un punto: il problema non è il singolo incidente. È un'infrastruttura globale costruita su superfici di fiducia che nessuno verifica sistematicamente. Un errore in un nodo si propaga a cascata sull'intero ecosistema.

Il blast radius è enterprise-wide

Settantamila dipendenze dirette significano una cosa concreta: codice malevolo può entrare silenziosamente in ambienti di produzione attraverso aggiornamenti automatici, senza che nessun team interno se ne accorga. Le evidenze di settore più recenti indicano che il 65% delle organizzazioni nel 2025 dichiara di aver subito un attacco attraverso la propria catena di fornitura software. Non è un dato tecnico. È un dato di continuità operativa.

Per un board, la questione si traduce in termini diretti: esposizione a rischi che il management potrebbe non sapere nemmeno di avere. La visibilità sulle dipendenze transitive, quelle librerie che non avete scelto voi, ma che sono incorporate nelle librerie che avete scelto, è quasi sempre insufficiente. Nessun registro aggiornato. Nessuna mappa delle criticità. Nessuna ownership definita. Se domani una di queste dipendenze viene compromessa, chi nel vostro organigramma ne risponde? Chi la conosce? Chi sa che esiste? Il rischio non è ipotetico. È strutturale e già prezzato nelle statistiche, ma non ancora nei vostri comitati rischi.

Velocità contro controllo: la frizione che nessuno governa

La tensione reale è tra la velocità dei workflow di sviluppo e la capacità delle pratiche di sicurezza di governarli. Le workstation degli sviluppatori sono oggi zone ad alta fiducia e bassa visibilità. Con l'adozione crescente di AI coding agent, l'esposizione si amplifica: questi strumenti operano con accesso diretto a file system, shell, rete e server MCP. Il blast radius di una compromissione non è più limitato a un pacchetto software. È l'intera postazione dello sviluppatore, e da lì, potenzialmente, l'ambiente di produzione.

La governance della pipeline CI/CD viene ancora trattata nella maggior parte delle organizzazioni come un problema DevOps. Una questione di configurazione, di tooling, di automazione. Ma quando il danno si materializza, un rilascio contaminato, un dato esposto, un servizio interrotto, la responsabilità non ricade sul team DevOps. Ricade sul management. Sulla direzione. Sul board che non ha chiesto visibilità su un processo che attraversa l'intera catena del valore. La delega esiste nei fatti, ma l'accountability rimane in alto. Senza che in alto si sappia cosa è stato delegato.

NIS2 e DORA: la supply chain software è già nel perimetro normativo

L'articolo 21, paragrafo 2, lettera d) della Direttiva NIS2 è esplicito: le misure di gestione del rischio devono includere la sicurezza della catena di approvvigionamento, compresi gli aspetti relativi ai rapporti tra ciascun soggetto e i suoi diretti fornitori o prestatori di servizi. Dipendenze software non governate, processi di pubblicazione non controllati, assenza di visibilità sulle componenti transitive: tutto ciò ricade direttamente nel perimetro dell'obbligo. Non è un'interpretazione estensiva. È la lettera della norma.

Per il settore finanziario, il Regolamento DORA rafforza il quadro imponendo la gestione del rischio ICT derivante da terze parti, incluse le dipendenze software critiche. Con la crescita esponenziale dell'uso di componenti open source nelle pipeline AI, il rischio di concentrazione su singoli maintainer volontari diventa un tema di stabilità operativa regolamentata. L'AI Act, dal canto suo, introduce obblighi di governance per i sistemi AI in fase di sviluppo e deployment, e quegli stessi sistemi poggiano su catene di dipendenze che nessuno sta mappando con la granularità richiesta dalla norma.

La domanda che il board non si è ancora posto

L'infrastruttura software globale dipende in larga misura dal lavoro volontario di singoli maintainer. Un account compromesso propaga codice malevolo a decine di migliaia di progetti. Non è uno scenario teorico: è accaduto, ripetutamente, in dieci giorni. Tim Mackey, Head of Software Supply Chain Risk Strategy presso Black Duck, lo ha detto con chiarezza: la terza versione più recente è spesso la più sicura, il che smonta la narrazione semplicistica dell'"aggiornare tutto subito". Il problema è più profondo. Riguarda la conoscenza stessa di ciò che è in esecuzione nei vostri ambienti, e la capacità di governarlo.

La domanda che ogni membro del board dovrebbe porsi non è se la vostra organizzazione utilizza dipendenze open source. La risposta è sì, senza eccezioni. La domanda è un'altra: se domani il maintainer volontario di una libreria che attraversa il vostro intero stack viene compromesso, il vostro board sa che quella dipendenza esiste? E soprattutto, chi ne risponde?

Il rischio della supply chain software non si gestisce con un audit annuale o un tool in più nella pipeline. Si gestisce sapendo cosa non sapete. E quella è una conversazione che non può restare confinata in un canale Slack di engineering.