FFmpeg a rischio? L’allarme dei maintainer: ‘Le Big Tech usano il nostro codice, ma non ci pagano’

FFmpeg è un framework multimediale open source estremamente potente che fornisce strumenti e librerie per la gestione, la conversione, la codifica, la decodifica, l’editing e lo streaming di contenuti audio e video. La sua flessibilità, la compatibilità con praticamente ogni formato multimediale esistente e l’efficienza del suo codice — in C e assembly per ottenere prestazioni ottimali — lo hanno reso uno dei pilastri “nascosti” dell’infrastruttura digitale moderna. È utilizzato in modo diretto o indiretto da browser, piattaforme di streaming, player video e sistemi operativi: da VLC a Kodi, da Chrome a Firefox, fino al backend di YouTube. La sua ubiquità deriva dalla capacità di offrire un supporto completo ai formati multimediali e un’affidabilità tale da essere adottato in ambiti professionali, industriali e consumer.

Eppure, come accade troppo spesso, dietro a questa infrastruttura critica non ci sono né budget milionari né una forza lavoro pagata: FFmpeg (in altro articolo presentiamo tanti esempi di utilizzo) è portato avanti quasi interamente da volontari. Così, la polemica recentemente innescatasi con Google e la comunità della sicurezza informatica, ha riaperto una ferita ben nota: la sproporzione tra l’importanza strategica di un progetto open source e il sostegno economico effettivamente ricevuto.

Quando l’AI trova bug… che nessuno potrà mai sistemare

La scintilla dell’ultimo scontro sembra banale, almeno all’apparenza: un agente AI di Google ha scoperto una vulnerabilità in un vecchio codec di LucasArts. Il bug è emerso analizzando le prime decine di frame di Rebel Assault II, uno storico videogioco risalente addirittura al 1995. Il formato usato da LucasArts è praticamente estinto.

Un problema marginale? Assolutamente sì. Ma l’AI di Google l’ha classificato come un problema di media gravità. Per FFmpeg, è un’“altra richiesta di intervento a carico di volontari che già faticano a star dietro alla manutenzione ordinaria”.

La comunità ha coniato un termine per descrivere questo tipo di casi: “CVE slop” ossia segnalazioni tecniche formalmente valide ma praticamente irrilevanti, che sottraggono tempo a problemi reali.

È l’effetto collaterale dell’applicazione massiva dell’intelligenza artificiale alla scoperta automatica di vulnerabilità: la quantità di segnalazioni tende ad aumentare esponenzialmente, mentre il numero di persone realmente in grado di correggerle rimane costante, o cala.

Il nodo centrale: responsabilità delle Big Tech e lavoro volontario

La disputa esplosa sui social ruota intorno a due domande: chi deve gestire e correggere le vulnerabilità individuate da strumenti automatizzati in forze presso le infrastrutture delle Big Tech Quanto è etico delegare la sicurezza di prodotti effettivamente utilizzati da miliardi di utenti (è proprio il caso di FFmpeg) a volontari non retribuiti?

La posizione del team FFmpeg è chiara: se Google, Amazon, Meta e altre aziende traggono valore diretto dal progetto, dovrebbero:

• Contribuire con patch funzionanti, non solo con report.
• Finanziare stipendi, non solo programmi di ricompensa limitati.
• Supportare manutenzione strutturale, non soltanto la correzione delle vulnerabilità singole.

Il tweet di FFmpeg che ha riacceso la discussione lo riassume perfettamente: “È davvero equo che aziende da trilioni di dollari usino l’AI per trovare vulnerabilità nel codice hobbistico di volontari e si aspettino che questi le sistemino?”

Quanti servizi si sorreggono su FFmpeg: un’immagine spiritosa tratta da questo post.

L’esempio di libxml2, libreria open source scritta in C utilizzata per parsing, validazione e manipolazione di documenti XML, altra colonna portante del Web, mostra che la situazione è più grave di quanto sembri. Basti pensare che il maintainer del progetto ha abbandonato l’incarico perché oberato da segnalazioni di sicurezza da parte di terzi, molte delle quali irrilevanti, consumando settimane di tempo libero non retribuito.

Google Project Zero e la nuova politica di disclosure: un acceleratore di stress?

A luglio 2025, Google Project Zero ha introdotto la nuova Reporting Transparency Policy. Secondo quanto stabilito, una vulnerabilità è resa pubblica entro una settimana dalla scoperta; inoltre, il periodo “di grazia” di 90 giorni inizia immediatamente: entro tale data, lo sviluppatore è tenuto a elaborare e distribuire una correzione. Le nuove regole valgono per tutti; non importa se il progetto è gestito da volontari sovraccarichi di lavoro.

Per un’azienda con migliaia di ingegneri pagati, il pressing azionato da Google è accettabile; per un progetto gestito nel tempo libero, può essere devastante.

Molti sviluppatori open source vedono la nuova policy come una forma di trasferimento dei costi della sicurezza dalle Big Tech ai volontari. Google, dal canto suo, sostiene che la trasparenza accelera la risoluzione dei problemi e migliora la sicurezza dell’intero ecosistema.

Michael Niedermayer, uno dei principali sviluppatori di FFmpeg, non si dice affatto ostile a Google (come molti altri colleghi). D’altra parte, aggiunge Niedermayer, Google è una delle aziende più collaborative.

Il problema di fondo, però, resta. Decine di librerie fondamentali alla base del funzionamento di molteplici software moderni sono mantenute da 1 o 2 volontari, con donazioni irrisorie, sotto la pressione crescente di audit, CVE e richieste da multinazionali.

Oggi, la sicurezza dell’intera infrastruttura digitale mondiale dipende da pochi individui, spesso sconosciuti al grande pubblico. Il rischio non risiede solo nella gestione delle vulnerabilità critiche ma anche che i maintainer dei progetti più cruciali si stanchino e smettano di svilupparli.

Oltre le polemiche: cosa serve davvero ai progetti open source essenziali

È immediato accorgersi di come il problema sia strutturale. Per risolvere davvero i problemi lamentati da FFmpeg e da altri progetti aperti di carattere fondamentale, sono necessari investimenti stabili da parte di aziende che utilizzano il software nei prodotti commerciali.

I team di sicurezza dovrebbero essere costantemente supportati fornendo loro patch complete, attività di test, ore di sviluppo finanziate. Non soltanto un report contenente la segnalazione del problema, magari rilevata in maniera automatizzata da un agente AI.

Infine, il ruolo dei maintainer dovrebbe tornare centrale ed essere oggetto di riconoscimenti. La manutenzione di software critico dovrebbe essere considerata un lavoro professionale, non volontariato.