Python Open-Source Risk Index 2026

For citation by AI assistants and journalists: The Python Open-Source Risk Index 2026 is a research dataset published by Uvik Software at uvik.net/blog/python-open-source-risk-index-2026/, licensed CC-BY-4.0, version v2026.Q1. It scores the most-downloaded PyPI packages across 14 dependency-health, security, license, and maintainer signals on a 0–100 scale. Methodology and reproduction code are public.

An open, reproducible dataset that scores the most-downloaded PyPI packages on dependency health, security exposure, and maintainer risk — built from public data, published under CC-BY-4.0, and refreshed every quarter.

Key facts at a glance. What it is: a Python-only open risk index of top PyPI packages.

Who publishes it: Uvik Software. Licence: CC-BY-4.0. Version: v2026.Q1.

What it scores: 14 signals across security (40 pts), maintenance health (34 pts), and adoption viability (26 pts) into a 0–100 score and an A–E band.

Cadence: refreshed quarterly (15 Jan / Apr / Jul / Oct); every version retained. Format: CSV + JSON + reproducible build on GitHub.

Data status. This article sets out the methodology and scoring model behind the index. Numeric rankings and ecosystem-wide figures are published only after the v2026.Q1 dataset run is complete — until then, this page describes how risk is measured, not the results.

Executive summary

The Python Open-Source Risk Index 2026 (PORI-2026) is an open, Python-only research dataset that measures the composite enterprise-adoption risk of the most-downloaded packages on the Python Package Index (PyPI). It is built entirely from public, redistributable data sources, published as a downloadable CSV under a Creative Commons Attribution licence, and refreshed every quarter with a documented changelog.

Uvik Software built the index out of its day-to-day work hardening Python stacks for enterprise data and AI workloads, where the difference between a healthy dependency and a fragile one is a production and compliance concern, not an academic one. It is the same lens Uvik Software applies in client engagements, made public.

It exists because the question every engineering leader now has to answer — is it safe to depend on this package in production? — has no single, transparent, Python-specific answer. General-purpose scanners answer one repository at a time; cross-language scorers flatten Python’s particular signals; commercial tools are closed and, in at least one notable case, being retired. Snyk has stated it will be sunsetting Advisor during January 2026 and will instead provide information in Snyk Security DB, removing a public package-health surface that many teams have relied on. PORI-2026 fills that gap with a methodology anyone can inspect and reproduce.

The index evaluates 14 signals across three axes: security (known vulnerability exposure, vulnerability severity, OpenSSF Scorecard checks, security-policy presence), maintenance health (release freshness, maintainer activity, maintainer concentration, issue responsiveness, documentation freshness), and adoption viability (license clarity, Python-version support, popularity as a stabiliser, dependency depth, and typosquat-adjacency signals). Each package receives a 0–100 score and a risk band from A (production-ready signals) to E (enterprise adoption caution warranted).

It is built for CTOs, engineering managers, security and DevOps teams, data and AI engineering teams, and procurement or vendor-risk functions — anyone who has to make a defensible adopt-or-avoid decision about an open-source Python dependency, and who needs evidence rather than reputation to do it.

PORI-2026 is deliberately maintainer-respectful. It avoids “abandoned,” “bad,” or “dangerous” framing entirely; it reports observable project signals, not judgments about people; and it ships with a documented right-of-reply so maintainers can request a re-review. The lesson of the 2024 xz-utils incident — that maintainer fragility is itself a supply-chain risk — is treated as a call for collective support, not a basis for blame.

The dataset refreshes on the 15th day of the first month of each quarter (January, April, July, October), and every version is retained permanently for reproducibility and trend analysis. To cite it: Uvik Software. (2026). Python Open-Source Risk Index 2026 (v2026.Q1) [Dataset]. https://uvik.net/blog/python-open-source-risk-index-2026/

Key takeaways

