Advanced Remediation

The Xray Remediation feature provides automated, intelligent remediation guidance directly from your SBOM and Security Views.

It supports:

• CVE-specific remediation: Smart, context-aware remediation for a vulnerability
• Component-based remediation: Prioritized package upgrades that reduce overall risk—even when not focusing on a single CVE

By leveraging JFrog’s security intelligence, Xray pinpoints vulnerabilities in both direct and transitive dependencies, maps their impact, and recommends optimal remediation paths.

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

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

Remediation Approaches

Package Manager Support

Smart Remediation Badges

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:

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.