// 1 CRITICAL · 2 ZERO-DAY · 4 CVE · 3 EXPLOIT NELLE ULTIME 24H
Akrites porta 19 big tech sotto un unico SIRT per vulnerabilità open source. Il 5% di patch rate e la confessione di Dolan: la strada è in salita.

Il 25 giugno 2026 la Linux Foundation ha lanciato Akrites, un'iniziativa multi-stakeholder che istituisce un Security Incident Response Team condiviso e un processo di divulgazione coordinata delle vulnerabilità orientato alla confidenzialità. La mossa risponde a un dato che i fondatori giudicano insostenibile: secondo l'amministratore delegato di Endor Labs, Varun Badhwar, meno del 5% delle vulnerabilità open source validate negli ultimi mesi ha ricevuto una patch. L'obiettivo è comprimere la finestra temporale tra scoperta e correzione, ma un dirigente della stessa Linux Foundation ammette che "lo spazio è affollato e il track record è misto".

Punti chiave
  • Akrites opera come "maintainer of last resort" per pacchetti critici abbandonati, intervenendo dove il mantenitore originale manca.
  • Il finanziamento seed proviene da Alpha-Omega, fondo diretto della Linux Foundation già attivo su sicurezza della supply chain.
  • Diciannove organizzazioni fondatrici includono AWS, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft/GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone e Zscaler.
  • Il progetto si colloca in un campo già occupato: la coalizione Athena di Chainguard, annunciata due settimane prima, persegue obiettivi analoghi con membri sovrapposti.

Un SIRT centralizzato contro la velocità delle AI offensive

Il cuore operativo di Akrites è un SIRT condiviso che gestisce un processo di Coordinated Vulnerability Disclosure con primato della confidenzialità. La logica è rovesciata rispetto al modello tradizionale: invece di pubblicare la vulnerabilità e attendere la patch, Akrites mira a pre-posizionare le correzioni prima della divulgazione pubblica.

La necessità di questo capovolgimento emerge da una citazione attribuita alla Linux Foundation nel comunicato ufficiale: "Quando le patch vengono rilasciate pubblicamente, gli avversari possono utilizzare l'intelligenza artificiale per reverse-engineeringare rapidamente le vulnerabilità sottostanti, sviluppare exploit e lanciare attacchi". Secondo la fonte, il parametro di successo sarà il dispiegamento delle patch, non la loro pubblicazione.

Jim Zemlin, amministratore delegato della Linux Foundation, ha portato questa diagnosi all'estremo in un intervento all'UN Open Source Week: il tempo medio per l'exploit di una vulnerabilità software sarebbe sceso a "meno sette giorni". Il claim, riportato da DevOps.com, non è verificato indipendentemente nel dossier; resta un indicatore della percezione d'urgenza che guida l'iniziativa.

Il 5% di patch rate e il disallineamento uomo-macchina

Il dato più citato nei materiali di lancio è anche il più inquietante. Badhwar, la cui azienda Endor Labs è tra i fondatori, afferma che "delle migliaia di vulnerabilità open source validate emerse nei mesi recenti, meno del 5% sono state patchate". La fonte non specifica il periodo di riferimento esatto né la metodologia di conteggio; il numero tuttavia è riprodotto coerentemente tra SD Times e il comunicato PRNewswire.

La discrepanza strutturale che Akrites tenta di colmare è quella tra velocità di scoperta e capacità di risposta. L'intelligenza artificiale accelera entrambi i lati del confronto — la ricerca sistematica di flaw e l'ingegneria inversa delle patch — ma i progetti open source mantenuti da volontari o sottofinanziati non dispongono di risorse per tenere il passo. Il risultato è un crescente arsenale di vulnerabilità conosciute e sfruttabili.

Akrites non risolve il deficit di manodopera: lo gestisce esternalizzando la risposta. Il SIRT interverrà direttamente sui pacchetti abbandonati, assumendo il ruolo di mantenitore quando l'originale cessa l'attività. Il meccanismo solleva questioni di governance non dettagliate nelle fonti: chi decide quali progetti sono "critici", chi assume la responsabilità legale delle patch distribuite, come si concilia l'intervento top-down con l'autonomia della comunità.