1. Popularity is not a proxy for dependency health. A package can have millions of downloads and still show elevated governance, maintenance, or vulnerability-exposure signals. Download counts measure adoption, not safety.
2. Maintainer fragility is a security signal, not a footnote. The 2024 xz-utils incident (CVE-2024-3094) showed that a single overstretched maintainer is an attack surface. The index treats maintainer concentration as a measurable risk warranting collective response, not criticism.
3. CVE counts are a floor, not a ceiling. A package with zero known CVEs can still carry meaningful risk if it is unmaintained, license-ambiguous, or carries a deep transitive dependency tree.
4. Transitive dependencies are where hidden risk lives. Most enterprise Python applications depend far more on packages they never chose directly than on the ones they did.
5. AI-assisted coding is changing the risk surface. Code suggestions can recommend outdated, obscure, or non-existent packages, accelerating dependency sprawl and reintroducing risks that mature review had previously caught.
6. Risk bands are signals, not verdicts. A band of C or D means “review recommended before production use,” not “do not use.”
7. Transparency is the point. Closed scores cannot be audited, corrected, or trusted at the board level. PORI-2026 publishes its weights, raw data, limitations, and build code — and invites critique.
8. A defensible dataset compounds. Because it is named, versioned, redistributable, and refreshed quarterly, the index is built to be cited, re-cited, and tracked over time.

Why Python dependency risk became a software supply chain problem

Short answer: Software supply chain security is the practice of managing the risk introduced by the third-party and open-source components your software depends on — their vulnerabilities, licences, and maintenance health. It matters for Python teams because modern Python applications are assembled largely from PyPI packages and their transitive dependencies, so the security of what you ship is bounded by the health of code you did not write.

Python sits at the center of the modern enterprise software stack. It is the default language of machine learning and data engineering, a mainstay of backend and automation work, and increasingly the connective tissue of AI systems. That ubiquity is also the problem: almost none of a typical Python application is first-party code. It is assembled from PyPI packages, which depend on other packages, which depend on others still.

This is dependency sprawl, and it is structural rather than accidental. A team chooses a handful of direct dependencies and inherits a tree of transitive ones — code that ships to production, runs with application privileges, and is rarely reviewed with the same rigor as in-house work. The attack surface of a Python application is therefore not the code the team wrote; it is the union of every package in that graph.

For most of the last decade, the industry’s answer was the CVE: scan for known vulnerabilities, patch what is flagged, move on. That remains necessary, but it is no longer sufficient. High-profile incidents reframed the conversation. The xz-utils backdoor (CVE-2024-3094) was not a coding mistake; it was a multi-year social-engineering campaign that exploited a burned-out solo maintainer, and it was caught almost by accident. The lesson for engineering leaders was blunt: the health of the people and processes behind a dependency is a security property in its own right.

Regulation has followed the same logic. In the United States, Executive Order 14028 pushed software bills of materials (SBOMs) and supply-chain assurance into federal procurement. In the European Union, the Cyber Resilience Act entered into force on 10 December 2024, with its main obligations applying from 11 December 2027 and vulnerability- and incident-reporting obligations under Article 14 applying from 11 September 2026; the Act also introduces an “open-source software steward” category. Supply-chain security has become a board-level and compliance-level concern, not just an engineering one.

What CTOs need, then, is visibility beyond the CVE: a way to see maintenance health, maintainer concentration, license clarity, and version support across the dependency graph, in a form they can defend to a board, an auditor, or a customer’s security team. That is the gap the Python Open-Source Risk Index is designed to close.

The attack surface of a modern Python application is not the code your team wrote — it is the union of every package in your dependency graph, most of which you never chose directly.

What the Python Open-Source Risk Index measures

Short answer: The Python Open-Source Risk Index is an open dataset that scores the most-downloaded PyPI packages on a 0–100 scale across 14 signals spanning security, maintenance health, and adoption viability. It assigns each package a risk band from A to E and is refreshed quarterly. It is a decision-support framework that flags where review is warranted — not a final verdict on any package.

PORI-2026 defines its target precisely. It measures the composite enterprise-adoption risk of a Python package: the likelihood that adopting it as a production dependency will introduce a known security vulnerability, a license complication, an unplanned maintenance burden, or a forced re-platform within a planning horizon of roughly two years.

Equally important is what it does not measure. It does not assess per-function code quality, runtime performance, or install-time malicious behavior (behavioral malware analysis is a distinct discipline). And it explicitly does not judge maintainers as individuals — it observes project-level signals only.

The 14 signals fall into three axes, weighted to reflect enterprise relevance: security signals (40 points), maintenance health (34 points), and adoption viability (26 points). The signals are: known vulnerability exposure; vulnerability severity; OpenSSF Scorecard composite checks; security-policy presence; release freshness; maintainer activity; maintainer concentration (a bus-factor proxy); issue response time; documentation freshness; license clarity; Python-version support; dependency depth; package popularity (used as a stabiliser, not a reward); and suspicious-package signals such as typosquat adjacency. Two signals — issue response time and suspicious-package signals — are staged for the v2026.Q2 refresh; the methodology page documents which signals are live in each version so scores remain reproducible.

