Most organizations can tell you what CVEs they found last quarter. Few can tell you which packages will become a problem next month or which AI skills are running in production without a certified identity. This piece is about closing that gap.

Source for both: 2026 JFrog Software Supply Chain Security State of the Union

The problem is bigger than your CVE backlog

CISA, the SEC, and the EU Cyber Resilience Act are now mandating that enterprises address software supply chain risk not as a project, but as an ongoing operational discipline. The regulatory pressure is real, but the technical problem predates it by years.

The pattern is consistent across enterprises at scale: hundreds of ungoverned repositories, developers pulling packages directly from public registries with no policy enforcement, no Software Bill of Materials, no audit trail, and no way to determine whether what is running in production is what was approved. Containers carrying hundreds of OS-layer CVEs are baked into base images before a single line of application code is written.

Now compound this with the emerging agentic attack surface. AI agents, skills, MCP servers, and prompt templates are being packaged and deployed into production pipelines with the same absence of governance that plagued open-source packages a decade ago. The attack surface has expanded; the governance frameworks largely have not.

The Alert Fatigue Problem

A typical Xray scan of an enterprise estate surfaces thousands of CVEs. Without EPSS scoring and blast radius analysis, security teams have no principled basis for prioritization, so they either attempt to address everything (impossible) or nothing (the actual outcome). The result is a growing backlog that erodes trust in the tooling itself.

JFrog’s data shows why this matters. With only 12% of high-profile CVEs highly exploitable, a team that works the backlog in severity order alone will spend much of its effort on findings that were never going to be exploited. Applicability (is the vulnerable code actually reachable in your context) and EPSS (how likely is exploitation in the wild) are different signals, and the architecture below uses both kinds: EPSS for likelihood, and VEX attestations plus Wiz runtime analysis for reachability.

The three modes of supply chain posture

Most organizations sit in reactive mode. The goal of a governed supply chain program is to move through proactive and reach predictive where risk is identified and addressed before CVEs are published, not weeks after.

The governed tollgate: how it works

The architecture begins with a hard constraint: no package enters the estate without passing through a single governed path. Network enforcement Zscaler and proxy configuration eliminates direct registry access at the network layer. Developers and pipelines cannot bypass it. This is not a policy; it is a topology.

Curation: the pre-entry checkpoint

Before any package is admitted, JFrog Curation evaluates it against CVE thresholds, malicious package blocklists, and license policy. Low-risk packages auto-approve. Medium-risk packages are escalated to Security or AppSec for review. High-risk packages are hard-blocked. Every decision is logged with a timestamp and decision reason creating the audit trail that compliance requires and that reactive programs lack entirely.

Xray: the continuous monitor

Xray runs asynchronously on everything already inside the estate. As new CVEs are published, Xray rescans, runs impact analysis against affected builds, generates live SBOMs in CycloneDX format, and produces delta reports comparing the live inventory against the approved baseline. The combination of Curation and Xray is deliberate: Curation without Xray misses post-admission vulnerabilities; Xray without Curation lets bad artifacts in before they can be caught.

Chainguard: eliminating base image noise

Chainguard hardened base images ship with near-zero OS-layer CVEs and include VEX (Vulnerability Exploitability eXchange) attestations that declare which CVEs in an image are non-exploitable in that specific context. When Wiz’s runtime analysis confirms what is actually reachable in a running workload, the combination suppresses false positives before they reach the security team. This is not noise reduction through threshold tuning it is accurate signal at the source.

Moving to predictive: OpenSSF, EPSS, and blast radius

CVSS severity scores are a lagging indicator. They tell you how bad a vulnerability is once it exists. The predictive layer adds three signals that tell you what will become a problem before it does.

OpenSSF scorecard — maintainer health as a leading indicator

A package with zero critical CVEs today is not necessarily safe. If its OpenSSF scorecard is low no signed releases, no branch protection, inactive maintainers, no automated dependency update tooling, weak code review practices it is statistically more likely to carry an exploitable vulnerability within the next 12 months. OpenSSF Scorecard runs 10+ software supply chain hygiene checks and produces a score between 0 and 10. In this architecture, the scorecard is fetched automatically before a package hits the policy engine, so admission decisions are made on enriched risk profiles, not just package metadata. A minimum score threshold is enforced packages below it are flagged for human review regardless of their current CVE status.

