Time-to-Patch Analysis

Executive Summary

The AI/ML ecosystem still has a patch-rate gap, but the picture is sharper than the early "crisis" narrative suggested. Across all CVE-to-package associations we track, 41.2% have a documented fix available (1,400 of 3,399 entries) — better than first feared, but well below the 60-70% rate typical of mainstream software. For CISOs managing AI deployments, this means patch management remains a strategic risk decision: when no vendor-supplied fix exists at the moment of disclosure, you cannot simply "patch and move on."

The packages topping the risk-score table are: torch (85/100), ollama (84), mlflow (81), gradio (80), litellm (79). These combine high CVE volume, critical severity, and in many cases active exploitation. They are not niche tools; they are foundational components of enterprise AI stacks.

Key Findings

• 41.2% global patch coverage across 3,399 CVE-package associations. The remaining 1,400 associations have no documented fix in package metadata at the time of analysis.
• torch remains #1 by risk score (85/100) — 46 CVEs, ~13% patch coverage. High blast radius through downstream dependents amplifies every vulnerability.
• ollama (84/100) is the highest-risk inference platform with 29 CVEs including SSRF, authentication bypass, and command injection. Patch coverage at ~10% — release cadence outpaces backport discipline.
• mlflow (81/100) has 80 CVEs making it the most vulnerability-dense MLOps platform. ~36% patch coverage. Path traversal, authentication bypass, and code execution dominate, particularly concerning given its role in model training pipelines.
• gradio (80/100) and litellm (79/100) patch faster than peers. ~28% and ~49% of their CVE-products have a recorded fix respectively, meaningfully better than ollama or torch despite similar disclosure volume.
• TensorFlow has the highest absolute CVE count (438) but a lower risk score (67/100) thanks to Google's relatively mature security process and faster patch cadence than newer frameworks.
• Newer agent platforms still trail. Flowise, LangFlow, and similar tools continue to show patch coverage in the low double digits while their feature surface grows monthly.

Trend Analysis

The patch-velocity data reveals a fundamental tension in the AI ecosystem: speed of innovation versus security maturity. Established projects (TensorFlow, scikit-learn) maintain better patch coverage because they have dedicated security teams, established CVE processes, and corporate or community backing. The newer wave of LLM frameworks, agent platforms, and inference servers grow user bases faster than their security posture can keep pace.

The "move fast and break things" culture that drove web development's early years is repeating in AI tooling, with higher stakes. An unpatched RCE in a web framework affects a website. An unpatched RCE in an inference server affects every model it serves and every system it connects to.

OpenSSF Scorecard scores correlate moderately with patch velocity: packages scoring above 7/10 patch noticeably faster than those below 4/10. Branch protection, dependency updates, and a published security policy are reliable predictors of patch responsiveness — and they are visible to anyone evaluating a dependency before adopting it.

Recommendations

1. Evaluate AI dependencies by patch velocity, not just functionality. When choosing between competing AI frameworks, include time-to-patch and patch coverage as selection criteria. A tool that patches in 7 days is categorically safer than one that takes 90 days, regardless of feature parity.
2. Implement compensating controls for unpatched AI vulnerabilities. With ~41.2% patch coverage, you cannot rely on vendor patches alone. Deploy WAF rules, network segmentation, input validation, and runtime monitoring as compensating controls.
3. Prioritize patching for the top-5 risk-score packages. If your stack includes torch, ollama, mlflow, gradio, or litellm, treat their CVEs as high-priority patch cycles — these combine high severity, active exploitation, and wide blast radius.
4. Monitor OpenSSF Scorecards for your AI dependencies. Packages with scores below 4/10 are statistically more likely to have slow or missing patch cycles. Treat that as a red flag in procurement decisions.
5. Budget for AI-specific vulnerability management. The patch gap means your team will spend disproportionate time on workarounds, compensating controls, and risk acceptances for AI components. Plan staffing and tooling accordingly.

Methodology

Time-to-patch metrics are derived from `cve_products.first_patched_version` — the earliest fixed version recorded against a CVE for a given package. Patch coverage is the share of CVE-product associations with a non-null patched version. Risk scores combine 7+ signals: CVE volume, severity distribution, EPSS exploitation probability, KEV status, blast radius (downstream dependents), OpenSSF scorecard, and patch responsiveness. Data sources include NVD, GitHub Security Advisories, PyPI, npm, OSV, and vendor changelogs. All numeric values in this analysis are pulled live from the database on every page load.