Il giudizio interno: "lo spazio è affollato, il track record è misto"

La lettura più interessante del dossier proviene da Mike Dolan, Senior Vice President of Legal della Linux Foundation, in un'intervista a DevOps.com. Dolan non nasconde la cautela: "Lo spazio è affollato, e il track record è misto". Ciò che distingue Akrites, secondo lui, è "stretto: un unico processo coordinato, così che i maintainer open source affrontino un singolo partner invece di cento segnalatori separati".

"I maintainer meritano un partenariato coordinato, non un'alluvione di segnalazioni" — Matt Wilson, VP and Distinguished Engineer, AWS

La citazione di Wilson, riportata da Help Net Security, traduce in termini operativi il problema che Dolan identifica: la moltiplicazione di attori che scoprono e segnalano vulnerabilità senza coordinamento sovraccarica i maintainer, spesso volontari, con richieste duplicate e standard incompatibili. Akrites promette di funzionare da interfaccia unificata, filtrando e standardizzando l'intake.

La cautela di Dolan tuttavia pone un interrogativo che le fonti non chiariscono: se il track record delle iniziative analoghe è misto, cosa garantisce che maggiore scala corporativa produca maggiore efficacia? Il dossier non contiene metriche preliminari né un piano di valutazione indipendente.

Athena, Lightwell e il rischio di proliferazione

Akrites non arriva su un terreno vuoto. Due settimane prima del suo annuncio, Chainguard aveva presentato Athena, una coalizione con obiettivi sovrapposti; diversi membri di Athena sono confluiti nei fondatori di Akrites. DevOps.com cita anche Project Lightwell come terzo attoore nel medesimo spazio. La fonte non chiarisce se le tre iniziative convergeranno o competiranno.

Questa proliferazione rispecchia una dinamica ricorrente nella sicurezza open source: la risposta a una crisi di coordinamento genera ulteriore frammentazione. Ogni iniziativa introduce standard, processi e membership propri, aumentando la complessità per i maintainer che dovrebbero essere i beneficiari finali. Akrites promette di ridurre questa complessità per i singoli progetti, ma il suo stesso esistere la aumenta a livello di ecosistema.

Il settore target è ampio: finanza, sanità, energia, telecomunicazioni, governo e infrastrutture AI, secondo Help Net Security. Questa ampiezza riflette la dipendenza universale da componenti open source, ma espone anche il progetto a tensioni tra interessi corporativi potenzialmente confliggenti. Il dossier non documenta meccanismi di arbitraggio tra i fondatori.

Perche e importante

Akrites rappresenta un test sulla capacità dell'industria di auto-organizzare risposte strutturali a minacce che superano i singoli operatori. Il 5% di patch rate citato da Endor Labs, se confermato da metriche indipendenti, indicherebbe un fallimento sistematico della risposta alle vulnerabilità che non può essere attribuito a singoli progetti o maintainer.

Il dossier tuttavia lascia aperti punti critici. La fonte non specifica l'architettura tecnica della piattaforma di intake delle vulnerabilità, i criteri di selezione dei pacchetti "critici" da tutelare, il quadro di responsabilità legale per le patch distribuite dal SIRT, né l'interazione con l'infrastruttura CVE/CNA esistente gestita da MITRE. Questi limiti rendono impossibile valutare se Akrites sarà operativamente efficace o un altro strato di coordinamento istituzionale.

Il confronto implicito con Athena e Project Lightwell solleva un interrogito più ampio: la sicurezza della supply chain open source richiede più iniziative con più logo corporate, o una governance più radicale dei processi esistenti? La Linux Foundation, attraverso Dolan, ammette che il problema non è la scarsità di iniziative. La posta in gioco è se Akrites riesca a essere l'eccezione che rende superflue le altre, o l'ennesima eccezione che le moltiplica.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. securityweek.com
  2. helpnetsecurity.com
  3. unit42.paloaltonetworks.com
  4. sdtimes.com
  5. prnewswire.com
  6. techzine.eu
  7. devops.com