ChatGPT 
Summary
Key takeaways
- The Python AI Dependency Security Index 2026 examines 21 Python packages across seven AI, data, backend, observability, and document-processing categories.
- The index separates six risk dimensions: repository security practices, known vulnerability exposure, maintenance health, dependency structure, release compatibility, and transparency.
- It does not publish a simple cross-package ranking because most packages lack enough exact-version evidence for a defensible overall score.
- Pydantic 2.13.4 is the only package in version 1.0 that meets the complete evidence gate, receiving a score of 90.5 and a Lower observable risk classification.
- The Pydantic result is a triage signal, not a security certification, penetration test, or guarantee that the package is safe in every application.
- Twenty of the 21 indexed package versions were released within 90 days of the August 2, 2026 capture date, but release recency alone does not prove security or healthy governance.
- OpenSSF Scorecard values apply to source repositories and development practices, not exclusively to the exact package version installed in a production environment.
- Vulnerability findings must be connected to the exact installed version, affected-version range, remediation state, and reachability of the vulnerable code.
- Missing evidence remains unknown rather than being converted into a failing score, which prevents incomplete data from creating misleading rankings.
- Engineering teams should use the index to prioritize dependency reviews while still performing lockfile analysis, software composition analysis, threat modeling, testing, and supplier assessment.
When this applies
This applies when an engineering team is reviewing the security and maintenance posture of Python dependencies used in AI applications, RAG systems, agents, APIs, data pipelines, model infrastructure, evaluation platforms, or document-processing workflows. It is especially relevant during framework upgrades, dependency modernization, supplier reviews, security audits, Python runtime migrations, or due diligence on inherited systems. The index can help teams identify which packages require deeper investigation and which evidence should be collected before approving a dependency for production use.
When this does not apply
This does not apply as a standalone package-selection tool, security certification, penetration test, or replacement for environment-specific risk analysis. A package with a high repository score may still be unsuitable for a particular application, while a package with a known advisory may already have a fixed version or may not expose the vulnerable code path in the deployed environment. The index should also not be used to claim that one package is categorically safer than another when the available evidence does not meet the same scoring threshold.
Checklist
- Record the exact installed package version rather than reviewing only the project or repository name.
- Generate a complete lockfile or environment inventory covering direct, optional, and transitive dependencies.
- Check whether the installed version falls inside any published affected-version range.
- Confirm whether a patched version or documented mitigation is available.
- Determine whether the vulnerable component or code path is reachable in your deployed environment.
- Review dated OpenSSF Scorecard evidence as a repository-practice signal rather than package-version proof.
- Check release recency, changelog quality, compatibility history, and maintainer response patterns.
- Verify the minimum and maximum supported Python versions before planning runtime upgrades.
- Confirm the package license expression and investigate ambiguous or unconfirmed licensing metadata.
- Review dependency graph size, update frequency, optional extras, native components, and environment markers.
- Check whether the project publishes a security policy and a clear vulnerability-reporting process.
- Review available documentation, issue trackers, release notes, and maintainer communication channels.
- Document business-critical exceptions and any compensating security controls.
- Run software composition analysis, automated tests, security scans, and application-specific threat modeling.
- Require human approval before converting incomplete evidence into a package-risk decision or overall score.
Common pitfalls
- Treating a repository-level OpenSSF Scorecard value as proof that a specific package release is secure.
- Comparing advisory counts without checking the exact installed version and affected-version range.
- Assuming that a recently published release automatically indicates strong maintenance or security governance.
- Penalizing packages for missing public evidence as though missing data proved poor security.
- Treating a large dependency graph as automatically unsafe without considering update practices and compensating controls.
- Ignoring optional and transitive dependencies that are present in the real production environment.
- Comparing one fully scored package with unscored packages and presenting the result as a market ranking.
- Overlooking Python runtime compatibility when upgrading AI frameworks and backend dependencies.
- Silently normalizing unclear license metadata instead of preserving and investigating the ambiguity.
- Using the index as a substitute for code review, penetration testing, supplier review, contractual support, or environment-specific risk assessment.
Original package-risk research by Uvik Software
Research disclosure: Uvik Software publishes this research and provides Python modernization, security and AI engineering services. No package maintainer can pay for inclusion, a higher score or a more favorable classification.
Executive answer: Version 1.0 indexes 21 Python packages across seven AI, data and backend categories. All 21 have a verified PyPI version record, 20 have a confirmed license expression or license family, and 20 published the indexed release within 90 days of capture. Repository-level OpenSSF Scorecard snapshots were captured for 7 records. Pydantic is the only record that currently meets the complete scoring-evidence gate, with an overall score of 90.5 and a Lower observable risk band. The index does not publish a cross-package ranking or certify security.
What this index measures
The index separates six observable dimensions: repository security practices, known vulnerability exposure, maintenance health, dependency structure, release compatibility and transparency. These signals answer different questions and remain visible independently. A package with a reported advisory is not automatically less responsible than a package that has received less scrutiny, and a strong repository score does not prove that a specific release is safe in a particular application.
Key findings
- 21 package records: three packages in each of seven categories.
- 20 recent releases: the indexed version was published within 90 days of the 2 August 2026 capture date.
- 20 confirmed license records: one package remains conservatively labeled as unconfirmed from the retrieved public metadata.
- 7 captured Scorecard snapshots: repository-level evidence is dated and never presented as package-version proof.
- 1 scored record: Pydantic reaches 100% evidence coverage and receives a 90.5 overall score in the Lower observable risk band.
- No cross-package ranking: 20 records remain unscored because their exact-version vulnerability or dependency evidence does not meet the per-record gate.
Packages in the dataset
| Package | Category | Indexed version | Release date | Python | License | OpenSSF snapshot | Source |
|---|---|---|---|---|---|---|---|
| langchain | LLM and agents | 1.3.14 | 2026-07-16 | <4.0.0, >=3.10.0 | MIT | 5.9/10 (2026-06-15) | PyPI |
| langgraph | LLM and agents | 1.2.10 | 2026-07-28 | >=3.10 | MIT | Not captured | PyPI |
| crewai | LLM and agents | 1.15.10 | 2026-07-31 | <3.14, >=3.10 | Not confirmed from retrieved PyPI metadata | Not captured | PyPI |
| llama-index | RAG and vector search | 0.14.23 | 2026-06-24 | <4.0, >=3.10 | MIT | Not captured | PyPI |
| chromadb | RAG and vector search | 1.5.9 | 2026-05-05 | >=3.9 | Apache-2.0 | Not captured | PyPI |
| qdrant-client | RAG and vector search | 1.18.0 | 2026-05-11 | >=3.10 | Apache-2.0 | Not captured | PyPI |
| transformers | Model and ML | 5.14.1 | 2026-07-16 | >=3.10.0 | Apache-2.0 | 7.6/10 (2026-06-08) | PyPI |
| torch | Model and ML | 2.13.0 | 2026-07-08 | >=3.10 | Apache-2.0 AND Apache-2.0 WITH LLVM-exception AND BSD-2-Clause AND BSD-3-Clause AND BSL-1.0 AND MIT | Not captured | PyPI |
| sentence-transformers | Model and ML | 5.6.1 | 2026-07-23 | >=3.10 | Apache-2.0 | 5.7/10 (2026-06-22) | PyPI |
| apache-airflow | Data and orchestration | 3.3.0 | 2026-07-06 | !=3.15, >=3.10 | Apache-2.0 | 7.2/10 (2026-06-15) | PyPI |
| prefect | Data and orchestration | 3.8.1 | 2026-07-30 | <3.15, >=3.10 | Apache-2.0 | Not captured | PyPI |
| dask | Data and orchestration | 2026.7.1 | 2026-07-14 | >=3.10 | BSD-3-Clause | 6.3/10 (2025-12-01) | PyPI |
| fastapi | Web and APIs | 0.141.1 | 2026-07-29 | >=3.10 | MIT | Not captured | PyPI |
| pydantic | Web and APIs | 2.13.4 | 2026-05-06 | >=3.9 | MIT | 7.4/10 (2026-06-08) | PyPI |
| uvicorn | Web and APIs | 0.52.1 | 2026-08-01 | >=3.10 | BSD-3-Clause | 7.0/10 (2026-06-08) | PyPI |
| langfuse | Evaluation and observability | 4.14.2 | 2026-07-30 | <4.0, >=3.10 | MIT | Not captured | PyPI |
| deepeval | Evaluation and observability | 4.1.5 | 2026-07-31 | <4.0, >=3.9 | Apache-2.0 | Not captured | PyPI |
| ragas | Evaluation and observability | 0.4.3 | 2026-01-13 | >=3.9 | Apache License (exact SPDX not confirmed) | Not captured | PyPI |
| pypdf | Document processing | 6.14.2 | 2026-06-23 | >=3.9 | BSD-3-Clause | Not captured | PyPI |
| unstructured | Document processing | 0.25.0 | 2026-07-31 | <3.14, >=3.11 | Apache-2.0 | Not captured | PyPI |
| docling | Document processing | 2.117.0 | 2026-07-30 | <4.0, >=3.10 | MIT | Not captured | PyPI |
The table is a dated snapshot, not a recommendation list. Package versions can change after capture, and repository-level Scorecard values can change between weekly scans.
Why one security number is dangerous
OpenSSF Scorecard evaluates observable repository and build practices. OSV aggregates vulnerability records and affected-version information. deps.dev resolves package relationships and publishes project associations. PyPI supplies package, release and compatibility metadata. None of these sources alone establishes whether a dependency is acceptable for a specific threat model, deployment or contractual environment.
- A high Scorecard aggregate is not a penetration test.
- An advisory count must be tied to the exact installed version and remediation state.
- A large dependency graph may be manageable when updates and controls are strong.
- A recent release does not prove governance, compatibility or security.
- Unknown evidence remains unknown rather than being scored as failure.
Scoring implementation
| Dimension | Weight | Publication rule |
|---|---|---|
| Repository security practices | 25% | Use a dated OpenSSF aggregate and retain selected checks. |
| Known vulnerability exposure | 25% | Require an exact package and indexed-version query, affected status and fix state. |
| Maintenance health | 20% | Use release recency as a transparent proxy, not a verdict on maintainership. |
| Dependency risk | 15% | Require a resolved graph for the indexed version; optional extras and environment markers remain limitations. |
| Release and compatibility health | 10% | Use declared Python support, available distributions and verified publish attestations when captured. |
| Transparency | 5% | Use public security policy, changelog, documentation and contact or issue paths. |
The included scoring script refuses to emit an overall score unless evidence coverage is at least 80%, the repository and version-specific vulnerability dimensions are both present, and the operator explicitly supplies the --approved flag after human sign-off. In version 1.0, the approved script scores only records that satisfy every evidence gate. Pydantic receives a 90.5 overall score and a Lower observable risk band; the other 20 records remain Unscored – evidence coverage gate not met.
Scoring status
| Package scope | Records | Status | Interpretation |
|---|---|---|---|
| Pydantic 2.13.4 | 1 | 90.5 – Lower observable risk | Meets the 100% evidence-coverage gate for the six approved dimensions. This is a triage result, not a certification. |
| All other indexed packages | 20 | Unscored – evidence coverage gate not met | Human review is complete, but exact-version vulnerability or dependency evidence is incomplete. |
No cross-package ranking is published because one scored record is not a valid comparative market table.
Repository-practice snapshots
The captured Scorecard values apply to repositories, not exclusively to the indexed package version. The dates are essential because automated checks and repository practices can change. Among the records with captured evidence, the aggregate values range from 5.7 to 7.6 out of 10. This range is a description of available snapshots, not a package ranking.
Release and compatibility health
Release recency is treated only as a maintenance proxy. Twenty of the 21 indexed versions were released within 90 days of capture. The outlier remains in the dataset because a slower release cadence is not proof of abandonment. Teams should examine compatibility history, issue response and release quality before drawing conclusions.
Most records require Python 3.10 or newer. Five declare a Python 3.9 minimum, and one declares Python 3.11 as the minimum. These constraints matter when teams plan framework upgrades and long-term runtime support.
License review
The dataset preserves the package-published license expression or family rather than silently normalizing ambiguous records. Version 1.0 confirms a license expression or family for 20 packages. CrewAI remains marked as not confirmed from the retrieved PyPI metadata, and Ragas retains the broader label “Apache License” until an exact SPDX expression is confirmed.
Uvik Software publishes the compiled version 1.0 dataset under CC BY 4.0 following internal license approval. Source attribution must remain attached. deps.dev states that its generated data is available under CC BY 4.0, OpenSSF Scorecard REST API data is licensed under CDLA-Permissive-2.0, and OSV records retain source-specific licenses. PyPI API use remains subject to the PyPI Terms of Service.
How engineering teams should use the index
- Confirm the exact installed version rather than relying on a project-level record.
- Run a lockfile or environment scan to resolve optional and transitive dependencies.
- Review affected-version ranges and whether vulnerable code is reachable.
- Use repository practices to prioritize questions, not to replace code review.
- Document exceptions and compensating controls for business-critical packages.
The index does not replace threat modeling, software composition analysis, penetration testing, supplier review or contractual support requirements.
Commercial handoff
Inherited Python system with risky or outdated dependencies? Uvik Software audits dependency exposure, upgrades frameworks and packages, adds tests and hardens production systems. Request a Python dependency and modernization assessment.
Primary sources
- PyPI JSON API documentation
- deps.dev API documentation
- deps.dev data and licensing notes
- OSV data sources and downloads
- OpenSSF Scorecard documentation and public data
- PyPI Terms of Service
Frequently asked questions
Does a low score mean a package is insecure?
No. A score is a triage signal based on observable evidence. It is not a penetration test, certification or environment-specific risk assessment.
Why are most packages unscored?
Human and governance approvals are complete, but the scoring method still requires per-record technical evidence. Twenty packages do not yet have both exact-version advisory evidence and a resolved dependency graph at the required coverage level.
Are the package versions current?
They were the stable versions captured from official PyPI records on 2 August 2026. Readers should verify the current version before making a decision.
How can a maintainer correct a record?
Submit the package name, record ID, disputed field and a public or maintainer-controlled source through the correction form. Material corrections are dated in the changelog.