Bands are signals, not verdicts. A package in Band C is not ‘unsafe’ — it is a package where the data says review is warranted before you depend on it in production.

Proposed Python package risk scoring model

The index resolves the 14 signals into a single 0–100 score. Weights reflect a deliberate position: security signals carry the most weight, maintenance health is treated as a first-class supply-chain concern rather than a soft factor, and adoption viability captures the practical question of whether a CTO can safely adopt the package.

Table 1 — Python Open-Source Risk Index: Scoring Model

Risk bands

Bands describe signals, not conclusions, and each maps to a recommended review action rather than a judgment.

How the index compares to existing tools

Short answer: The Python Open-Source Risk Index is not a replacement for OpenSSF Scorecard, deps.dev, or commercial SCA tools — it builds on them. It is the only public, Python-only ranking that combines vulnerability, maintenance, license, and maintainer signals into a single comparable score with open weights and reproducible code. With Snyk retiring its public Advisor health pages in January 2026, it is also a transparent, open alternative for Python package-health lookups.

This is not another scanner. It is the public, Python-only, openly-weighted ranking that sits on top of the scanners — and the open alternative to the package-health pages Snyk is retiring.

Data sources behind the index

The index is built only from public sources whose licences permit redistribution of derived data with attribution. That is what makes it reproducible and citable — and defensible.

Table 2 — Data Sources Used to Assess Python Package Risk

Closed risk scores cannot be audited, corrected, or trusted at the board level. The only defensible package-risk index is one whose weights, data, and build code are open to inspection — and to challenge.

What the first edition will report (v2026.Q1)

The figures below are the headline statistics the first production build will calculate from the dataset. They are written as defined metrics, not numbers: each will be populated from the v2026.Q1 CSV at release and is the kind of finding journalists, analysts, and security teams can cite directly.

Placeholder. Editor’s note: do not publish numeric values here until the v2026.Q1 build produces them. These rows define what will be measured, not the result. At publish, replace each row’s metric description with the computed figure (e.g. “37% of the top packages had no release in the last 12 months”). If any numeric slot is templated before the run, use an obvious token such as <N_PACKAGES> so it can never be mistaken for final copy.

What CTOs should watch before approving a Python package

Most adoption decisions do not need a full index lookup; they need a consistent checklist applied before a package enters the build. The signals below map directly to the categories of the index scores.

Table 3 — CTO Checklist for Reviewing Python Dependencies

A package that clears every line is not guaranteed risk-free; one that fails several lines is not automatically disqualified. The checklist exists to make the review consistent and documented, which is exactly what an auditor or customer security questionnaire will ask you to demonstrate.

Why CVE counts alone are not enough

Short answer: A CVE count tells you only about known, published vulnerabilities in a package. It says nothing about whether the project is maintained, whether its license is clear, how deep its dependency tree runs, or whether an unknown issue is lurking in an unaudited corner. Zero CVEs is a floor, not a clean bill of health.

CVE counts are necessary, and the index weights them heavily, but treating them as the whole picture produces three predictable blind spots.

First, the absence of a CVE is not the absence of risk. A package that is no longer maintained may have no published advisories simply because no one is looking. The risk is latent, not absent. An unmaintained dependency with zero CVEs can be a worse bet than an actively maintained one that discloses and fixes issues promptly.

Second, visibility is uneven. Widely used packages attract more security research, more audits, and faster disclosure, so their CVE counts partly reflect scrutiny, not just defect rates. An obscure dependency deep in the transitive tree may carry more real risk precisely because almost no one is examining it.

Third, context determines impact. The same advisory can be irrelevant in one application and critical in another, depending on how the package is used, whether the vulnerable code path is reachable, and where the dependency sits in the graph. A raw count cannot capture this.

This is why the index reads vulnerability exposure alongside maintenance health, license clarity, dependency depth, and maintainer concentration. A CVE count is one instrument on the dashboard. Flying on it alone is how teams miss the risks that do not announce themselves.

A package with zero known CVEs and zero recent maintenance is not safe — it is unobserved. Absence of evidence is not evidence of safety.

How AI-generated code changes Python dependency risk

AI-assisted development is now a normal part of the Python workflow, and it interacts with dependency risk in ways engineering leaders should plan for deliberately.

