--- updatedAt: 2026-10-05T10:32:04.000Z agentTools: siteIndex: https://docs.jfrog.com/llms.txt projectIndex: https://docs.jfrog.com/security/llms.txt --- # Smart Remediation Learn how JFrog Xray Remediation recommends dependency and base-image upgrades. [JFrog Xray](/docs/xray) Remediation analyzes your SBOM and Security Views to recommend how to fix vulnerable dependencies as well as 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're not targeting a single CVE. Xray evaluates candidate versions using ecosystem-specific dependency logic, semantic versioning, and JFrog vulnerability intelligence. You can choose a remediation strategy that fits your priorities. Options range from the smallest safe upgrade to the version with the lowest residual risk. ## How Xray Remediation Works ### Prerequisites **Self-hosted JFrog Catalog access**: To use Xray Remediation, you must have access to [JFrog Catalog](/docs/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. Transitive dependencies are 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 identifies the most effective fix version to resolve a specific CVE. Component-based remediation surfaces 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's difficult to determine which upgrades yield the highest overall security gain. ### Core Capabilities Remediation suggestions are best-effort recommendations based on the dependency graph and JFrog vulnerability data. **Note** 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 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. Xray generates remediation suggestions 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 Xray offers the following remediation strategies. | Strategy | Description | Best For | Algorithm Deep Dive | | -------------------- | ------------------------------------------------------------------ | --------------------------- | ------------------- | | **Quickest Fix** | Chooses the nearest secure version to minimize time to patch | Time-sensitive patches | | | **Least Vulnerable** | Selects the version with the best overall security posture | Maximizing security posture | | | **Best Version** | Selects the optimal version based on JFrog’s remediation algorithm | General purpose | | ### Remediation Approaches You can apply the following remediation approaches. | Approach | Description | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Override Remediation (In-Lock)** | Forces a secure version of a transitive dependency without upgrading direct dependencies | | **Direct Dependency Fixes** | Upgrades direct dependencies to secure versions that remove vulnerable transitive components | | **Base Image Upgrade** | Recommends 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](/docs/advanced-security), which the Remediation tab in scan results requires. * [Base Image Detection](/docs/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 CVE-based and component-based remediation. **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 [Remediation Approaches](/security/docs/smart-remediation#remediation-approaches). * This isn't 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](/docs/create-policies#skip-base-image-security-and-license-rules). ### Package Manager Support Xray Remediation supports the following package managers. | Ecosystem | In-Lock | Direct | Code Snippet Support | | -------------- | -------------- | ------------------ | ---------------------- | | Maven | ✅ | ✅ | `maven` | | npm | ✅ | ✅ | `npm`, `yarn`, `pnpm` | | PyPI | ✅ | ✅ | `pip`, `pdm`, `uv` | | Go | ✅ | Coming soon | `go.mod` | | NuGet | ✅ | Coming soon | Coming soon | | Conan | ✅ | Coming soon | Coming soon | | Docker and OCI | Not applicable | Base image upgrade | Dockerfile `FROM` line | ### Smart Remediation Badges The following badges can appear on a remediation suggestion. | Badge | Meaning | | ----------------------------------- | -------------------------------------------------------------------------------- | | **Non-Breaking** | Upgrade respects semantic versioning constraints, minimizing breakage risk | | **Solve More CVEs** | Suggested version resolves additional vulnerabilities beyond the targeted CVE | | **Curation Approved – Coming Soon** | Suggested version is approved by [JFrog Curation](/docs/curation-intro) policies | | **Policy Approved – Coming Soon** | Suggested version is pre-approved by effective security policies | For more information, see [Transitive Dependency Analysis](/docs/contextual-analysis-of-cves-1#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 supported version selection strategies used in Xray Remediation to help you choose the most appropriate approach for your security vulnerability fixes. ### Version Selection Strategies Overview When Xray detects vulnerabilities in your dependencies, it can suggest updated versions to fix these security issues. Xray Remediation offers 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. The following weights reflect the real-world impact of different severity levels. | Severity | Score | | -------- | ------ | | Low | 1 | | Medium | 10 | | High | 100 | | Critical | 10,000 | The total score for a candidate is the sum of all its vulnerability scores. This scoring system treats critical vulnerabilities with the urgency they deserve, while still accounting for the cumulative effect of multiple lower-severity issues. ### Strategy 1: Quickest Fix Strategy The Quickest Fix strategy 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 The Least Vulnerable Fix strategy 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 Risk Scoring system * 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 The Best Version strategy is the most sophisticated strategy. It 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 points), 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. ### Version Selection Limits * 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, you might get partial results. * 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. You can choose the strategy that best aligns with your organization's priorities and risk management approach. ## Related Topics * [Understanding and Analyzing Xray Scan Results](/docs/understanding-and-analyzing-xray-scan-results) * [Create Fix Pull Requests with Auto-PR](/docs/how-to-create-fix-pull-requests-with-auto-pr) * [Zero-Touch Remediation Overview](/docs/zero-touch-remediation-overview) * [SBOM](/docs/sbom) * [Compliant Version Selection](/docs/compliant-version-selection)