Smart Remediation

Xray Remediation analyzes your SBOM and Security Views to recommend how to fix vulnerable dependencies—including issues buried in transitive packages. For each artifact, Xray suggests secure upgrade paths, optional lockfile overrides, and ready-to-use configuration snippets tailored to your package manager.

You can remediate in two ways:

  • CVE-based remediation — find the best fix for a specific vulnerability, including whether to upgrade a direct dependency or override a transitive one.
  • Component-based remediation — identify package upgrades that reduce the most overall risk, even when you are not targeting a single CVE.

Xray evaluates candidate versions using ecosystem-specific dependency logic, semantic versioning, and JFrog vulnerability intelligence. Choose a remediation strategy that fits your priorities—from the smallest safe upgrade to the version with the lowest residual risk.

Prerequisites

Self-Hosted – JFrog Catalog Access: To use Xray Remediation, you must have access to the JFrog Catalog.

Self-Hosted – SBOM Requirements
Remediation requires the following feature flags in Xray’s system.yaml:

  • sbom.enabled: true
  • sbom.dependenciesEnabled: true

Why Transitive CVEs Matter

Most vulnerabilities in modern applications reside deep within transitive dependencies—packages that are included indirectly through other dependencies.

These issues are difficult to detect and fix because:

  • Vulnerabilities may be several layers deep in the dependency tree
  • The impact path can be complex to trace
  • Fixes require deciding between patching a transitive dependency or upgrading a direct dependency

Xray Remediation automates this process, highlighting the most effective fix path and allowing you to choose between quick, minimal-disruption patches or broader upgrades that resolve multiple vulnerabilities at once.

Key Use Cases

CVE-Based Remediation
Identify the most effective fix version to resolve a specific CVE.

Component-Based Remediation
Surface upgrades that deliver the largest overall security improvement, independent of a specific CVE.

Challenges Addressed

  • Complex Dependency Trees – Vulnerabilities buried in transitive dependencies require in-depth analysis to locate and remediate
  • Manual Overhead – Researching secure versions, generating configuration changes, and validating compatibility and policy compliance is time-consuming
  • Lack of Strategic Context – Without guidance, it is difficult to determine which upgrades yield the highest overall security gain

Core Capabilities

📘

Remediation outputs are suggestions generated from multiple information sources, including JFrog research, the dependency graph, and available package and vulnerability data. Software dependency graphs are highly complex, and not every scenario can be fully evaluated. Remediation suggestions represent best-effort recommendations and may not be complete or fully accurate in all cases.

1. Component-Based Remediation (Upgrade Suggestions)

A general, multi-vulnerability approach that highlights upgrades with maximum security payoff.

2. CVE-Based Remediation

CVE-based remediation provides targeted fixes derived from impact path analysis of the SBOM. For each vulnerability, Xray determines whether the CVE is introduced through a direct dependency or through one or more transitive dependencies, and maps the full resolution path.

Remediation suggestions are generated using ecosystem-specific resolution logic. For example, in Maven projects, Xray accounts for dependency management and override mechanisms. This ensures that the fix recommendation is valid and reproducible within the package manager’s constraints.

Xray also applies semantic versioning awareness and JFrog’s vulnerability intelligence to select the most suitable upgrade option. The engine evaluates multiple candidate versions, considering:

  • Whether a direct upgrade resolves the vulnerable transitive component
  • Whether a transitive override is required
  • Whether the resulting dependency tree introduces additional known CVEs

This combination of transitive context analysis and ecosystem-specific upgrade logic ensures that the suggested fix is both secure and technically correct for the package manager in use.

Remediation Strategies

StrategyDescriptionBest ForAlgorithm Deep Dive
Quickest FixChooses the nearest secure version to minimize time to patchTime-sensitive patches
Least VulnerableSelects the version with the best overall security postureMaximizing security posture
Best VersionSelects the optimal version based on JFrog’s remediation algorithmGeneral purpose

Remediation Approaches