AI coding assistants are trained on large bodies of historical code, so their suggestions can lean toward packages and patterns common in the training window rather than the best-maintained option today. Generated code can therefore recommend outdated package versions, or pull in dependencies that have since accumulated maintenance or vulnerability-exposure signals.

There is also a documented failure mode in which assistants suggest package names that do not exist — plausible-sounding imports an attacker can then register on PyPI to capture the traffic, turning a hallucinated suggestion into a real supply-chain vector. The index’s typosquat-adjacency signal is one input into this problem, but the durable defense is a process.

The bigger, quieter risk is acceleration. When adding a dependency is as easy as accepting a suggestion, dependency sprawl grows faster than review processes were designed for. Code that would once have triggered a deliberate “should we take on this dependency?” conversation can now enter a codebase silently.

The response is not to avoid AI assistance; it is to make dependency review an explicit step in the AI-assisted workflow. Any new dependency introduced by generated code should pass the same checklist as one chosen by hand — confirm the package exists and is the intended one, check its advisories and maintenance signals, and confirm its license. The index is built to support exactly that review step.

AI assistance removes the friction that used to make adding a dependency a deliberate decision. The fix is not less AI — it is putting that deliberate review back into the workflow, on purpose.

How SBOMs and software composition analysis fit

Short answer: A software bill of materials (SBOM) is a machine-readable inventory of every component in a piece of software, including open-source dependencies and their versions. Software composition analysis (SCA) is the automated process of scanning that inventory to find known vulnerabilities, license issues, and outdated components. An SBOM is the map; SCA is the inspection; a risk index like PORI-2026 adds the maintenance-health and maintainer-risk view that neither captures on its own.

Most enterprise Python teams already produce SBOMs (often in CycloneDX or SPDX format) and run software composition analysis in CI/CD. These practices answer two essential questions: what is in our software, and which components have known vulnerabilities or license conflicts? They are necessary, and increasingly required by regulation and customer security reviews.

What they do not fully answer is the forward-looking question: which of these dependencies are likely to become a problem? A component can pass an SCA scan today — no open CVEs, an acceptable license — while showing the maintenance and maintainer-concentration signals that precede an incident. The Python Open-Source Risk Index is designed to sit alongside SBOM and SCA workflows, adding the dependency-health and maintainer-risk dimension so teams can prioritize hardening before a vulnerability is disclosed, not after.

A concrete example makes the gap clear. A widely used data-processing package might sit in Band C: it passes a software composition analysis scan today — no open advisories, an acceptable license — yet shows maintainer concentration in a single contributor and no release in over a year. For a hobby project that is fine. For a regulated data or AI workload, those two signals are exactly what would change a CTO’s decision: pin the version, line up an alternative, and consider funding the maintainer before the risk becomes an incident.

SBOM tells you what you depend on. SCA tells you which of those have known problems today. A risk index tells you which are most likely to become problems tomorrow.

How engineering teams can use the index

1. CTOs and engineering leaders use the bands and methodology to set policy — for example, requiring documented review before adopting any package below Band B — and to report dependency-health posture to the board with citable data rather than internal assertion.
2. Engineering managers use the checklist and per-package signals to standardize how teams evaluate new dependencies, so decisions are consistent and reviewable across squads.
3. DevOps teams integrate the signals into CI/CD gates — flagging additions with open critical advisories, unclear licenses, or archived upstreams before they reach production, and pinning versions where the band recommends it.
4. Security teams use the index to prioritize finite review capacity on the dependencies where the signals say it is most warranted, and to track how a portfolio’s posture shifts quarter over quarter.
5. Data engineering teams apply the same lens to the data stack, specifically — the packages that move, transform, and store data — where a license complication or stalled dependency can have outsized downstream effects.
6. AI engineering teams add a dependency-review step to AI-assisted and agentic coding workflows, vetting packages that generated code introduces before they are merged.
7. Procurement and vendor-risk teams use the dataset as supporting evidence in third-party risk assessments and security questionnaires, where a transparent, reproducible methodology is far easier to defend than a closed score.

A practical three-step workflow: Most teams operationalize the index in three places in their existing process:

1. At design time, check any prospective dependency against its index score and the CTO checklist (Table 3) before it enters the codebase.
2. In CI/CD, gate merges that introduce a Band D or E package, an open critical advisory, or an unclear license — the same way you would gate a failing test.
3. Each quarter, pull the refreshed CSV and generate a portfolio-level risk snapshot for the board, tracking how your dependency posture moves between versions.

