Dependabot will drop Python 3.9 support: what to check before the deadline

From 23 June 2026, GitHub Dependabot will no longer support Python 3.9. A practical checklist for software, DevOps and security teams that need to avoid disruptions in dependency updates.

A deprecation that only looks small

GitHub has announced in its changelog that from 23 June 2026 Dependabot will no longer support Python 3.9, a version that has reached end of life. The operational message is clear: according to GitHub, if a project continues to use Python 3.9, there is a risk that Dependabot will stop creating pull requests to update dependencies.

At first glance, this may seem like a minor change. It concerns one specific Python version and an automation tool already familiar to teams working on GitHub. In practice, it touches a sensitive part of software maintenance: the connection between application runtimes, dependency management tools and automated security controls.

Dependabot is often part of DevSecOps processes used to detect library updates, security patches and compatible new versions. If the project runtime is no longer supported, the automation may become less reliable or stop producing the expected updates. For an organisation, this means that an apparently “platform-level” detail can create a gap in software supply chain security.

The point is not to upgrade Python simply because a new version exists. The point is to avoid leaving part of the maintenance chain anchored to an unsupported technical base while internal policies, audits and metrics still assume that automated updates are working.

What changes for software, DevOps and security teams

The most immediate impact concerns Python repositories that declare or use Python 3.9 in configuration files, pipelines or container images. Checking application code is not enough: the runtime version may appear in pyproject.toml, setup.cfg, runtime.txt, Dockerfiles, GitHub Actions workflows, CI templates, base images and test environments.

For DevOps teams, the deadline requires a compatibility check across the whole pipeline. Upgrading the local runtime while leaving a container image based on Python 3.9 can create inconsistent behaviour. Similarly, a test matrix that includes only obsolete versions may prevent teams from properly validating a move to Python 3.10, 3.11, 3.12, 3.13 or 3.14, depending on library compatibility and operational constraints.

For security teams, the risk is more organisational than technical: a repository may still be considered “covered by Dependabot” even when the automation no longer produces pull requests. This creates a false sense of control. In vulnerability management programmes, the presence of a tool should not be confused with the effectiveness of the control.

For IT and governance leaders, the deprecation is a practical lifecycle management case. Every EOL runtime should be visible in a centralised risk view: which systems use it, which assets are exposed, which critical dependencies cannot be updated, which exceptions have been approved and until when. Without this discipline, end-of-support deadlines become technical emergencies instead of planned maintenance activities.

Operational checklist before 23 June 2026

The first activity is to identify affected repositories. Searching for the version string across GitHub repositories can reveal explicit references to Python 3.9, but this is not enough. It is useful to combine code search, dependency graph data, container image inventories and CI/CD pipeline information. In enterprise environments, the inventory should also cover internal repositories, shared templates and company libraries reused across multiple products.

The second activity is to define a supported target version. Jumping directly to the latest available release is not always the best choice: the decision should balance library compatibility, production constraints, cloud provider support, available base images, internal policies and the team’s ability to test regressions. GitHub notes that, as of May 2026, the latest supported Python version is 3.14, but the organisational choice must reflect the application context.

The third activity is to update and validate pipelines. This includes automated tests, linting, container builds, security scanners, staging environments and scheduled jobs. If Dependabot is configured with specific rules, grouped updates, version limits or private registries, teams should verify that it continues to operate after the runtime change.

The fourth activity is to measure whether the control has actually been restored. After the upgrade, a green build is not enough. Teams should verify that Dependabot still generates pull requests, that security alerts are correct, that private dependencies remain reachable and that approval processes do not block urgent patches. From Dedaloop’s perspective, this is a good opportunity to turn a one-off intervention into a recurring rule: EOL runtime dashboards, periodic checks on base images, minimum versioning policies and reports for technical owners.

In Cloud managed services & DevOps, this type of control is part of ordinary platform maintenance: observable pipelines, planned updates and verifiable automation. In more exposed architectures, the issue also connects to Cybersecurity and cloud infrastructure, because outdated dependencies and unsupported runtimes increase supply chain risk.

Mistakes to avoid and governance criteria

The first mistake is treating the deprecation as a single-repository issue. In many organisations, Python 3.9 may be present in shared libraries, golden images, data processing jobs, serverless functions, internal tools and automation scripts. A partial upgrade reduces risk but does not remove blind spots.

The second mistake is focusing only on application compatibility. The question is not just “does the software work with a newer version?” but also “do the security and maintenance tools still work?”. Dependabot, SCA scanners, SBOM processes, merge policies and CI checks are part of the quality system, not optional extras.

The third mistake is failing to formalise exceptions. If a system must temporarily remain on Python 3.9 due to real constraints, the exception should have an owner, an expiry date, a reason, compensating controls and a remediation roadmap. Otherwise, it becomes permanent technical debt.

The broader lesson is that platform tool deprecations should be embedded into IT governance. An effective technology roadmap does not only look at new features; it also manages the orderly removal of what is no longer supported. Strategic IT advisory and governance activities can help define clear criteria: which versions are allowed, when a migration plan is triggered, which KPIs measure exposure to EOL runtimes and who decides priorities.

The deadline set by GitHub does not require panic, but it does require method. Teams using Python 3.9 with Dependabot still have time to act. The value lies in not stopping at the upgrade: inventory, update, verify the automation and make the control repeatable.

Approfondimenti Dedaloop

Fonti