ApproachDescription
Override Remediation (In-Lock)Forces a secure version of a transitive dependency without upgrading direct dependencies
Direct Dependency FixesUpgrades direct dependencies to secure versions that remove vulnerable transitive components
Base Image UpgradeRecommends a newer version of the base image your container is built on, for CVEs that come from that base image

3. Base Image Upgrade for Container Images

A container image picks up vulnerabilities from the base image it's built on. Those CVEs don't come from your own code, and the way to fix them is to build on a newer base image. Xray tells you which version to move to.

When a CVE comes from the base image, Xray recommends a newer version of the base image you already use and gives you the FROM line to put in your Dockerfile. Xray doesn't suggest replacing your base image with a different one, so it won't tell you to move from Debian to Alpine, for example.

Prerequisites

  • JFrog Advanced Security, which the Remediation tab in scan results requires.
  • Base Image Detection. Both your image and its base image must be scanned by Xray on the same JFrog Platform. If Xray hasn't scanned the base image, it can't tell which CVEs come from it, so no base image recommendation appears.
  • On self-managed environments, sbom.enabled: true and sbom.dependenciesEnabled: true in Xray's system.yaml, the same as the other remediation types on this page.

To upgrade a base image:

  1. Open the scan results for a Docker or OCI image.
  2. Select a CVE that comes from the base image.
  3. Open the Remediation tab and go to the Base Image section.
  4. Choose the option that matches your priority: Quickest Fix for the smallest change, Least Vulnerable for the strongest security posture, or Best Version for JFrog's recommended balance.
  5. Copy the FROM line, update your Dockerfile, and rebuild your image.

What to Expect

  • Xray suggests base image versions that it has already scanned, so a version released very recently might not appear yet.
  • Only CVEs that come from the base image are covered. For vulnerabilities in the layers you add on top, use the other remediation approaches on this page.
  • This is not the same as Skip base image in a policy, which stops base image findings from raising violations instead of fixing them. For more information, see Create Policies.

Package Manager Support

EcosystemIn-LockDirectCode Snippet Support
Mavenmaven
NPMnpm, yarn, pnpm
PyPIpip, pdm, uv
GoComing soongo.mod
NuGetComing soonComing soon
ConanComing soonComing soon
Docker and OCINot applicableBase image upgradeDockerfile FROM line

Smart Remediation Badges

BadgeMeaning
Non-BreakingUpgrade respects semantic versioning constraints, minimizing breakage risk
Solve More CVEsSuggested version resolves additional vulnerabilities beyond the targeted CVE
Curation Approved – Coming SoonSuggested version is approved by JFrog Curation policies
Policy Approved – Coming SoonSuggested version is pre-approved by effective security policies

For deeper context on how vulnerabilities are introduced and propagated through your dependency tree, see Transitive Dependency Analysis. This feature complements remediation by showing the exact dependency paths that lead to a CVE, helping you validate and prioritize suggested fixes.

Version Selection Strategies

This guide explains the three supported version selection strategies used in the remediation system to help you choose the most appropriate approach for your security vulnerability fixes.

Overview

When vulnerabilities are detected in your dependencies, the remediation system can suggest updated versions to fix these security issues. The system offers three different strategies, each with its own approach to selecting the best candidate version from available options.

Vulnerability Risk Scoring

Each candidate version receives a risk score based on its vulnerabilities using a weighted system that reflects the real-world impact of different severity levels:

SeverityScore
Low1
Medium10
High100
Critical10,000

The total score for a candidate is the sum of all its vulnerability scores. This scoring system ensures that critical vulnerabilities are treated with the urgency they deserve, while still accounting for the cumulative effect of multiple lower-severity issues.

Strategy 1: Quickest Fix Strategy

Purpose: Selects the version that requires the smallest version jump from your current version.

How it Works

  • Finds the closest semantic version that is newer than your current version
  • Prioritizes minimal version changes to reduce the risk of breaking changes
  • Only considers versions that are actually newer than your current version
  • Ignores versions with invalid version strings

When to Use

  • Development environments where you want to minimize disruption
  • Critical production systems where stability is paramount
  • Legacy codebases that may be sensitive to major version changes
  • When you need a quick, low-risk fix for security vulnerabilities