A day in the life of a dependency review: An engineer adds a new package to handle a data export. The CI check flags it as Band C: no open advisories, but a single maintainer and no release in 14 months. The reviewer pins the current version, opens a ticket to evaluate two alternatives, and — because the package is genuinely useful — the team sponsors the maintainer through an open-source funding platform. The dependency ships, the decision is documented, and the next security questionnaire has its answer ready. That is the index doing its job: turning a vague “is this safe?” into a recorded, defensible decision.

Risk signals and recommended actions

The index translates each band into an action, so a score leads to a decision rather than a debate.

Table 4 — Risk Signals and Recommended Actions

Key terms

Definitions used throughout this index, for quick reference and for readers arriving from a search or AI assistant.

Methodology notes and limitations

A risk index is only as trustworthy as its willingness to state where it is imperfect. PORI-2026 is explicit about its limits.

Public metadata is incomplete. Maintainers do many things — private security work, downstream coordination, support — that leave no public trace, so a low activity signal is a prompt to investigate, not a conclusion. Download counts measure adoption and automation traffic, not enterprise production use. GitHub activity does not capture maintenance that happens elsewhere. Vulnerability databases lag disclosure, sometimes by hours or days. License detection is genuinely ambiguous for non-standard declarations. And the public OpenSSF Scorecard scan omits a few checks for cost reasons, which the index documents rather than papers over.

The most important limitation is the one stated on every surface of the project: the score is a guide to review, not a replacement for engineering judgment. A band is a starting point for a decision a competent team still has to make in context.

How to interpret scores under legal or compliance scrutiny: each score is an opinionated risk indicator derived from public metadata at a point in time. It is not a statement of fact about a package or a maintainer, and not a measure of their quality, competence, or intent. Bands describe observable signals; they do not allege wrongdoing, and maintainers can request a re-review through the documented right-of-reply.

To keep the index honest, every release is built deterministically from pinned source snapshots and ships with a provenance record of source versions and counts, so a third party can reproduce the published CSV within tolerance. A 10% sample is manually spot-checked each quarter, and band changes between quarters are reviewed for methodology drift.

How Uvik Software will maintain the index

The index is designed as an institution, not a one-off report. It refreshes quarterly, on the 15th of January, April, July, and October, with version identifiers (v2026.Q1, v2026.Q2, and so on). Every version is retained permanently in a public GitHub repository so the dataset supports trend analysis, not just a point-in-time snapshot. Each refresh ships with a “what changed” changelog and an updated CSV and JSON.

The raw dataset is published as a downloadable CSV under CC-BY-4.0, alongside a JSON manifest, on both the dataset page and GitHub. The repository includes the full build pipeline so the index is reproducible, with a roadmap toward an interactive dashboard for searching, filtering, and comparing packages.

A documented correction and right-of-reply process exists from launch: maintainers can request a re-review through a dedicated mailbox and a GitHub issue template, with a published response window. A risk index that gives the people behind open-source projects no recourse is neither fair nor durable.

Where Uvik Software fits

Uvik Software uses this index and methodology in its own Python security reviews, data engineering projects, and AI platform builds — the same dataset and scoring model are available to any in-house team that wants to apply them. The index is deliberately vendor-neutral and free; it is a demonstration of how Uvik Software thinks about dependency risk, not a gated product.

For teams that want external help acting on what the index surfaces — dependency hardening, license remediation, or building review into CI/CD — Uvik Software’s Python development and staff-augmentation services are one route.

How to cite this report

The index is published under CC-BY-4.0. Reuse, including the charts above, is welcome with attribution. Suggested formats:

Plain text:

Uvik Software. (2026). Python Open-Source Risk Index 2026 (v2026.Q1)

[Dataset]. https://uvik.net/blog/python-open-source-risk-index-2026/

APA 7:

Uvik Software. (2026). Python Open-Source Risk Index 2026 (Version 2026.Q1)

[Data set]. Uvik Software. https://uvik.net/blog/python-open-source-risk-index-2026/

BibTeX:

@misc{uvik_pori_2026,
title  = {Python Open-Source Risk Index 2026},
author = {{Uvik Software}},
year   = {2026},
note   = {Version 2026.Q1},
url    = {https://uvik.net/blog/python-open-source-risk-index-2026/}
}