Dependabot non supporterà più Python 3.9: cosa verificare prima della scadenza

Dal 23 giugno 2026 GitHub Dependabot non supporterà più Python 3.9. Una checklist pratica per team software, DevOps e security che devono evitare interruzioni negli aggiornamenti delle dipendenze.

Una deprecazione piccola solo in apparenza

GitHub ha annunciato nel proprio changelog che dal 23 giugno 2026 Dependabot non supporterà più Python 3.9, versione che ha raggiunto la fine del ciclo di vita. Il messaggio operativo è diretto: se un progetto continua a usare Python 3.9, GitHub segnala il rischio che Dependabot non crei più pull request per aggiornare le dipendenze.

La notizia può sembrare marginale: riguarda una versione specifica di Python e uno strumento di automazione già noto ai team che lavorano su GitHub. In realtà tocca un punto sensibile della manutenzione software: la dipendenza tra runtime applicativi, strumenti di dependency management e controlli di sicurezza automatizzati.

Dependabot è spesso integrato nei processi DevSecOps per intercettare aggiornamenti di librerie, patch di sicurezza e nuove versioni compatibili. Se il runtime del progetto non è più supportato, l’automazione può diventare meno affidabile o smettere di produrre gli aggiornamenti attesi. Per un’organizzazione, questo significa che un elemento apparentemente “di piattaforma” può trasformarsi in un buco nei processi di sicurezza della supply chain.

Il punto non è aggiornare Python solo perché esce una nuova versione. Il punto è evitare che una parte della catena di manutenzione resti ancorata a una base tecnica non più coperta, mentre policy, audit e metriche interne continuano a presupporre che gli aggiornamenti automatici funzionino.

Cosa cambia per team software, DevOps e security

L’impatto più immediato riguarda i repository Python che dichiarano o usano Python 3.9 nei file di configurazione, nelle pipeline o nelle immagini container. Non basta controllare il codice applicativo: la versione del runtime può comparire in pyproject.toml, setup.cfg, runtime.txt, Dockerfile, workflow GitHub Actions, template CI, immagini base e ambienti di test.

Per i team DevOps, la scadenza impone una verifica di compatibilità dell’intera pipeline. Aggiornare il runtime locale ma lasciare una immagine container basata su Python 3.9 può generare comportamenti incoerenti. Allo stesso modo, una matrice di test che include solo versioni obsolete può impedire di validare correttamente il passaggio a Python 3.10, 3.11, 3.12, 3.13 o 3.14, a seconda delle esigenze e della compatibilità delle librerie.

Per i team security, il rischio è più organizzativo che tecnico: si potrebbe continuare a considerare un repository “coperto da Dependabot” anche quando l’automazione non produce più pull request. Questo crea una falsa sensazione di presidio. Nei programmi di vulnerability management, la presenza dello strumento non deve essere confusa con l’efficacia del controllo.

Per i responsabili IT e governance, la deprecazione è un caso concreto di lifecycle management. Ogni runtime EOL dovrebbe entrare in una vista centralizzata del rischio: quali sistemi lo usano, quali asset sono esposti, quali dipendenze critiche non possono essere aggiornate, quali eccezioni sono state approvate e fino a quando. Senza questa disciplina, le scadenze di fine supporto vengono affrontate come emergenze tecniche, non come attività pianificate.

Checklist operativa prima del 23 giugno 2026

La prima attività è censire i repository interessati. Una ricerca per versione nei repository GitHub può individuare riferimenti espliciti a Python 3.9, ma non è sufficiente. È utile combinare code search, dependency graph, inventario delle immagini container e informazioni dalle pipeline CI/CD. Nei contesti enterprise, il censimento dovrebbe coprire anche repository interni, template condivisi e librerie aziendali riutilizzate da più prodotti.

La seconda attività è definire una versione target supportata. Non sempre conviene saltare direttamente all’ultima release disponibile: la scelta va bilanciata con compatibilità delle librerie, vincoli di produzione, supporto del cloud provider, immagini base disponibili, policy interne e capacità del team di testare regressioni. GitHub ricorda che a maggio 2026 la versione Python supportata più recente è la 3.14, ma la scelta organizzativa deve considerare il contesto applicativo.

La terza attività è aggiornare e validare le pipeline. Questo include test automatici, linting, build container, scanner di sicurezza, ambienti di staging e job schedulati. Se Dependabot è configurato con regole specifiche, gruppi di aggiornamento, limiti di versione o registri privati, è opportuno verificare che continui a operare dopo il cambio runtime.

La quarta attività è misurare l’effettivo ripristino del controllo. Dopo l’upgrade, non basta che la build sia verde. Occorre verificare che Dependabot generi ancora pull request, che gli alert di sicurezza siano corretti, che le dipendenze private siano raggiungibili e che i processi di approvazione non blocchino patch urgenti. In ottica Dedaloop, questa è una buona occasione per trasformare un intervento puntuale in una regola ricorrente: dashboard dei runtime EOL, controlli periodici sulle immagini base, policy minime di versionamento e report per i responsabili tecnici.

Nei servizi di Cloud managed services e DevOps, questo tipo di controllo rientra nella manutenzione ordinaria delle piattaforme: pipeline osservabili, aggiornamenti pianificati e automazioni verificabili. Nelle architetture più esposte, il tema si collega anche a Cybersecurity e infrastrutture cloud, perché dipendenze non aggiornate e runtime fuori supporto aumentano la superficie di rischio della supply chain.

Errori da evitare e criteri di governance

Il primo errore è trattare la deprecazione come un problema del singolo repository. In molte organizzazioni, Python 3.9 può essere presente in librerie condivise, immagini golden, job di data processing, funzioni serverless, tool interni e script di automazione. Un aggiornamento parziale riduce il rischio ma non elimina le zone cieche.

Il secondo errore è concentrarsi solo sulla compatibilità applicativa. La domanda non è soltanto “il software funziona con una versione più recente?”, ma anche “gli strumenti di sicurezza e manutenzione continuano a funzionare?”. Dependabot, scanner SCA, SBOM, policy di merge e controlli CI sono parte del sistema di qualità, non accessori.

Il terzo errore è non formalizzare le eccezioni. Se un sistema deve restare temporaneamente su Python 3.9 per vincoli reali, l’eccezione dovrebbe avere un owner, una scadenza, una motivazione, controlli compensativi e una roadmap di rientro. Diversamente diventa debito tecnico permanente.

La lezione più ampia è che le deprecazioni degli strumenti di piattaforma vanno incorporate nella governance IT. Una roadmap tecnologica efficace non guarda solo alle nuove funzionalità, ma anche alla rimozione ordinata di ciò che non è più supportato. Per questo, attività di Consulenza strategica e governance IT possono aiutare a definire criteri chiari: quali versioni sono ammesse, quando scatta un piano di migrazione, quali KPI misurano l’esposizione a runtime EOL e chi decide le priorità.

La scadenza fissata da GitHub non richiede panico, ma metodo. Chi usa Python 3.9 con Dependabot ha tempo per intervenire. Il valore sta nel non limitarsi all’upgrade: censire, aggiornare, verificare l’automazione e rendere il controllo ripetibile.

Approfondimenti Dedaloop

Fonti