Example

If you're using version 3.4.5 and have candidates 3.4.6, 3.4.7, and 3.4.8, this strategy will select 3.4.6 as it's the closest upgrade.

Strategy 2: Least Vulnerable Fix Strategy

Purpose: Selects the version with the lowest security risk score among all candidates.

How it Works

  • Calculates a risk score for each candidate using the vulnerability scoring system described above
  • Among candidates with the same lowest score, selects the closest semantic version
  • Prioritizes security over version proximity

When to Use

  • Security-focused environments where vulnerability reduction is the top priority
  • Compliance requirements that mandate the lowest possible risk
  • When you have multiple versions with similar security profiles and want the safest option
  • Production systems where security takes precedence over minimal version changes

Example

You're currently using version 3.4.4 and have these candidates:

  • Version 4.2.0: 1 Medium vulnerability (10 points) + 1 High vulnerability (100 points) = 110 points
  • Version 3.4.5: 1 Critical vulnerability (10,000 points) = 10,000 points
  • Version 5.3.1: 1 Medium vulnerability (10 points) + 1 High vulnerability (100 points) + 1 Low vulnerability (1 point) = 111 points
  • Version 4.2.1: 1 Medium vulnerability (10 points) + 1 High vulnerability (100 points) = 110 points

The strategy will select Version 4.2.0 (110 points) as it has the lowest risk score, even though it's a larger version jump than 3.4.5. If multiple versions had the same lowest score (like 4.2.0 and 4.2.1 both at 110 points), it would choose the one closest to your current version.

Strategy 3: Best Version Strategy

Purpose: The most sophisticated strategy that balances security, policy compliance, and breaking change considerations.

How it Works

The Best Version Strategy uses a four-tier priority system to make intelligent decisions. It first looks for policy-approved, non-breaking versions and selects the least vulnerable among them. If none exist, it falls back to policy-approved breaking versions, then non-policy-approved non-breaking versions, and finally non-policy-approved breaking versions. Within each tier, it always chooses the version with the lowest vulnerability risk score.This approach ensures that your organization's policies are respected while maintaining security as the primary concern within each priority level.

When to Use

  • Enterprise environments with established security policies
  • Complex applications where both security and stability matter
  • Organizations with compliance requirements that need policy adherence
  • Production systems that need to balance multiple competing priorities
  • When you want the most comprehensive and intelligent version selection

Example

If you have candidates that are policy-approved and non-breaking, this strategy will always prefer those over policy-approved breaking changes, and will always prefer policy-approved versions over non-policy-approved ones, regardless of their security scores.

Detailed Example

You're currently using version 4.1.1 and have these candidates:

  • Version 4.2.0: 1 High vulnerability (100 points), policy-approved, non-breaking
  • Version 5.0.0: 1 Medium vulnerability (10 point), policy-approved, breaking
  • Version 4.2.2: 2 Medium vulnerabilities (20 points total, including CVE-2025-12345), not policy-approved, non-breaking

Your organization's policy automatically rejects any version containing CVE-2025-12345, making version 4.2.2 non-policy-approved despite having a lower vulnerability score than 4.2.0.The strategy processes candidates in priority order:

Even though 4.2.2 has a lower vulnerability score (20 points vs 100 points), it's not policy-approved due to the forbidden CVE, so it's never considered. The strategy prioritizes policy compliance over perfect security scores.

Important Notes

  • All strategies only consider versions that are newer than your current version
  • The Remediation mechanism only selects the latest 500 versions to prioritize from. if a package has more than 500 newer versions than the current one - partial results may happen
  • Policy Approval Check is limited to security-related rules

Conclusion

Each strategy serves different organizational needs and risk tolerances. The Quickest Fix strategy prioritizes stability, the Least Vulnerable Fix strategy prioritizes security, and the Best Version strategy provides intelligent balancing of all factors. Choose the strategy that best aligns with your organization's priorities and risk management approach.


Did this page help you?