EPSS: exploitability probability at the moment it matters

EPSS (Exploit Prediction Scoring System) estimates the probability that a given CVE will be exploited in the wild within the next 30 days. Applied alongside CVSS, it answers a different question: not how severe is this, but how urgent. A CVSS 7.5 with an EPSS of 0.82 demands immediate attention. A CVSS 9.1 with an EPSS of 0.003 can be scheduled. This is the basis for intelligent routing: high EPSS findings go directly to a ServiceNow change ticket with an SLA; low EPSS findings can be monitored with a standard cadence.

Blast radius: understanding exposure before acting

A CVE in isolation is an incomplete picture. Blast radius analysis maps every build, pipeline, and downstream consumer that would be affected if that vulnerability were exploited. Combined with EPSS, it enables a risk prioritization that security teams can actually execute: address the high-EPSS, high-blast-radius findings first, schedule the rest. This is how an organization moves from a backlog of thousands to a sprint list of twelve.

The five-gate pipeline

Every artifact package, container image, AI skill package passes through the same five-gate sequence before promotion to production.

The CI/CD pipeline becomes a hard governance gate. Promotion cannot proceed if a package fails policy validation. Developers receive a clear signal at promotion time not three weeks later when a CVE is disclosed in a production incident.

Shift left: IDE and CI/CD integration

The same policy engine that enforces gates at the pipeline level surfaces findings in the developer’s IDE before a commit is made. A dependency flagged in the IDE operates under the same rules that govern production it is not a different finding, it is the same finding surfaced earlier. This is what shift left means in practice: not a different set of rules for developers, but the same rules applied at the earliest possible moment in the development lifecycle.

AI artifact governance: the forward edge

JFrog Security Research found 495 malicious models on Hugging Face and 969 malicious AI agent skills in public skill registries, while 97% of organizations claim certified model governance (2026 JFrog Software Supply Chain Security State of the Union). The distance between that claim and what is demonstrably in place is the gap this layer addresses.

Traditional supply chain governance addresses software packages and container images. The same attack surface now extends to AI artifacts (models, skills, MCP server implementations, and prompt templates), which are being packaged and deployed into production pipelines with the same absence of governance that characterized open-source dependency management a decade ago.

AIBOM — AI Bill of Materials

AIBOM extends the SBOM concept to AI artifacts. For a model: training data sources, architecture, fine-tuning dataset provenance, evaluation benchmark results. For a skill: what tools it can call, what data it can access, what model it invokes, who authored it.

Generated at intake, versioned, and cryptographically signed. This satisfies emerging requirements from NIST AI RMF, EU AI Act Article 13, and anticipated SEC guidance on AI system disclosure.

AIVSS — AI Vulnerability Scoring System

Traditional CVSS scores software vulnerabilities. AIVSS extends the same scoring discipline to AI-specific risk dimensions:

Governing agent skills through the same intake pipeline

JFrog’s intake pipeline Curation, Xray, and the policy gate governs AI skill packages before they are registered in the agent catalog, using the same mechanics it applies to software packages. A Python package implementing callable agent behavior, an MCP server implementation, or a prompt template is evaluated at intake, versioned, and cryptographically signed. A skill that has not cleared the intake gate cannot be registered in the catalog. The CI/CD promotion gate is the trust boundary not a separate approval process, not an informal review, but the same governed path that every other artifact in the estate travels.

Regulatory alignment

The SBOM requirement addresses NTIA and CISA mandates directly. The AI artifact governance layer AIBOM, AIVSS, cryptographic signing at intake anticipates NIST AI RMF implementation guidance and EU AI Act Article 13 transparency requirements. The audit trail produced by the five-gate pipeline is the form of evidence SEC cyber disclosure rules require: timestamped, attributable, and queryable on demand.

These requirements are not static. The accelerator is designed to evolve with the regulatory landscape rather than require re-implementation as guidance matures.