Zero-Touch Remediation Overview
Automatically replace vulnerable package versions with verified, drop-in secure patches at resolution time—so builds stay green and exposure windows shrink from weeks to hours.
JFrog Zero-Touch Remediation closes the gap between vulnerability detection and remediation. When a developer or CI pipeline requests a vulnerable package from an Artifactory virtual repository covered by a Zero-Touch Remediation automation, the service provides a verified patched version without requiring a manual dependency upgrade.
AppSec teams govern remediation through scoped automations that define the covered virtual repositories and vendor priority. Fixes can come from connected clearing-house vendors or from local patches—Maven artifacts your organization rebuilt and registered in an Artifactory local repository. The goal is to compress exposure windows from weeks to hours while keeping builds green.
How Zero-Touch Remediation Works
Zero-Touch Remediation supports Maven and npm virtual repositories. The remediation flow differs by package type.
Maven remediation
Maven remediation occurs during download:
- A build requests the original Maven coordinate from a covered virtual repository.
- Artifactory asks Xray whether a patched replacement is available.
- Xray queries JFrog Catalog for patched candidates from the clearing-house vendors connected to the virtual repository and from local patches registered in local repositories that are members of that virtual repository.
- The Least Vulnerable strategy selects the candidate with the lowest vulnerability score. If scores are equal, a registered local patch ranks above a vendor rebuild. Remaining ties use the automation's vendor priority.
- If the selected candidate reduces CVE exposure, Artifactory serves it through the same virtual repository.
- Xray records the decision in the Zero-Touch audit view.
If no suitable patched version exists, or a candidate would not reduce CVE exposure, Artifactory serves the originally requested artifact.
npm remediation
npm remediation occurs before installation by rewriting package-lock.json; it does not intercept the tarball download:
- The project contains a
package-lock.jsonwith the original package versions. - A JFrog CLI version that supports lockfile healing sends the lockfile and npm virtual repository name to Xray.
- Xray queries JFrog Catalog for patched candidates allowed by the matching Zero-Touch automation.
- Xray returns a rewritten lockfile with the patched version, a
resolvedURL that points to the same Artifactory virtual repository, and integrity data calculated from the artifact in Artifactory. - JFrog CLI writes the returned lockfile, and npm installs the patched tarballs from the virtual repository.
- Xray records the decision in the same Zero-Touch audit view used for Maven.
Lockfile healing evaluates direct and indirect dependencies. Continue to declare the original package name and version in package.json; do not enter vendor-specific versions manually or point npm directly to a vendor registry.
npm requires JFrog CLIA standard
npm installdoes not invoke lockfile healing. Use a JFrog CLI version that supports npm lockfile healing and use or commit the rewrittenpackage-lock.json. Maven remediation happens in Artifactory and does not require JFrog CLI.
Supported Fix Vendors
Zero-Touch Remediation selects patched packages from the following clearing-house vendors. Vendor coverage differs by package type.
| Vendor | Maven | npm |
|---|---|---|
| Chainguard | Supported | Not supported |
| Echo | Supported | Supported |
| TuxCare | Supported | Supported |
| Seal Security | Supported | Supported |
Because Chainguard provides Maven fixes only, npm automations remediate through Echo, TuxCare, and Seal Security. A vendor participates in remediation only when the covered virtual repository includes that vendor's remote repository.
Local patches
Organizations that maintain their own Maven backports can register those artifacts as healing candidates. Zero-Touch Remediation serves the local bytes at the original coordinate—the same interception path used for vendor rebuilds.
- Registration is a REST API request (
POST /xray/api/v1/ztr/patches) plus a CycloneDX 1.6 declaration. There is no create-patch UI. - Local patches are Maven only. npm lockfile healing does not consume them.
- Serving requires the local repository to remain a member of the covered Maven virtual repository. Registration does not name the virtual repository and does not add a separate enable/disable control.
For the registration contract and validation outcomes, see Register local patches.
Supported Capabilities
| Area | Description |
|---|---|
| Resolution-time remediation | Maven packages through Artifactory virtual repository interception |
| Lockfile remediation | npm packages through JFrog CLI and package-lock.json rewriting |
| Fix sources | Verified patched versions from the clearing-house vendors connected to the covered virtual repository—Chainguard (Maven), Echo, TuxCare, and Seal Security—and from registered local patches (Maven) |
| Automation management | Create, edit, and activate automations with repository scope and vendor priority |
| Audit | Remediation Requests page with per-event detail and candidate version scoring |
| Scan results | How to read results after remediation—requested vs. served version lineage, remediated vs. active violations, and reconciling Xray counts with third-party scanners |
Prerequisites
Before you enable Zero-Touch Remediation:
- Xray and Artifactory on your JFrog Platform.
- A Maven or npm virtual repository that includes the public registry and the remote repositories of the vendors you want to use. For npm, use a vendor that supports npm: Echo, TuxCare, or Seal Security.
- Remote repositories behind the virtual repository indexed in Xray, so scans correctly reflect components after remediation.
- For npm, an existing
package-lock.jsonand a JFrog CLI version that supports npm lockfile healing. - For local patches, an Xray-indexed Maven local repository that is a member of a covered virtual repository, plus Manage Data permission to register artifacts. See Register local patches.
Next Steps
- Configure Zero-Touch Remediation automations
- Register local patches
- View Remediation Requests
- Interpret remediation in scan results
FAQs
Q: Does Zero-Touch Remediation block builds like Xray or Curation?
A: No. Zero-Touch Remediation provides a less-vulnerable patched package when one is available. Blocking enforcement remains part of Xray and Curation.
Q: What package types does Zero-Touch Remediation support?
A: Zero-Touch Remediation supports Maven through Artifactory download interception and npm through JFrog CLI lockfile healing. Maven fixes come from Chainguard, Echo, TuxCare, Seal Security, and registered local patches. npm fixes come from Echo, TuxCare, and Seal Security.
Q: Can we serve patches we built ourselves?
A: Yes, for Maven. Upload the rebuilt artifact to an Xray-indexed local repository that is a member of a covered virtual repository, then register it with POST /xray/api/v1/ztr/patches. See Register local patches. Local patches are not supported for npm.
Q: What is a remediation event?
A: A remediation event is the activation of Zero-Touch Remediation logic that replaces a vulnerable package with a less-vulnerable patched version. Events are grouped as Healed (replacement succeeded), Skipped (no compliant version was found or the CVE count was not reduced), or Not required (no automation matched).
Q: How does the Least Vulnerable strategy select a package?
A: Least Vulnerable selects the patched candidate with the lowest vulnerability weight: Critical × 1,000,000 + High × 10,000 + Medium × 100 + Low. When scores are equal, a registered local patch ranks above a vendor rebuild. Remaining ties use vendor priority.
Q: Will remediated packages show as violations in scan results?
A: The served (patched) version scans clean. Xray displays a Patched contextual analysis status so scan results reflect the remediated state. See Interpret remediation in scan results for details.
Updated about 4 hours ago
